[Blocks-development] Mixnets, libblocks, datagrams

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

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

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

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.

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.

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?

--Spence
bl...@ms...