On Tue, 10 Sep 96, Andrew Loewenstern <andrew_loewenstern@il.us.swissbank.com> wrote:
Wei Dai writes:
How about a combination of the two? Suppose Alice wants to anonymously post a message and get replies. She generates a new RSA key, signs her post with it, and asks readers to send encrypted replies to a server. Then periodicly she sends a one-time reply block to the server to retrieve the accumulated replies.
I'd like to chime in and say that this is a really good idea. Basically a nymserver that holds onto incoming mail until an e-mail arrives from the nym to retrieve it.
Instead of that, how about this? 1. Create a pool of N remailers, each with its own set of public/private key pairs. The public key(s) for each remailer are widely disseminated. Each remailer also publishes a list of other remailers that it will poll for messages. (More about this later.) 2. Each remailer user MUST have at least 1 public/private key pair per nym. The public key should be widely available. 3. Each message is encrypted with the intended recipient's (nym's) public key, and then with each remailer's public key succesively, but in reverse order. (The message is encrypted last with the public key of the first remailer in the chain.) The chain is determined by selecting some subset of N at random, with the set growing as the need for security increases. Encryption is done a la PGP, with a header prepended to the message containing the fingerprint of the public key used to encrypt the session key used to encrypt the actual message. Each layer of encryption encrypts the header of the previous layer of encryption as well as the message, so only the last encryption is "visible", and it is not feasible to detect the number of encryptions by examining the message. 4. The multiply-encrypted message is sent to the first remailer in the chain. The remailer decrypts the message with its private key, and at this point one of two things can happen. If the decrypted message specifies an email address, the remailer sends the message to the specified address. Otherwise, it posts it in a publicly available database with 3 fields. 2 are public; one contains the key fingerprint of the outermost public encryption key, and the other contains the message itself. The third, private field contains the date/time the record was added to the database. Any appropriate techniques for reducing input/output correlation can be used, such as delaying the decryption for random time intervals, dummy messages between remailers, etc. Remailer-to remailer traffic (or to any nym that gets a lot of traffic) should should be bundled together (take a few hours worth of traffic going to a specific nym, ZIP it into one large message, and re-encrypt using that nym's public key) to prevent a sender from being able to recognize any of his messages in transit. 5. Anyone can do lookups in the public fields of the message database by key fingerprint. Remailer users do this to download their messages, and remailers download messages from other remailers in this manner as well. Anyone can download any message in the database; only the intended recipient will be able to decrypt it. Messages are not deleted when they are downloaded; instead they are kept for a fixed period of time (determined by the remailer operator) and then deleted. If users are required to download other people's messages, tracing a message to one specific person will be much more difficult. 6. Steps 4 and 5 are repeated until the final recipient receives his message and decrypts it, at which time crypto-anarchic utopia can resume. Randumb Thotz: Given an encryption program with a database of which remailers poll other remailers, remailer chaining can be automated, and be done randomly. If 2 nyms can agree to poll a mutually known set of remailers, (such as via anonymous Usenet/Blacknet postings) 2-way anonymous correspondence can occur without either nym having to know the other nym's email address. The remailer operators wouldn't know either, but they may be able to make reasonably informed guesses at recipient-nym relationships via analysis of database browsing patterns. This is the the weakest part of the proposal, and suggestions for preventing this would be appreciated. Remailers should use SSL or other encrypted communication protocols to ensure that third parties cannot observe who is browsing what in the public message databases. Jonathan Wienke