-----BEGIN PGP SIGNED MESSAGE----- Does the world need to have the anon.penet.fi model of anonymous email and news posting refined, given the existence of Cypherpunks remailers and Mixmaster digital mixes, not to mention nymservers? I will listen respectfully to the arguments of the people who say "no", and they're very likely right. But penet *is* the most widely used means of anonymous communication on the Internet - largely because of its ease of use compared to genuinely secure remailers and mixes. The other night, while sick and feverish with the flu, a scheme popped into my head that would seem to make penet-style anonymous servers less vulnerable to compromise through seizure of the remailer equipment or of the address database. In the cold light of day and normal temperature, it still seems like a sound idea to me, and I wondered what other people would think of it. My scheme is the design of the address database. It consists of two hash tables, one for sending messages (which maps anonymous IDs onto sender's addresses), and one for receiving them (mapping recipient's addresses onto anonymous IDs). A cryptographically secure hash (say, MD5) is used for the index of both tables. The index of the sending message table is the MD5 hash of the sender's address. The table entry the index points to is the sender's anonymous ID, encrypted by a symmetric algorithm (maybe IDEA). The encryption key would be a different hash, by another algorithm (let's suppose it's SHA), of that same address. In forwarding a message, the server MD5-hashes the sender's address and looks at the table. If it doesn't find a corresponding entry, it creates one. If it *does* find an entry, it SHA-hashes the sender's address and uses this key to decrypt the anonymous ID. In the unlikely event of collision the decrypted ID will be gibberish and the server does something sensible (like appending padding to the address and trying again). The header information is filtered and the anonymous ID inserted in the From: line. The receiving message hash table is designed similarly, in reverse. The index of the hash table is the MD5 hash of the anonymous ID; the entry in the table is the recipient's email address, encrypted with the SHA hash of the anonymous ID. When a message comes in, the anon ID is hashed and looked up in the table. If nothing is found, the message is bounced. If an entry is found, the anon ID is SHA hashed and the table entry decrypted. If it is gibberish, a collision has taken place and handled appropriately. The message is then forwarded to its intended recipient. What all this accomplishes is to obscure more information from attackers and from honest operators. In the event of abuse it is a simple matter to find out who the abusers are and block them out. If the operator is subject to subpoena, anyone named in the subpoena can be easily identified . . . *but nobody else can!* Authorities cannot use a search for one identity as an excuse for a fishing expedition in the address database. (Obscuring information from honest operators can protect the operator when questions of liability or even conspiracy come up.) There is a way that attackers who have seized or copied the database can search it - by trying it out on anonymous IDs, or user addresses, until they hit paydirt. And of course such an anonymous server can be no more trustworthy than its operator; and the fundamental security limitations of the penet-style anonymous server are well-understood. So what do people think of this scheme of mine? Are there drawbacks or weaknesses that I'm not seeing? Is it a good idea? I'd really like it if *something* good came out of being laid up with the flu. - -- Alan Bostick | They say in online country there is no middle way mailto:abostick@netcom.com | You'll either be a Usenet man or a thug for the CDA news:alt.grelb | Simon Spero (after Tom Glazer) http://www.alumni.caltech.edu/~abostick -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMX+n0OVevBgtmhnpAQFkrwL+N+CklsLNsqHXNPnCOs1mogNydNnCtvGs cUqK9rG3xpTYFsPMH6lhWq8wfPfKtQ88xs3RC/JE8ypcDZBugifNDf7hTuGeLZ8n Q8RDvnAq0qNz9rxqHiMuyOQ3kf6YEVys =g5SU -----END PGP SIGNATURE-----