[Cryptography] prism-proof email in the degenerate case

Jerry Leichter leichter at lrw.com
Thu Oct 10 16:22:50 EDT 2013


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?

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.

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.  One way around this, for cooperative senders:  When creating a message, the sender selects a random R and appends tag Hash(R).  Anyone may later send a "you may delete message R" message.  A sender computes Hash(R), finds any message with that tag, and discards it.  (It will still want to delete messages that are old, but it may be able to define "old" as a larger value if enough of the senders are cooperative.)

Since an observer can already tell who created the message with tag H(R), it would normally be the original sender who deletes his messages.  Perhaps he knows they are no longer important; or perhaps he received an application-level acknowledgement message from the recipient.
                                                        -- Jerry



More information about the cryptography mailing list