Need to Declare Policies on Remailer Record-Keeping

[tcmay@netcom.com (Timothy C. May)]

(I hope this is not considered "off-topic" by anyone.)

It would be nice if the operators of the current remailers made clear
their archiving/record-keeping policies on remailer traffic.

An "ideal mix" is like an "ideal op amp": very hard to build in
practice, but very useful as a concept. David Chaum's 1981 paper
anticipated many of the issues some of us later discovered, and which
are dwell upon at length on this list.

Some brief descriptions of the "ideal mix" (remailer):

1. Records. No records kept of incoming or outgoing traffic (in Chaum's mix,
done by tamper-resistant hardware implementing software that keeps no
records; in DC-Net approach, no single entity knows traffic, so only
collusion can reveal traffic).

Score: Many remailers keep records/logs, either explicitly ("to help
in debugging") or by default (Unix records, system requirements, etc.)

I have been shocked on a couple of occasions--a useful, educational
shock--to get e-mail messages from the operators of remailers, saying
things like "I couldn't help noticing your comments--I agree with you
that...." Now partly this was my problem, in that I was not using PGP
to chain my transmissions (in which case no snooping remailer operator
will be able to get my true name except by colluding or traffic
analyis), but it also indicated that some remailers are not taking a
sufficiently hands-off policy...more on this point later.

2. Encryption, obviously, to hide mapping between ingoing and outgoing
traffic.

Score: Pretty good (no pun intended), though use of encryption is
reported to be low. PGP has helped immensely.

3. Latency: some number N of messagers needs to be stored (securely,
unobservably, as in #1) and then sent out in an order that obscures
order of arrival. (Lex order, for example.)

Score: Someone has been trying to implement this, but it is not
widespread. (People want fast response, and in a low overall message
volume environment, this could be impossible. If N = 100, could be a
very long wait.)

4. Padding of message lengths in such a way that messages cannot be tracked by
message length.

Score: I don't think this is being implemented. We've talked about
"quantizing" to several standard message lengths ("short," "medium,"
and "long," uncreatively enough) for this reason.

5. Other issues can be found in Chaum's papers, in the attacks on
DC-Nets (one of which I distributed with the 70 pages of printed
material handed out at the first Cypherpunks meeting), and in the many
messages on remailers here on this list. Hal Finney's analysis, for
example.

In light of the recent subpoena, I urge that #1, record-keeping, be
addressed quickly. If the authorities are seeking sources of crypto
material, or routes used in conveying such material, they may
conceivably issue subpoenas for site records.

Some suggestions, which protect the remailer operators and the users:

a. Keep no records, use scripts to delete records that may be
generated that you have control over.

b. The "best" remailers will be on systems under the control of the
remailer operator himself (there seem to be a few of these), as he can
control archiving and logs.

c. Remailer operators should announce their policies on logs,
announcing their philosophy (e.g., "to protect myself, I keep copies
of all traffic through my remailer," or, "I keep no records
whatsover--once it's through my system, all traces are deleted."). 

d. Trust in what they remailer operators say is another big issue...if
the FBI operated a remailer, would you trust what they say? One avenue
for helping here is to have independent agents reporting on their
experiences, and perhaps confronting the remailers with evidence (such
as the "helpful messages" I 've sometimes gotten) of their actual
policies.

e. Increased use of encryption.

Lots more here. For now, just getting the remailers to publically
state their policies will be helpful. To us, in allowing better market
choice in which remailers we use, and to them by making their lack of
record-keeping (for example) a matter of public record.

Let's plan ahead for the day when Cypherpunks traffic, and remailer
records, get subpoenaed. That _could_ be the next test case.

I don't think I'm being paranoid. In any case, there are some fairly
easy _social_ changes to the remailer system that we can make that
will improve the security against traffic analysis and subpoenas.

-Tim May


-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | Public Key: PGP and MailSafe available.
Note: I put time and money into writing this posting. I hope you enjoy it.