[GNU/consensus] having a "dropbox" in the age of full traffic and server analysis

[carlo von lynX]

On Thu, Jul 25, 2013 at 09:33:09AM +0100, Michael Rogers wrote:
> On 25/07/13 08:58, elijah wrote:
> > * Third-party-dropbox: To exchange messages, user A and user B
> > negotiate a unique "dropbox" URL for depositing messages,
> > potentially using a third party. To send a message, user A would
> > post the message to the "dropbox". To receive a message, user B
> > would regularly polls this URL to see if there are new messages.
> 
> Hi Elijah,
> 
> I'm curious about the third-party dropbox idea (partly because I'm
> currently working on an HTTP dead drop transport for Briar). It seems
> like there are two ways you could do this:
> 
> 1. The dropbox is shared by multiple users; when user A authenticates
> and deposits a message, she tells the dropbox that user B is allowed
> to collect the message.
> 
> 2. The dropbox is only used by one pair of users; when user A
> authenticates and deposits a message, the dropbox knows it's for user B.
> 
> In either case, the dropbox has metadata about who's communicating
> with whom. In case 2, anyone watching the dropbox also has that
> metadata. (In case 1, anyone watching the dropbox has that metadata
> unless communication with the dropbox is encrypted and padded.)
> 
> So I don't see how this technique is metadata-resistant, except in the
> short term (NSA has to arrange metadata collection from a new service
> provider). What am I missing?

you didn't ask for it, but I'll give a rough description of the
PSYC over gnunet approach to this as far as i think we are doing it.

a dropbox is technically a multicast context anonymously* subscribed
to by one or millions of recipients. the name of the context is the
public key necessary to write to it. by looking it up in the DHT you
find possible root nodes of the multicast. you can send messages to
them encrypted to that public key - they will trickle down to the
subscribers. the ones who have the private key can read the messages.

if the subscribers are offline, the nodes next to the subscribers in the
tree will keep the messages for a reasonable time until they come back.
thus there is no actual implementation of a dropbox - it's just a side
effect of the multicast infrastructure and works both for one-to-one
messaging as for twitter-like usage or videocasting to millions of
viewers... and what's best: it's redundant and doesn't depend on any
node staying up.

gnunet mesh actually reencrypts the message from hop to hop as it
travels down, as this has some advantages, but that doesn't mean
the original content has to be sent "in the clear." so my description
above is a bit of a simplification of what actually happens under the
hood.

too bad we didn't get the financing to have this already out there
running.


*) "anonymously" if you insert some onion hops between yourself and
the multicast source or if the tree is sufficiently big already.
you can choose to keep the tree short and fast, though. it will
still be hard to tell you are participating, unless the content is
a video stream and everybody else is just chatting. if instead
everybody else is watching streams or doing file sharing, then you
are covered well even if you chose to reduce the number of hops.
that's why gnunet is also for file sharing.