Need to Declare Policies on Remailer Record-Keeping

(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.

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

Here's the policy paragraph from my remailer blurb:

--------------------
	Policy, security, and legal cruft:
The remailer has the capability to log source and destination
addresses, as well as full message text.  This is presently turned
off.  If I need to debug some weirdness, though, I'll turn it on
again.  I cannot guarantee, for both technical and political
reasons, that anonymous mail will be secure.  In particular, I
explicitly disclaim the security of messages which are in themselves
harmful and illegal, such as extortion and libel.  I will block mail
from my remailer to any particular address upon request of its
owner.  I may request some form of verification, to thwart
denial-of-service attacks based on this mail blocking.
   By sending a message through my remailer, you are trusting me,
like it or not.  I could be a sting operation, or a blackmailer
gathering information -- it *will* happen eventually.  If you do not
trust me, ask someone you do trust to do the remailing.
   Please remember that anti-social behavior or truly excessive
traffic through the remailer will probably cause my sysadmins to
ask me to remove it.  Thank you for being polite.  Please ask me
if you have any questions.
------------------------------

Addenda to the above: I do keep usage logs ("date >>log"), which
perhaps I should mention.  jarthur is not my machine (fortunately!),
so it keeps mail logs and I can't do anything about it (unless we
make the remailers avoid getting logged in the first place...).  I'd
like to run a personal linux box, but I really can't unless somebody
would like to give me a second machine.  
   The muttering about "disclaiming the security" of extortion
threats is pretty much moot, because I can't do do any outing unless
somebody says "I'm going to extort an upstanding citizen through
your server; please turn logging on."

Mail logs are a problem, because lots of machines keep them and most
remops (uh, that coinage is a lose) can't fix this.  I think that
the user-mode orientation of the remailer package should extend to
letting J. User install it and *have it be secure*, too.  Really,
anonymity with mail logs is security only through obscurity.

I presume you can do socket coding in perl.  It should be possible
to have the remailer interpret mailings to "<keyword>@<machine>" to
mean "open a socket to the remailer on <machine> and dump the message
to it."  The remailers do their own mail handling; all the transport
system does is dump it in their laps.  To fix logging on the final
transmission to the recipient would require batching, which if most
people get sufficient traffic (I don't) might be preferable to this
whole mess.

   Eli   ebrandt@jarthur.claremont.edu