[Cryptography] prism-proof email in the degenerate case

[R. Hirschfeld]

> From: Jerry Leichter <leichter at lrw.com>
> Date: Thu, 10 Oct 2013 16:22:50 -0400
> 
> On Oct 10, 2013, at 11:58 AM, "R. Hirschfeld" <ray at unipay.nl> wrote:
> > Very silly but trivial to "implement" so I went ahead and did so:
> > 
> > To send a prism-proof email, encrypt it for your recipient and send it
> > to irrefrangible at mail.unipay.nl....
> Nice!  I like it.
> 
> A couple of comments:
> 
> 1.  Obviously, this has scaling problems.  The interesting question is how to extend it while retaining the good properties.  If participants are willing to be identified to within 1/k of all the users of the system (a set which will itself remain hidden by the system), choosing one of k servers based on a hash of the recipient would work.  (A concerned recipient could, of course, check servers that he knows can't possibly have his mail.)  Can one do better?

A simple way to distribute the load over multiple servers might be to
just to have them share a subscriber list, i.e., recipients are
subscribed to all of the lists and senders arbitrarily choose one to
send to (perhaps the one advertising the lowest load?).  This doesn't
lighten the load on the recipients, only on the servers.  It does
sidestep the anonymity tradeoff, though, and remains oblivious to the
crypto used (e.g., Bob & Carol can use gpg and Ted & Alice can use a
one-time pad and none of them need to know a system-wide hash function
for choosing the correct server).

For a bulletin-board-like system, you could perhaps achieve something
similar with a CDN.

> 2.  The system provides complete security for recipients (all you can tell about a recipient is that he can potentially receive messages - though the design has to be careful so that a recipient doesn't, for example, release timing information depending on whether his decryption succeeded or not).  However, the protection is more limited for senders.  A sender can hide its activity by simply sending random "messages", which of course no one will ever be able to decrypt.  Of course, that adds yet more load to the entire system.

I like the idea of sending out random messages to further frustrate
traffic analysis!

> 3.  Since there's no acknowledgement when a message is picked up, the number of messages in the system grows without bound.  As you suggest, the service will have to throw out messages after some time - but that's a "blind" process which may discard a message a slow receiver hasn't had a chance to pick up while keeping one that was picked up a long time ago.

With a mailing list (as opposed to a bulletin-board-like system) you
needn't retain any messages on the server at all.  They would still
pile up in MTA queues and on POP servers and the like (and there'd be
a lot of duplication!) but this is largely self-limiting as they'd be
discarded as recipients pick up their mail.

OK, obviously this doesn't scale.

Ray