Re: [Blocks-development] Mixnets, libblocks, datagrams

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

>From: "Michael Spencer Jr." <m...@ms...>
>To: <blo...@li...>
>Subject: [Blocks-development] Mixnets, libblocks, datagrams
>Date: Sat, 10 Mar 2001 16:45:27 -0600
>
>I've been pouring over the Blocks 0.17 source this morning, and am having
>lots of evil thoughts.  :)
>
>I'm ignoring libsock, because the traffic is supposed to be encrypted
>anyway -- we should never be stepping around libblocks and sending
>unencrypted data.
>
>It looks like GPG source integration is going to be hairy.  They have an
>existing project, gpgme, which is supposed to be a portable "GPG Made Easy"
>library for use in applications.  Unfortunately, it doesn't seem to want to
>compile in MS Visual Studio -- the documentation plainly states that you
>need to use GNU tools for Windows to compile this.  (The rest of Blocks
>compiles just fine in MS VS 6, and even comes with a workspace file
>ready-made for it.)

I have been very unimpressed by the portability of encryption
software in general. Nearly all of it has no platform specific
features beyond a couple of rotate macros, yet it is rare that
you find anything that is not overoptimized, overcomplex
and platform specific. This was one of thereasons why I
implmented my own crypto in Blocks. Its fun as well :-)

>
>A lot of GPG seems to be framework and compatibility code -- figuring out
>what pieces to use where, and encapsulating everything in easy-to-transport
>packets.  Perhaps we can just take the functions we need, and port the code
>to the same multiplatform standards Blocks already uses.  What do we need 
>to
>be able to do?  Generate a keypair, encrypt-with-pubkey,
>decrypt-with-seckey, sign-with-seckey, verify-with-pubkey...correct?  If we
>decide that GPG integration is the way we want to go, should we approach 
>the
>GnuPG dev mailing list with a request for advice?

I would definately go down this route, but be warned, crypto
is a prime fighting ground for people trying to entrench
algorithms and influence on future standards. For instance,
P1363 is largely the result of companies playing tech warfare
for part of the future crypto market.

IMHO all public key crypto is a white elephant. There can
never be trusted certificate authorities over the public
internet, and even the PGP WoT is very limited and subject
to fraud. Security is about guarantees, and IMHO PGP WoT
falls short of pretty good protection. Absolute authentication
based on short memorable secrets is the only obvious
future direction, but this would require the demise of
the current corporate PKI incumbants.

>
>------
>
>I made a post to Infoanarchy last night that contains a rather neat idea.
>Since the content index is the legal target right now, suppose we use 
>mixnet
>routing to hide one or more 'central' content index servers in the Blocks
>network?  One or more nodes would serve as collections of file adverts, and
>search requests and results would go through the Blocks network, using an
>'encrypted tunnel' through the Blocks network.

So you would be using Blocks as like a VPN packet switching
relay network. I think something like AT&T's Crowds project
would probably be a more direct and elegant solution to
hiding central servers, or rather communication beween the
client and server.

>
>For this 'mixnet' protection to work, index servers will need to have
>special anonymity protection from the rest of the network.  Any one
>untrusted user can run three or four blocks nodes on his own machine, 
>making
>a search request appear to have come from farther down the network...so we
>can't chance revealing the index server's identity through an untrusted
>connection.
>
>The buddy-list approach seems useful here.  If one index server has three 
>or
>four peers he knows and trusts, the server can expose its service through
>those peers.  To protect against connection spoofing, trusted peers should
>probably authenticate to each-other with a public-key handshake...although
>an internal list of trusted IPs will probably work for now.
>
>I'm not saying that index servers need to be completely isolated from the
>public network -- if they're worried about their index server getting them
>in trouble, though, they should only expose index services through trusted
>connections.  They're free to route data blocks and datagrams.

Why not make the index servers initiate the connection? They
could have a list of 'clients' they want to connect to and
connect to each in turn. That way ISPs couldnt even accuse
people of running servers at all and its pretty much guaranteed
(bar routing attacks) that noone but the correct audience get
direct connections.

>
>Broadcast traffic is greatly reduced then...because we're only broadcasting
>index server availability and/or index server location requests.  These
>requests can be cached.  It seems that after index server adverts, most of
>the traffic is then point-to-point routed traffic.
>
>Hmm...there's only one problem:  if the server and the client are 
>introduced
>to each other through an index server, how does the index server know what
>the fastest path between the two machines is?  The only path between the 
>two
>machines that's known is the path from server to index concatenated onto 
>the
>path from index to client.

You could gather statistics about the latency between connections
and add them up. Then you would just need to solve the 'travelling
salesman problem' to find the quickest route. Of course, the
men in black might be able to use this information as well :-)

>
>Perhaps the index server can forward a 'download request' from the client 
>to
>the server, and the server could send out a broadcast file advert...but
>encrypted so only the requesting client machine can read it.  The download
>can then continue through the shortest direct route.
>
>------
>
>This seems to call for a couple of changes to the libblocks API, if this is
>a good enough idea to implement:
>
>1)  a send-datagram function and a receive-datagram notification callback.
>2)  a way to negotiate an encrypted datagram tunnel between two hosts
>several hops apart on the network.
>
>...and later on...
>
>3)  broadcast index-server advertisements and index-server requests, and
>internal lists of recent index-servers
>4)  a toggle controlling whether or not to broadcast file adverts in the
>traditional way, and a toggle controlling whether to send file adverts to
>known index-servers.
>5)  a toggle controlling whether to forward search queries to known
>index-servers.
>
>------
>
>What do you guys think?

Blocks is a bit of a mess and any change is probably going to
be more than a minor one. Feel free to change anything you
want. If I get a chance I'll have a look at the code and see
if I can remember anything :-)

ttfn

PG.

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