[Cryptography] prism-proof email in the degenerate case

[Eugen Leitl]

----- Forwarded message from Nico Williams <nico at cryptonector.com> -----

Date: Fri, 11 Oct 2013 10:53:03 -0500
From: Nico Williams <nico at cryptonector.com>
To: Jerry Leichter <leichter at lrw.com>
Cc: ray at unipay.nl, cryptography at metzdowd.com
Subject: Re: [Cryptography] prism-proof email in the degenerate case
Message-ID: <20131011155302.GA8170 at gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Thu, Oct 10, 2013 at 04:22:50PM -0400, Jerry Leichter wrote:
> 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.

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

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

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

Nico
-- 
_______________________________________________
The cryptography mailing list
cryptography at metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5