[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: strengthening remailer protocols

On Tue, 10 Sep 96, Andrew Loewenstern <[email protected]> 
>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 

Jonathan Wienke