Re: Message Havens
Thus spake SINCLAIR DOUGLAS N <sinclai@ecf.toronto.edu>:
klbarrus@owlnet.rice.edu (Karl Lui Barrus) writes:
Maybe I wasn't clear in what the "message haven" offered... I'm trying to get away from the penet style mapping tables, persistent information tying you and your pseudonym, and solve the "unsolicited anonymous mail" problem. The message haven requires no trust, no tables, no information since it just accepts message and files them, and if you retrieve all the message, the haven can't figure out which ones you are interested in! This flavour of message haven would not require persistent tables. A crooked operator /could/ maintain them, but unlike penet they are not required. Every time you log into a message haven, you tell it what tags you are interested in. Here the level of trust is similar to that of a regular remailer. The remailer /could/ keep logs to destroy your anonymity, but we hope it doesn't.
I realize this solution is far from ideal. But as I posted before, I don't believe the numbers favour a message haven where everything is downloaded. I have this nagging feeling that there is some very elegant cryptographical way of doing this employing secret sharing, but I can't actually think of how to do it.
Couldn't each message have a short header, which is encrypted with the final recipent's public key? When you go to retrieve mail from the haven, you request the complete list of headers (or at least those that are new). If you can decrypt the header, then the message is for you. You then request that those messages, and also some random messages, be sent to you. If the sender uses one or more current-style remailers to send his/her message to the haven, it would much more difficult to work out a map of who is talking to whom. david -------------------------------------------------------------------------------- David Scheidt PGP 2.3 key by email scheida@yang.earlham.edu or finger scheida@earlham.edu "If we don't remember what we do, how will we know who we are?" -Ronald Reagan
As regards message havens... Seems to me that you should also have all of the messages to you collated into one block, have some random length padding added, and then encrypt the whole thing and send it back to you. If you have this all done automatically by the server at the haven, then you may not even need to call all of those random other messages down. That is, assuming you trust the sysadmin of that haven, which is probably not the best of ideas. Anyhow, you can do somwthing similar with anonymous remailers. Maybe someone should (or already has) written a client which will take your message, pad it with some extra gibberish, then construct all of the headers necessary (and encrypt several times along the way) to post it along a path of remailers which either the user inputs, or it randomly determines. Seems to me that if you leave the actual routing in the hands of the user, and not at the discretion of the first remailer you send it to, you gain a far more secure transmission. Of course i could be wrong... It would be nice if remailers supported padding from this end as well. ie, insert something like :: Padding: *** and this tells the remailer that, after decrypting the message (presumably it was sent to a remailer that supports encryption) it should discard whatever comes after the ***, or however it happens to be implemented. This gives yet another layer of obfuscation between me and whoever doesn't like me... * * Mikolaj J. Habryn dichro@tartarus.uwa.edu.au * "Information wants to be free!" PGP Public key available by finger * #include <standard-disclaimer.h>
Seems to me that you should also have all of the messages to you collated into one block, have some random length padding added, and then encrypt the whole thing and send it back to you. If you have this all done automatically by the server at the haven, then you may not even need to call all of those random other messages down. That is, assuming you trust the sysadmin of that haven, which is probably not the best of ideas. The only problem I see here is that it requires the message haven know your public key. All sorts of man-in-the-middle attacks become
possible here. I don't know that I'd trust a machine to do an intellegent web-of-trust; it can't actually meet people at a conference and swap cards.
participants (3)
-
David Scheidt -
Mikolaj Habryn -
SINCLAIR DOUGLAS N