blocks-development — Main mailing list for Blocks

Re: [Blocks-development] Doh!

[Benjamin M. B. <br...@kr...>]

On Tue, 1 Aug 2000, Blat Froop wrote:
> 4) Authentication and Ratings
> 
>    Im quite interested in crypto, and a rating system is an
>    interesting idea. However, I dont want to increase the size
>    of File Adverts by including public keys, descriptions, and
>    so on. Now, if there were a seperate system (maybe even
>    web based) that Blocks could access information from
>    using the file ID (hash sent with ad) that would be a very
>    different story. Another possible future option would be
>    to seperate out the server code and build something like
>    a library (maybe even ActiveX control) to allow much more
>    complex custom front ends (you might have noticed they
>    arent really my speciality) that allow extended functionality.


Sorry for the 'dup' reply, but I did want to make another point. Assuming
you are shooting for cross-platform (or at least easy portability...) you
do NOT want to use ActiveX. It's not even available on the MacOS none the
less solaris/digital unix/linux/*bsd. This would be a 'bad career move'
for blocks / blocknet. Perhaps we can work something out without using
ActiveX.

One other thing to note: Although I have no idea how to do programming
with the fltk toolset, etc, I _would_ like to design a better GUI for
blocks/blocknet. If it is ok with the members on the list, I would like to
make a few drawings for a proposed GUI? I'll post them in

http://www.kripto.org/blocks/newgui/

I'll probably have them done tomorrow night sometime - I have another
10-hour shift at work, and paint shop pro is a good waste of time :)

-Benjamin M. Brewer
http://kripto.org
bb...@we...

Re: [Blocks-development] Doh!

[Benjamin M. B. <br...@kr...>]

Comment are below in the 'correct sections'.

On Tue, 1 Aug 2000, Blat Froop wrote:

> Hi,
> 
> well I thought it was getting a bit quieter on the email front...
> I didnt realise that I actually had to *join* the mailing list
> after I set it up! But Im here now :-)
> 
> Ive had a quick look through the archive and heres some brief
> comments :-
> 
> 1) We need that ability to upload multiple files.
> 
>     Agreed. I also need to fix the problem that everything stops
>     while a file is uploaded. Another possibility is a(possibly         
> command line based) injection tool for injecting content into
>     servers.
> 
Perhaps if there was a simple 'upload' directory within the blocks
dir? You could just mv/cp files into the directory at one time, and then
hit a button within the blocksgui to READ that upload dir to see if any
files were in there?

> 2) Sticky local files.
> 
>    Seems so obvious I wonder why I never thought of it. I dont
>    want to have too much complexity on the cache maintenance side
>    if I can avoid it, but adding a sticky bit is a possibility.
> 
> 3) Should we readvertise proxied files?
> 
>    Well it does at the moment. If you switch off 'readvertise files'
>    people cant connect and browse your cache anyway. 'Deniablilty'
>    is always there since you didnt upload these files anyway...
>    its the same problem if you were to run a public HTTP Proxy
>    (Squid or whatever). Routes do get 'unadvertised' when a
>    connection is broken so content may become inaccssible.
>    I could add another option covering this but would it really be
>    useful?

Yes. Although this system is NOT designed for the modem users, they will
obviously become interested in the protocol / application, so they can get
their mp3 'fix'. :)  We should _not_ leave them out, even though their
usage of the network may not be desirable on their end.

> 4) Authentication and Ratings
> 
>    Im quite interested in crypto, and a rating system is an
>    interesting idea. However, I dont want to increase the size
>    of File Adverts by including public keys, descriptions, and
>    so on. Now, if there were a seperate system (maybe even
>    web based) that Blocks could access information from
>    using the file ID (hash sent with ad) that would be a very
>    different story. Another possible future option would be
>    to seperate out the server code and build something like
>    a library (maybe even ActiveX control) to allow much more
>    complex custom front ends (you might have noticed they
>    arent really my speciality) that allow extended functionality.

Idea! I was just playing with gnoRPM (A gnome frontend to the RPM package
format) and I liked how it worked. When you clicked on a file, and quickly
connected to that location and downloaded information about the file in
question. Blocknet could do the same thing. This request for information
would only be sent to the sender of the file, and since the sender will
get 'connected to' anyways to download the file, we are not losing any
privacy that we currently have.

Have it so you highlight a file in the search list, and then hit the 'more
info' button, or something similar, and THEN the varifying information can
be sent - per request.

> 5) Logos
> 
>    The 2 Logos on the web page are the winners. These are now
>    the Blocks logos for the foreseeable future.

Not sure if you noticed the colorized version of the 'other logo' (the one
that isn't mine...), it is much better, and if you wish, I can add that
one instead...

> 6) IRC
> 
>    As long as Flaggovic hold #blocks open on DALNet I'll
>    keep it listed. I may change the order to list EFNet first
>    if its more popular.
> 

DALNet is crap =\ I think it should mainly be based on EFnet, but that's
just personal opinion.

PS, did you get those linux-binaries?

-Ben

> Apologies if I missed any important threads.
> 
> ttfn
> 
> PG.
> 
> PS Im glad the list isnt full of bug reports! :)
> 
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> 
> 
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development
> 

[Blocks-development] Doh!

[Blat F. <pet...@ho...>]

Hi,

well I thought it was getting a bit quieter on the email front...
I didnt realise that I actually had to *join* the mailing list
after I set it up! But Im here now :-)

Ive had a quick look through the archive and heres some brief
comments :-

1) We need that ability to upload multiple files.

    Agreed. I also need to fix the problem that everything stops
    while a file is uploaded. Another possibility is a(possibly         
command line based) injection tool for injecting content into
    servers.

2) Sticky local files.

   Seems so obvious I wonder why I never thought of it. I dont
   want to have too much complexity on the cache maintenance side
   if I can avoid it, but adding a sticky bit is a possibility.

3) Should we readvertise proxied files?

   Well it does at the moment. If you switch off 'readvertise files'
   people cant connect and browse your cache anyway. 'Deniablilty'
   is always there since you didnt upload these files anyway...
   its the same problem if you were to run a public HTTP Proxy
   (Squid or whatever). Routes do get 'unadvertised' when a
   connection is broken so content may become inaccssible.
   I could add another option covering this but would it really be
   useful?

4) Authentication and Ratings

   Im quite interested in crypto, and a rating system is an
   interesting idea. However, I dont want to increase the size
   of File Adverts by including public keys, descriptions, and
   so on. Now, if there were a seperate system (maybe even
   web based) that Blocks could access information from
   using the file ID (hash sent with ad) that would be a very
   different story. Another possible future option would be
   to seperate out the server code and build something like
   a library (maybe even ActiveX control) to allow much more
   complex custom front ends (you might have noticed they
   arent really my speciality) that allow extended functionality.

5) Logos

   The 2 Logos on the web page are the winners. These are now
   the Blocks logos for the foreseeable future.

6) IRC

   As long as Flaggovic hold #blocks open on DALNet I'll
   keep it listed. I may change the order to list EFNet first
   if its more popular.

Apologies if I missed any important threads.

ttfn

PG.

PS Im glad the list isnt full of bug reports! :)

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: [Blocks-development] Authentication and Ratings

[Michael S. Jr. <bl...@ms...>]

You guys have done a great job of seeing what and why, but I think you're
failing to see how this web-of-trust thing works.  (I only understand it
because once upon a time...high school, some five years ago...I was a
wannabe black hat, and I used PGP a lot.)  This isn't bad, or a failing on
your part -- most people don't really have any need for an automated
web-of-trust because you get to know each other on IRC and trust each other
that way.

The content-rating stuff can work without a web of trust...you only get
single identities that aren't related, and you have to sort out on your own
which identities you trust and which you don't.  Joe Sixpack probably trusts
Lars more than Flaggovic, because he's Joe Sixpack.  He doesn't know any
better.

WEB OF TRUST EXPLANATION

Webs of trust are freakin complicated, but keep in mind that only the people
who are very important to the network really have to get down and dirty with
the web-of-trust, and understand all this stuff.  Joe Sixpack can accept
some intelligent defaults and merely look at the red-amber-green-blank light
next to the search result.


I'll assume you guys already understand the basics of PK encryption, and all
you need to understand is the web-of-trust stuff.  If you have trouble
understanding all this, get GPG from the BlocksNet (gnupg-w32-1.0.2.zip) or
from www.gnupg.org, read the docs, and practice using it a bit.  I'll try to
be on IRC (EFnet, #blocks) later tonight, and we can try some stuff in
practice, so you get a good feel for how it works.

And for those of you who are already familiar with how PGP implements
webs-of-trust, the goals here are different:  PGP's web-of-trust certifies
that a key belongs to a particular individual, so you call the individual on
the phone and verify their identity.  Blocks' web-of-trust certifies
trustworthiness but NOT identity:  I don't care who the person is, but he's
been <making content available> for three months now, I've downloaded it
all, and it's all been good content...so I'll certify him.  PGP certifies
identity but not trustworthiness...Blocks will certify trustworthiness but
not identity.


OK, web of trust.

WHAT IS IT?

A web-of-trust is basically a collection of files that cryptographically
sign each other.  There's two kinds of key material:  a PUBLIC KEY, which is
who you're trying to certify, and KEY SIGNATURE certificates, which affirm
to the world that person A trusts person B a certain amount.

When you see the files laying there in the filesystem, they don't look like
much.  Each key has a unique identifier (that'll be about 20 hex digits
long).  If you find that you need a key for something (like to verify a
'this is SPAM' certificate) you just do a search on that key ID.  Key
signature certificates are also files that have two identifiers in them:
the ID of the key being signed, and the ID of the key that's doing the
signing.  If you just got a new key you've never seen before, just search
for key signature certificate files that have your new key's ID and a bunch
of ??????'s so you can find all people who signed that new key.

THE WEB IS WEAVED FROM SIGNATURES

So that's how nodes interconnect:  keys sign each other.  You could imagine
individual keys as points on a tree, and signatures as lines that connect
the points.  If you don't have many signatures yet, you'll have a big cloud
of points, with just a few points tied together with signatures.  If you
have a large number of well-organized signatures, you'll see one very big
tree with a bunch of little disorganized clumps here and there.

AUTOMATIC TRUST

This tree is useful so we can pass a value along the tree without human
intervention.  In this case, the value is trust -- we want the network to
tell us that we should trust this person-we've-never-seen-before.

Or in other words...we know we trust person A, because he wrote the
software.  When the system sees that A trusts B, B trusts C, and C trusts
D...we should know that we can trust D.  (The system sees all this because
it searches for keys and key signatures for A, B, C, and D, and
cryptographically verifies all the signatures.)

So this whole thing is based on this concept:  I can pick from a short list,
people I trust with my modem time.  These people I pick will pick people
they trust...and so on.  So when I trust someone very central, perhaps
Flaggovic...I will suddenly have 2000 people on my 'trusted list'.  I could
also pick my best friend Joe Warez...but his little network of friends only
spans 10 people or so.

TRUST ISN'T FOREVER

These key certificates aren't permanent:  you can also issue a 'signature
revocation' or a 'key revocation' -- if your new best friend who distributes
all the best movies turns out to be an MPAA plant and is now distributing
spam, just issue a revocation certificate.  As long as people see your
revocation as well as your original certification, they won't trust him any
more.  And the people he trusts, and so on, also won't be trusted any more.


I should be on IRC later tonight, about 2 to 3 hours from when I send this.
I look forward to making this clearer, and doing some group-participation
stuff to make this all make sense.


BTW...I don't want to reply separately, but I agree with the loss of privacy
comment ('now I can call the FBI').  I knew there was a flaw in there
somewhere.  :)


--Michael Spencer
bl...@ms...

----- Original Message -----
From: "Erik Moeller" <mo...@sc...>
To: <blo...@li...>
Sent: Monday, July 31, 2000 1:13 PM
Subject: RE: [Blocks-development] Authentication and Ratings


> On 31 Jul 2000, at 14:12, Paul Kalupnieks wrote:
>
> > But who would want to download the contents of a whole file if the
> > quality is unknown? I know I wouldn't want to sit on a 56K modem,
> > download a 10MB file and only find out it's bogus. The rating couldn't
> > be generated by the party who added it in the 1st place, since, if
> > they're creating bogus data, the file could be marked, in the same
> > way, as being just fine.
>
> You receive announcements from every node that stores the file. In
> your local index, the metadata would be joined and displayed when
> searching for the file. e.g.:
>
> Metallica.mp3
> |- Flaggovic rates this file as: SPAM, stops at 2:32
> |- Lars rates this file as: TOP, our latest album
> |- Gnome rates this file as: CORRUPTED
>
> Regards,
> Erik
> --
> Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
> Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
> The Origins of Peace and Violence: <http://www.violence.de>
> Please donate free food NOW: <http://www.thehungersite.com>
>
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development

[Blocks-development] Reworked Logo

[Erik M. <mo...@sc...>]

OK, here's a little more colorful version of the logo. I used 
gradients of the primary colors and their complementaries (rgb,cmyk), 
the gradient direction is supposed to symbolize connectedness. It 
should look good on most bright background colors.

LMKWYT.

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

[Blocks-development] Reworked Logo

[Erik M. <mo...@sc...>]

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  blockscolor.gif
     Date:  31 Jul 2000, 23:24
     Size:  3913 bytes.
     Type:  GIF-image

Re: [Blocks-development] Authentication and Ratings

[Erik M. <mo...@sc...>]

On 31 Jul 2000, at 16:24, Troy D. Strum wrote:

> Hmm, but what if Lars and Company decided that they wanted to start
> marking every Metallica file that they found as SPAM?

If I find that out, I add Lars to my killfile. Bad ratings are not 
really a problem. That's what this "trust system" is all about: You 
make experiences and learn from them.

> It seems to me that there should be some sort of check to make sure
> that the person downloaded the file completely before they could rate
> it.

We must find a way to ensure that nobody can send out an announcement 
for a file that is not available. This is also necessary to avoid 
flooding.

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

Re: [Blocks-development] Authentication and Ratings

[Troy D. S. <ts...@sa...>]

Hmm, but what if Lars and Company decided that they wanted to start marking
every Metallica file that they found as SPAM?

It seems to me that there should be some sort of check to make sure that the
person downloaded the file completely before they could rate it. This could
be some kind of hash that is reported back to the node holding the file to
verify that the content they have matches the content of the node.

This validates that they downloaded the whole file and that the file they
have matches the file on the node, preventing them from claiming that it's
corrupted on the node when it's actually their copy that's corrupted (or is
this already handled in some form or another?)

Another issue is the face that anyone can be running more than one server at
a time. What's to stop someone from rating a file from another node running
under their control?

Of course this exposes another level of trust issues - do you trust the
person(s) that are rating the file?

... then again maybe I'm confused.


- Troy Strum
ts...@sa... *change of address*
Technical Operations, Salter New Media
Halifax, Nova Scotia, Canada
"To err is human, to moo bovine."


> On 31 Jul 2000, at 14:12, Paul Kalupnieks wrote:
>
> > But who would want to download the contents of a whole file if the
> > quality is unknown? I know I wouldn't want to sit on a 56K modem,
> > download a 10MB file and only find out it's bogus. The rating couldn't
> > be generated by the party who added it in the 1st place, since, if
> > they're creating bogus data, the file could be marked, in the same
> > way, as being just fine.
>
> You receive announcements from every node that stores the file. In
> your local index, the metadata would be joined and displayed when
> searching for the file. e.g.:
>
> Metallica.mp3
> |- Flaggovic rates this file as: SPAM, stops at 2:32
> |- Lars rates this file as: TOP, our latest album
> |- Gnome rates this file as: CORRUPTED
>
> Regards,
> Erik
> --
> Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
> Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
> The Origins of Peace and Violence: <http://www.violence.de>
> Please donate free food NOW: <http://www.thehungersite.com>
>
> _______________________________________________
> Blocks-development mailing list
> Blo...@li...
> http://lists.sourceforge.net/mailman/listinfo/blocks-development

RE: [Blocks-development] Authentication and Ratings

[Erik M. <mo...@sc...>]

On 31 Jul 2000, at 14:12, Paul Kalupnieks wrote:

> But who would want to download the contents of a whole file if the
> quality is unknown? I know I wouldn't want to sit on a 56K modem,
> download a 10MB file and only find out it's bogus. The rating couldn't
> be generated by the party who added it in the 1st place, since, if
> they're creating bogus data, the file could be marked, in the same
> way, as being just fine.

You receive announcements from every node that stores the file. In 
your local index, the metadata would be joined and displayed when 
searching for the file. e.g.:

	Metallica.mp3
	|- Flaggovic rates this file as: SPAM, stops at 2:32
	|- Lars rates this file as: TOP, our latest album
	|- Gnome rates this file as: CORRUPTED

Regards,
Erik
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

RE: [Blocks-development] Authentication and Ratings

[Paul K. <pa...@nk...>]

But who would want to download the contents of a whole file if the quality
is unknown? I know I wouldn't want to sit on a 56K modem, download a 10MB
file and only find out it's bogus. The rating couldn't be generated by the
party who added it in the 1st place, since, if they're creating bogus data,
the file could be marked, in the same way, as being just fine.

On the other hand, how can anyone tell if a file is valid (other than being
corrupted or completely bogus) by only 2-3 blocks of it. In the example of
an MP3, what's stopping a given bogus file from being "valid" for the 1st
few blocks and just garbage from that point on? Even if it's been hashed,
the hash itself could be generated invalidly.

Maybe I'm just missing something from Micheals explaination. I understand
the web-of-trust model, but I'm not understanding the hash model that he's
proposing fully.

For the hash to be valid at least one other (valid) signature must sign it?

-----Original Message-----
From: Erik Moeller [mailto:mo...@sc...]
Sent: Monday, July 31, 2000 1:51 PM
To: blo...@li...
Subject: Re: [Blocks-development] Authentication and Ratings


I cannot emphasize enough how important authentication and ratings 
are for a system like Blocks. Just think of the "Stop Napster" crap --
so far, not a single file-sharing system has come up with a solution 
to avoid intentionally mislabled or corrupted content.

I'm not sure I understand your web-of-trust concept completely. 
Here's my understanding of a possible implementation, correct me if 
I'm wrong. I'm using the term "announcement" instead of 
"advertisement".

- Every announcement includes 
		- the filename and location
		optionally:
		- a human-readable nickname
           + if it already exists, a new one with a 
             running number is created, e.g. Flaggovic_2
	 	- the public key belonging to this nickname
		- a short string rating the file's quality
		  and describing its content (should be done
		  using pre-defined labels and categories
	      to save bandwidth)

If this metadata exists, it is encrypted and signed with the public & 
private key.

Does this make sense? How do we make sure that an IP address is not 
associated with a nickname?

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

Re: [Blocks-development] Authentication and Ratings

[Erik M. <mo...@sc...>]

I cannot emphasize enough how important authentication and ratings 
are for a system like Blocks. Just think of the "Stop Napster" crap --
so far, not a single file-sharing system has come up with a solution 
to avoid intentionally mislabled or corrupted content.

I'm not sure I understand your web-of-trust concept completely. 
Here's my understanding of a possible implementation, correct me if 
I'm wrong. I'm using the term "announcement" instead of 
"advertisement".

- Every announcement includes 
		- the filename and location
		optionally:
		- a human-readable nickname
           + if it already exists, a new one with a 
             running number is created, e.g. Flaggovic_2
	 	- the public key belonging to this nickname
		- a short string rating the file's quality
		  and describing its content (should be done
		  using pre-defined labels and categories
	      to save bandwidth)

If this metadata exists, it is encrypted and signed with the public & 
private key.

Does this make sense? How do we make sure that an IP address is not 
associated with a nickname?

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

Re: [Blocks-development] Avoiding malicious content-dilution through PKI encryption

[Erik M. <mo...@sc...>]

On 30 Jul 2000, at 22:39, Michael Spencer Jr. wrote:

Sorry for the duplicates, Michael. The list doesn't seem to use the 
"Reply-To" field so I had to select the recipient manually.

> On #blocks in EFnet we were talking about what happens when a file 
is
> routed across another node -- it seems once all of the blocks pass
> through an intermediate server, that intermediate server then knows 
it
> has a copy of the file, and advertises that copy as well.
> 
> The only problem with this is...if I search for * and find
> questionable content in my own cache, legally it should be my
> responsibility to leave and rejoin the network to remove that 
content
> from my server, since I can directly see that my own cache is
> providing the content.

[...]

> In the change I'm proposing...suppose my client keeps the blocks
> cached, but doesn't advertise the completed file.  Once the download
> is complete, other clients only see search results with routing
> entries AF, but the data comes directly from me.  Suppose the leaf
> node disconnects...now routing entry F on my client is invalid. 
> However, the file is still known to the rest of the network as on AF
> (for example).  If a client again tries to download AF, ideally
> instead of returning that the route is no-longer valid, my client
> should return the cached blocks, not revealing the fact that my 
node F
> has disconnected.
> 
> Wait a minute...there seems to be a hole in my logic somewhere.  Can
> someone help me find it?

Doesn't that make the originator of information easier to find? I 
would only have to know which IP number is "F" and then I could call 
the FBI.

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

[Blocks-development] (no subject)

[Spencer Jr., M. <sp...@ac...>]

I'd like to begin implementing my earlier crazy idea for content
verification and certification.

Remember that the object is to make it possible to publish a file such that
you can still remain anonymous but the general public still has some idea
that the content you're publishing is meaningful and worth downloading.
That is...I can publish an mp3 and Joe Sixpack can easily tell that this mp3
file I published really contains the song that's listed in the title.  Mr.
RIAA Consultant can publish an mp3 with a popular song's name, containing a
'public service announcement' or dogs barking or bells ringing or something
like that...and Joe Sixpack can easily tell that this is a bogus file
without taking the time to download it, and without getting frustrated with
the network.

In case I haven't made it clear before, the idea is that data will still
replicate and be reshared as before...there could be 50 copies of The Matrix
parts 1 and 2 out there.  However, when someone with a trusted public key
downloads one of these copies and finds that it's legit content, he can sign
the content and publish his signature.  People can download the
signature...download enough key material to decide whether or not they trust
his signature...and then affirm that all 50 of these copies (which are all
exactly the same) are good copies.  They can also determine that the 5 or 10
bad copies...corrupted, or malicious planted files meant to waste peoples'
time...are really bad (or at least, uncertified) content.

The first step here is to have a way to uniquely identify a file without
downloading it -- a secure hash of the file.  I'd like to make this 'secure
hash' a feature request to implement rather quickly.

What's a secure hash?  Well, what's an insecure hash?

The object of all this is to save people some downloading time -- you don't
want them to download a file only to find out it's not what they thought it
was, especially if it's a several-hundred MB movie file.  We're going to be
applying PKI certificates to these signatures...so a user is going to look
at just the hash, not the file, and decide whether or not to download the
file.  An attacker is going to attempt to foil the system by returning
search results that match known-good content, but when you download the file
that supposedly matches the hash, it's not the same file.  Of course, when
you run the hash yourself after you've downloaded the file, you'll see the
delusion -- the hash you come up with doesn't match the hash the file
publisher provided...but the damage has already been done.  You downloaded
the file, wasting your bandwidth and frustrating yourself.

A secure hash would have to resist this.  How?  Block hashes.  If this works
as it's supposed to, you will only waste a maximum of one block's worth of
bandwidth downloading bogus files.

Here's my idea so far...if you see any weaknesses or problems, please help
us strengthen it -- we'll only get one shot to do this right before the
network starts going into widespread usage.

When you get a file advertisement you should also get a three-part hash with
the file.  The first part should be a whole-content hash (like normal), the
second part should be a long multiple-block hash with one hash value per
data block, and the third part should be a hash of all the multiple-block
hashes taken together.  (You're going to use the third part to check the
second part for corruption...and you're going to compute and use your own
value for this third one anyway when you search.)

This hash should provide two things:  a unique identifier you can use to
search for certificates on the network (probably the first and third hashes
concatenated), and a set of periodic checks you can run on the file while
you're downloading it, so you can tell if you're downloading what you're
supposed to be downloading and abort the download if necessary.

(Was that pretty clear on how this should be implemented?  Questions and
comments?  :) )

So this can resist different kinds of attacks:

1)  totally bogus content with a hash that matches good content.  This is
defended against because once the client downloads and checks the first
block, they can see the file is bad and immediately stop the download, after
only downloading one block.

2)  partially-bogus or halfway-completed content:  the client will continue
to download the content until it reaches the first bad block, and then
abort.  I would say this is a good condition, but at present Blocks doesn't
support resuming downloads.  (Once we have reliable content hashes we can
securely and confidently resume downloads)


On a related note...download resumes!  Once we have per-block and per-file
hashes that get sent around with the file adverts, we can trust other hosts
that claim to have the same data...or we can automatically download from
other hosts that have the same data if the current download fails.

Of course, all this is just 'application layer' stuff -- the network layer
is top priority, and I have no right to 'demand' a feature.  If a change
needs to be made for the health of the network (or for other peoples'
ideas...I'm not the only one here with good ideas and plans) then by all
means, implement that first.  But if there are no other changes in mind...

0.15:  implement sending whole-file and block-by-block hashes along with the
file adverts.  Add someplace in the client UI to save the hash information
to a text file, so we can do sample crypto stuff by hand.
0.16:  implement checking downloads against the advertised hashes, and
aborting downloads if a received block doesn't match the block hash.
0.17:  implement download resumes from the same and multiple sources, using
the (now debugged and tested) hash stuff.

Then we get to have fun with PKI crypto!  Hope I can find a few interested
bodies willing to learn how to use GPG, and do a LOT of cutting and pasting
into and out of text files.  We will need to get a general flowchart going
for how the client can automatically check and sign content and all that, so
we can later make the Blocks client do that automatically.  Then we need to
try to break it, so it doesn't die when the system comes under attack.

Sounds like fun, right?  Just think of the positive press we'll get later
on.  :)

(Just in case this project becomes famous later down the road...if you are
press or media viewing mailing list archives, these comments are owned by me
and I do *not* license anyone to snip bits and pieces of this post, looking
for things to quote out of context.  If you reproduce this post, reproduce
it in its entirety.  I encourage everyone else on this list to say something
like this at the end of their longish posts as well.)

--Michael Spencer
bl...@ms...

Re: [Blocks-development] Content caching and replication...and deniability

[<lu...@et...>]

* Michael Spencer Jr. wrote:
> [snip]
> In the change I'm proposing...suppose my client keeps the blocks cached, but
> doesn't advertise the completed file.  Once the download is complete, other
> clients only see search results with routing entries AF, but the data comes
> directly from me.  Suppose the leaf node disconnects...now routing entry F
> on my client is invalid.  However, the file is still known to the rest of
> the network as on AF (for example).  If a client again tries to download AF,
> ideally instead of returning that the route is no-longer valid, my client
> should return the cached blocks, not revealing the fact that my node F has
> disconnected.
> 
> Wait a minute...there seems to be a hole in my logic somewhere.  Can someone
> help me find it?

Your logic looks sound to me, but I think there may be more going on under the
hood than you think.  Perusing the code I saw a message that seemed to be
fore 'unadvertising' a route when a connection goes away.  If this
were done then, in your example, the route 'AF' would be unadvertised and
you'd be holding a file in your cache for no reason.

On a related note, I'm getting the impression that files fall out of
the cache when they're replaced by something "fresher".  This seems
to include things I've shared from my local drive, though, so I 
have to keep re-adding them to the cache every so often.  Is this
really the case?  Perhaps there should be two caches, one "sticky" and one
for files that are "just passing through"?

-Luke

FW: [Blocks-development] Content caching and replication...and de niability

[Paul K. <pa...@nk...>]

No, that seems to make sense to me. If the data exists on a node other than
the originating one, 
why couldn't the remaining node continue to serve the file, unbeknownst to
the rest of the network?

What bothers me is what happens when a new node connects? That host would
then become node F and 
all the adverts routing to it would be invalid. Even if the route exists,
the file won't. 



-----Original Message-----
From: Michael Spencer Jr. [mailto:m...@ms...]
Sent: Monday, July 31, 2000 7:29 AM
To: blo...@li...
Subject: [Blocks-development] Content caching and replication...and
deniability


On #blocks in EFnet we were talking about what happens when a file is routed
across another node -- it seems once all of the blocks pass through an
intermediate server, that intermediate server then knows it has a copy of
the file, and advertises that copy as well.

The only problem with this is...if I search for * and find questionable
content in my own cache, legally it should be my responsibility to leave and
rejoin the network to remove that content from my server, since I can
directly see that my own cache is providing the content.

The rest of the network already has file advertisements saying that the file
is available through one or more hops past myself.  Wouldn't it be better to
leave the encrypted blocks unassociated with a file on my own intermediate
server, but to let the associations already made by the existing file
adverts still have people get content through me?

Or for an example...let's say I have a leaf node connected to me, and that
leaf node offers a file.  Someone on the other side of me downloads the
file -- that file's blocks must pass directly through me.

When the leaf node offered the file, my client broadcast the file and a
routing entry...let's say the leaf node was my connection F...the file being
offered might have routing entry AF in your search results.

When you download the file, the file's data must pass through me to get to
you.  As your machine downloads the blocks, they get cached on my server
also.

In the present system, once my client sees that it has all of the blocks the
leaf node was offering, my client also makes a file advert for that file --
so if you search you get the file with routing entry AF and another copy of
the file with routing entry A.

In the change I'm proposing...suppose my client keeps the blocks cached, but
doesn't advertise the completed file.  Once the download is complete, other
clients only see search results with routing entries AF, but the data comes
directly from me.  Suppose the leaf node disconnects...now routing entry F
on my client is invalid.  However, the file is still known to the rest of
the network as on AF (for example).  If a client again tries to download AF,
ideally instead of returning that the route is no-longer valid, my client
should return the cached blocks, not revealing the fact that my node F has
disconnected.

Wait a minute...there seems to be a hole in my logic somewhere.  Can someone
help me find it?

--Michael Spencer
bl...@ms...


_______________________________________________
Blocks-development mailing list
Blo...@li...
http://lists.sourceforge.net/mailman/listinfo/blocks-development

[Blocks-development] Content caching and replication...and deniability

[Michael S. Jr. <m...@ms...>]

On #blocks in EFnet we were talking about what happens when a file is routed
across another node -- it seems once all of the blocks pass through an
intermediate server, that intermediate server then knows it has a copy of
the file, and advertises that copy as well.

The only problem with this is...if I search for * and find questionable
content in my own cache, legally it should be my responsibility to leave and
rejoin the network to remove that content from my server, since I can
directly see that my own cache is providing the content.

The rest of the network already has file advertisements saying that the file
is available through one or more hops past myself.  Wouldn't it be better to
leave the encrypted blocks unassociated with a file on my own intermediate
server, but to let the associations already made by the existing file
adverts still have people get content through me?

Or for an example...let's say I have a leaf node connected to me, and that
leaf node offers a file.  Someone on the other side of me downloads the
file -- that file's blocks must pass directly through me.

When the leaf node offered the file, my client broadcast the file and a
routing entry...let's say the leaf node was my connection F...the file being
offered might have routing entry AF in your search results.

When you download the file, the file's data must pass through me to get to
you.  As your machine downloads the blocks, they get cached on my server
also.

In the present system, once my client sees that it has all of the blocks the
leaf node was offering, my client also makes a file advert for that file --
so if you search you get the file with routing entry AF and another copy of
the file with routing entry A.

In the change I'm proposing...suppose my client keeps the blocks cached, but
doesn't advertise the completed file.  Once the download is complete, other
clients only see search results with routing entries AF, but the data comes
directly from me.  Suppose the leaf node disconnects...now routing entry F
on my client is invalid.  However, the file is still known to the rest of
the network as on AF (for example).  If a client again tries to download AF,
ideally instead of returning that the route is no-longer valid, my client
should return the cached blocks, not revealing the fact that my node F has
disconnected.

Wait a minute...there seems to be a hole in my logic somewhere.  Can someone
help me find it?

--Michael Spencer
bl...@ms...

[Blocks-development] Man pages & other documentation (fwd)

[Benjamin M. B. <br...@kr...>]

I'll volunteer to write the Man pages / documentation for the project if
you wish. I'd also like to note that I got the linux port done, so write
to me if anyone wants it. Thanks, 
Ben

[Blocks-development] Adding multiple files

[Erik M. <mo...@sc...>]

The upload requester does not seem to allow uploading multiple files. 
It's therefore very hard to add a collection to Blocks. This should 
be changed.

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

[Blocks-development] Avoiding malicious content-dilution through PKI encryption

[Michael S. Jr. <bl...@ms...>]

I posted this to the GnutellaNG working group message board a while back,
and the idea wasn't met very well.  It seems this idea isn't really in line
with the Gnutella project's goals.

Since this project is rather new, maybe we'd like to implement this in
Blocks.


-----Begin snipped post from GnutellaNG message board-----

I originally posted this message on the GnutellaDev message board. It seems
to fit in better with the existing content at GnutellaNG.

I'm repeating a lot of information you guys already know, so please forgive
the discussion of public-key cryptography and web-of-trust systems.

Also posted this to slashdot on a thread about jamming Napster with
mislabeled content. It got moderated up to 2, so it probably didn't even get
read. :(

I believe what's needed is a distributed content- and host-verification
system based on public-key cryptography signatures and a web-of-trust. (GPG
sources could be used for the PK crypto) I don't really have a good response
for the privacy concerns about plastering persistent identities all over the
content out there...but that's just one of many things that need to be
discussed.

For those unfamiliar with the distributed web-of-trust implemented in the
original PGP release: the idea is that using public-key crypto (where the
encryption key has two halves, a public- and a private- half, which are
linked in a very special mathematical way...what you 'do' with one half
requires the other half to 'undo') you can place signatures on things --
include a hash of the content, create a message using your private key which
can be verified by your public key.

In the PGP world this is used to create a web-of-trust: if you have a key
owned by a person you trust (say, your very technical neighbor John) you
might trust two things about his key: you might or might not trust that his
key will remained owned by him (trusting the identity of the key) and you
might or might not trust the integrity of the owner in certifying other keys
(trusting the integrity of signatures made by the key). So you could trust
the key of a complete sociopath, merely saying that you know the key belongs
to him personally...but you don't exactly trust his signatures on other
peoples' keys. Or you could trust both the key and the signatures of your
neighbor John -- not only do you believe his key belongs to him personally,
but you believe that when he puts a signature on some third-party key out
there, then that third-party key probably really belongs to that person.

In Gnutella, this could be used to maintain a distributed database of
trusted individuals and servers (anonymity will be discussed later) and
trusted content. The effect will be that, for a given user, once he's taken
the time to tell Gnutella how accurate the songs he downloads are...these
songs weren't what their filename claimed they were, while these other songs
were accurate and of X quality...he can publish signatures affirming to
other users that files with X length and Y CRC really do contain Q content.
Another user who trusts his signature can then trust files signed by him.

In the simplest case, this system would consist of a separate database of
content signatures. When you get a search result from the servlet you're
interested in (which contains a filename, size, and CRC) you do another
search (perhaps in another network altogether) to find signatures for that
file and public keys to verify the signatures with. Each key represents an
individual, and each signature represents a public certification made by
that individual about that content. Without a web of trust, all I really get
from this is a cryptographically strong way of tying identities to content
certifications. I have no idea how trustworthy the identities are.

This simplest case can be easily attacked -- I'll build onto it soon.
Obviously, just as quickly as I can create signatures that certify good
content as good and bad content as bad, the 'AIAA' (attacking Industry
Artists Association) can create identities and signatures that certify good
content as bad and bad content as good. So I've only gained ground if an
arbitrary user can learn, either from a web page or IRC or whatever...that
signatures made from my key are accurate and signatures made from other keys
are always inaccurate. The target audience isn't going to want to find and
add their own content certification keys.

A more realistic example would implement a web-of-trust. We now have key
signatures as well as content signatures: in the keyring management section
of my client, I can investigate the keys I know about, by searching for key
signatures for the key in question. My which-keys-can-I-trust problem is
still there, but easier to overcome now: if we have a few definitely-trusted
keys (like the original authors of Gnutella, or known information freedom
advocates), those keys can delegate trust to people by signing their keys.
Big deviation from the PGP web of trust model here: in PGP you're merely
certifying the ownership of the key when you issue a signature. How much you
trust an individual is never published by PGP. In the system being discussed
here, you are interested in trust more than identity, so you publish trust
information. Trust is published by issuing a key signature certificate out
into the network, and it's revoked by issuing a key signature revocation
certificate.

A client can verify a given key's trustworthiness by the signature path from
the known-and-trusted keys. If a key is signed directly by a
known-and-trusted key, it's also pretty well trusted. If a key is signed by
someone who is signed by someone who is...eventually signed by a trusted
key, trust will be established, but with lower confidence. Most likely, the
given key will have many many signatures with a fault-tolerant signature
path leading back to the trusted keys. If we suppose that one of the
original trusted keys' "trusted lieutenants" (keys signed directly by one of
the original trusted keys) were to go bad and start signing AIAA keys and
start certifying bad content, the original trusted key owner would revoke
the trust granted to that individual. All keys signed by that individual
would no-longer benefit from that individual's trust. That doesn't mean they
become untrusted...but we should hope they have some trust-granting
signatures other than derived from the bad individual...because the bad
individual's signature is no-longer meaningful.

This model is more likely to survive attacks. Keys that create bad content
signatures simply never get marked as trusted. Keys that were once trusted,
but have now began creating bad content signatures and signing other bad
keys, have their signatures revoked and are no-longer trusted.

This trust network can be self-starting, also. The client software should be
able to catalog all of the content and key signatures made by a key. If a
particular client can directly measure the 'decisions' made by a key --
checked that its files really are the way it claims they are, and checked
that the other keys signed by this key seem to be trustworthy (ugh,
recursion) that client can decide to trust that key (partially or
completely), thus making another 'root' of the trust tree. To put it another
way, the client could also compare the decisions 'influenced' by a key --
which content signatures would become trusted if that key was trusted -- and
compare those content signatures to the overlapping content signatures made
by the existing trusted network...the client could measure how trustworthy
the key might be.

In practice, it seems silly to require processing several public-key crypto
operations and finding and downloading many key certificates and files, to
tell whether a given content file is worth downloading or not. However...we
don't have to use Gnutella to transfer keys and signatures: I imagine
Freenet might be more appropriate for this kind of content. (So yes, besides
adding the GPG source to Gnutella, I'm proposing merging Gnutella with
Freenet someday, using Freenet for key distribution.) Also, each client will
need to keep a keyring, retaining the keys and signatures that pertain to
the content it's downloaded and the keys it uses frequently.

Assuming a trust network that fans out quickly, with each influential key
signing dozens of other keys instead of two or three, it may only require
three or four dips into the distributed keyserver to verify content. The
client could verify content in the background...coloring a search result's
icon from red to yellow to green as it gets more of the key and certificate
material it needs.

The only major concern left is privacy and anonymity. These keys are
personal identities: for a key to be effective it must be maintained by one
person. However, the key and the identity might not be obviously-related:
the network won't expose where a key's signatures are entering the network
from, and keyring files must be seized or stolen to confirm that any given
identity belongs to a specific computer. In addition to that, these keys can
be detached from their identities if the owner destroys his private key. The
existing signatures made by that orphaned key still stand and are still
meaningful, but nobody can tell what individual once owned that key.

It is probably not illegal to help maintain a web of trust. It's probably
illegal to host the content directly, and it might be somewhat illegal to
directly publish signatures that confirm that someone else's content is what
it claims to be (affirming to the world that you personally downloaded the
content and confirmed that it was good). However, it's probably not illegal
to sign someone else's key, attributing trust to them. All you're really
saying is that you trust them to sign only good content -- and you have no
idea whether that content is legal or not.

In the Gnutella interface, this web-of-trust system would probably be seen
as a key-management screen, a content-rating screen, and as trust levels
displayed next to each search result. In the content-rating screen you could
look at the content you have downloaded and rated (good/bad, or several
more-specific ratings), and who has signed the content. In the
key-management screen you could look at the keys you know about, what
content the keys affect, and how your ratings compare with trusted or
untrusted keys' ratings. When you get search results, a summary content
rating can be displayed next to each search result. The system can calculate
ratings either on-demand (right-click -> Investigate) or automatically (i.e.
search results returned < 50), and can explain and graph those ratings for
you (I trusted this file because these people certified the file.)


This file represents a vision for the kinda-distant future...but it will be
realized only if people get excited about it and work to implement it. If
you personally don't understand part of the discussion presented here, or if
I forgot to explain something, or if something doesn't make sense, please
post here in the forum and/or email me at gne...@ms....

Thanks for reading. This idea is *yours* now -- please do your part to help
it become reality.

-----End snipped post from GnutellaNG message board-----


This is a LOT to chew on, and my ideas have evolved a little since then...

this idea is posted here for everyone's benefit -- if any individual reader
has questions or comments, or doesn't understand something (because not
every code hacker on the planet has used GPG...don't feel bad, we won't
blame you) please feel free to reply publicly or in private email.

Thanks!

--Michael Spencer
bl...@ms...
(person running that public server, 209.180.104.204:9912)

Re: [Blocks-development] About the logo

[<lu...@et...>]

* Luke Hankins wrote:
> Is there a place where the logos can be viewed on the web?  Or are they
> on blocknet somewhere?

Boy, I'm an idiot.  Of course they're up on blocknet. :-)

Never mind.  I'm going to bed now.

-Luke

Re: [Blocks-development] About the logo

[<lu...@et...>]

Is there a place where the logos can be viewed on the web?  Or are they
on blocknet somewhere?  I'll put 'em up on my node if someone gets 'em to
me. :-)

-Luke

[Blocks-development] About the logo

[Erik M. <mo...@sc...>]

It's your decision. Here's the reason I made it the way it is:
8 parts (8*8=64 - parts=distributed network), arranged like a moving 
puzzle: one space left for moving the parts. Blocks rearranged -> 
picture changes, but information can be reassembled (anonymity, 
encryption). New block enters: open network. Main requirement for 
professional logos is simplicity: rule=if it can be drawn on paper by 
anyone, it's simple enough. Also works in b/w. 

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

[Blocks-development] IRC

[Erik M. <mo...@sc...>]

The official #blocks channel should be on EFNet. DALNet tends to be 
not as populated, and people try EFNet first. Just remove DALNet from 
the main page.

(It's bad to have two channels because it splits you when you're 
trying to chat.)

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

[Blocks-development] Logo & redesign

[Erik M. <mo...@sc...>]

Here's a version of the logo without the stupid slogan, and a 
redesign of the main page. I have changed no content, but I've added 
some headlines and horizontal lines. I've also copied some text from 
the description into a "Abstract" on top of the page. You're free to 
use whatever you want.

Regards,
Erik Moeller
-- 
Scientific Reviewer, Freelancer, Humanist -- Berlin/Germany
Phone: +49-30-45491008 - Web: <http://www.humanist.de/erik>
The Origins of Peace and Violence: <http://www.violence.de>
Please donate free food NOW: <http://www.thehungersite.com>

[Blocks-development] Logo & redesign

[Erik M. <mo...@sc...>]

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  blocks.html
     Date:  31 Jul 2000, 3:46
     Size:  12398 bytes.
     Type:  Unknown