[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]>
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