[Blocks-development] Authenticaion, Ratings, WoT

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

>From: "Spencer Jr., Michael" <sp...@ac...>
>To: 'Blat Froop' <pet...@ho...>, 
>blo...@li...
>Subject: RE: [Blocks-development] Doh!
>Date: Tue, 1 Aug 2000 10:40:50 -0500
>
>Quick summary:
>
>I want to start off by restating...I want this file verification stuff to
>have *minimal* impact on how the network functions.  Here at first, none of
>us are even sure a web-of-trust is even the right thing to do.
>However...all I need from the network right now is an identifying hash --
>I'm not asking anyone to code a web-of-trust without any proof that it'll
>work.  I'll make the web-of-trust myself, using command-line tools and
>uploading 'key material' files into the network.  Then once I get things
>figured out a bit, I'll write up procedures and we can all walk through 
>this
>web-of-trust by hand.  If and only if we all see how it works and we like
>it, we might add some code to the Blocks client to do the gpg stuff
>automatically.

This sounds like a promising approach.

>
>OK, here's how I *think* the file verificaton stuff would need to work:
>
>LAYER OF PROTOCOLS
>
>I think to get file verification information in a secure way, the system
>needs to be multi-layered...so the network protocol can stay as simple as
>possible, and all this extra stuff can be done by custom client code.  That
>is...I think the network layer (which I am NOT an expert in the design of)
>needs to stay as simple as possible, and as close to the existing design as
>possible.  If someone wants to run an old legacy client they should be able
>to...but they will see a bunch of strange files 'Blocks-filesig-XXXXXXXXXX'
>and 'Blocks-pubkey-XXXXXXXXXX' and all that.  And they won't be able to
>verify content automatically.

Remember Blocks currently has a hardcoded filename limit of ~85 characters.

>
>NETWORK LAYER
>
>The network layer should be almost completely unchanged, in my opinion.  I
>can see how we want to make content verification as simple as possible, and
>bundling verification data with the data files makes the search faster and
>easier.  BUT...I don't feel that we should bundle the verification data 
>with
>the files because for the system to be truly secure, *anyone* needs to be
>able to advertise data about *anyone else's* files.
>
>I do feel that we need to be able to have some kind of persistant hash of
>each file on the network.  I think Peter was OK with adding a few dozen or
>so extra bytes to the file adverts.  I think those bytes should contain a
>file hash which of the original data, not a hash of the encrypted data
>(which is different each time a file is uploaded).  I was talking before
>about block hashes and a separate hash of the block hashes...but that's 
>only
>needed if we need to face corrupted clients that send out false hashes.  We
>can do that stuff later.

How much hash do you want. 128bits is available but the current
advert mechanism encodes everything as hex (hey, it was easier
to debug :-) so it would add at least 32+1 chars to the advert
size... which is probably not significant.

Also, you want me to display the hash in the serach window... do
you want to see the full thing?... 32 chars is quite long for
human readers (and makes the listbox pretty wide).

>
>'CRYPTO' LAYER  -- A TRUSTED MESSAGE BOARD
>
>Remember that public-key crypto lets you publish trusted information in an
>untrusted space.  So if you have a known-good copy of Peter Gunn's public
>key, then Peter Gunn can make a statement, publish it on Blocks...you don't
>need a central server, and you don't need to care who you download it from.
>In all other cases, the content *could* be bogus because you don't know who
>you're downloading from...but because Peter Gunn signed his statement with
>his private key, you can verify the content with Peter Gunn's supposed
>public key and trust that the content really was said by him.  So if that
>statement-by-Peter-Gunn is an automatically-processed message saying
>"1.2.3.4 is a malicious client...do not connect there" you can completely
>trust that statement.
>
>On IRC last night, some of us had some very good ideas for
>content-protection things we could do with a central, trusted message board
>or server somewhere.  This public-key crypto lets you have that message
>board, but makes it fault-tolerant.  You can scatter the crypto stuff out 
>to
>the winds, and as long as you can search for it and find it when you need
>it, you can put it all together again and make a trusted message out of it.
>
>So I'm saying that centralization is bad -- we shouldn't really have a
>central server -- we should take those messages and turn them into crypto
>files and store them on the Blocks network.  But a message board is good --
>we had a lot of good ideas about what we could do if we had a central
>server.  What I'm saying is...if we use pub-key cryptography instead of a
>message board, all those cool ideas will still work.  And you can't sue or
>shut down a tree of crypto data...you can shut down or hack a single 
>server.
>
>VERIFICATION STUFF
>
>Once we have a trusted message board, we can post useful 'automated
>certificates' on it.  This is where my idea ends -- I just think that 
>Blocks
>can offer what no other network can offer right now, if it implements that
>shared message board stuff.  It's up to you guys what to do with the shared
>message board:  post human-readable comments perhaps, or just post 
>automatic
>certificates that the clients out there should use.  Some neat uses could
>be:  warnings about flooding clients or content, content spam-ratings,
>content usefulness-ratings, human-readable reviews and comments about
>content, etc.
>
>Everone else in IRC last night had better ideas about how to use this than 
>I
>did.  I'll leave this part to you guys.

I would also like to make sure that Blocks is useable without having
to rely on the WoT... since a significant number of people wont
really want to validate output all the time. Guess that just boils
down to another 'option', but I thought I'd say it anyways.

>
>BUT TO SUMMARIZE...
>
>Right now all I need to make this happen is content hashes.  I know 
>protocol
>changes are a bitch, but I propose a one-time change:  just lengthen the
>file advert data to include a bunch of bytes.  Compute a content hash
>(RIPE-MD128?) of the original file data, not the encrypted data, and 
>include
>it with the file advert.  Make the extra data twice as long, though, for a
>'reserved field'.  (Later on I'll make a convincing argument for the hash 
>of
>block-hashes...but since we're not likely to have to fight against bogus
>client programs for a while now, we can put this off.  Famous last words?
>:) )

Ok, I think I know how to add the content hash to the advert
in a backwardly compatible fashion, it will still take a little
fiddling though.

>
>So does this make sense?  I'd love to have questions to answer or 'devils
>advocate' scenarios to play with.

Im sure this discussion will go on for a while. Hopefully I can
get a new version of Blocks out next week sometime with half
a dozen of the suggested 'tweaks' in it.

ttfn

PG.

PS Sensible titles for the archive please :-)

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