RE: [Blocks-development] Doh!

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

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.

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.

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.

'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.

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?
:) )

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

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


-----Original Message-----
From: Blat Froop [mailto:pet...@ho...]
Sent: Tuesday, August 01, 2000 8:41 AM
To: blo...@li...
Subject: Re: [Blocks-development] Doh!


>From: "Benjamin M. Brewer" <br...@kr...>
>To: Blat Froop <pet...@ho...>
>CC: blo...@li...
>Subject: Re: [Blocks-development] Doh!
>Date: Mon, 31 Jul 2000 22:01:21 -0400 (EDT)
>
>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?

More likely I'll try and add a 'choose directory to upload' menuitem until I

can get around to building an upload widget.

>
> > 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.

Hmmm... dunno modemers simply dont have the bandwidth for
to broadcast file advertisements, and all the joining and
disconnecting creates a lot of routing traffic.

>
> > 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.

How much information (in bytes) do you estimate would be required
as a minimum to be associated with File Adverts to add public keys
and whatever else would be needed?

There is the option of having a second block of descriptive info.

I still have to get my head around how these things would work.

>
> > 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...

Done.

>
> > 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.

DALNEt is dead, long live EFNet.

>
>PS, did you get those linux-binaries?

On new page!

ttfn

PG.

________________________________________________________________________
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