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
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
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
