On Thu, Oct 10, 2013 at 04:22:50PM -0400, Jerry Leichter wrote:
> On Oct 10, 2013, at 11:58 AM, "R. Hirschfeld" <r...@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 irrefrangi...@mail.unipay.nl....
> Nice!  I like it.

Me too.  I've been telling people that all PRISM will accomplish
regarding the bad guys is to get them to use dead drops, such as comment
posting on any of millions of blogs -- low bandwidth, undetectable.  The
technique in this thread makes the use of a dead drop obvious, and adds
significantly to the recipient's work load, but in exchange brings the
bandwidth up to more usable levels.

Either way the communicating peers must pre-agree a number of things --
a traffic analysis achilles point, but it's one-time vulnerability, and
chances are people who would communicate this way already have such

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

Each server/list is a channel.  Pre-agree on channels or use hashes.  If
the latter then the hashes have to be of {sender, recipient}, else one
party has a lot of work to do, but then again, using just the sender or
just the recipient helps protect the other party against traffic
analysis.  Assuming there are millions of "channels" then maybe
something like

    H({sender, truncate(H(recipient), log2(number-of-channels-to check))})

will do just fine.  And truncate(H(recipient, log2(num-channels))) can
be used for introduction purposes.

The number of servers/lists divides the total work to do to receive a

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

But then the sender can't quite prove that they didn't send anything.
In a rubber hose attack this could be a problem.  This also applies to
recipients: they can be observed fetching messages, and they can be
observed expending power trying to find ones addressed to them.

Also, there's no DoS protection: flooding the lists with bogus messages
is a DoS on recipients.

The cryptography mailing list

Reply via email to