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