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.

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 

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

The cryptography mailing list

Reply via email to