-----BEGIN PGP SIGNED MESSAGE----- Lance Cottrell <lcottrell@popmail.ucsd.edu>

I agree completely that messages should be encrypted between remailers. This does raise the issue of keeping a database of all other remailers at each remailer. Lets settle for encrypting to the next remailer most of the time.

Well, actually, I'm suggesting a database that includes all remailers and all selected users. ICT: in order to beat TA, first or last remailers are going to _have_ to used standaradized, encrypted packets. The remailers are almost secondary here, except that we aren't sure that TA through the net is impossible. Or we could be facists, and _only_ send out PGP-ed, standard sized packets. (Forcing remailer-users to get into PGP.) Something would have to be done about lists & mail-to-news. Is there some difficulty in maintaining a database? Remailers would want to publicize their exsistance. This might involve pinging, but so what? That's just more noise.

The best way to do that is to open a socket between the remailers, and use DH key exchange (authenticated with RSA?), to generate the encryption key. This gives forward security to any intercepted messages. It is high on my list of upgrades to Mixmaster.

But doesn't this require a realtime connection to be practical? ie: remailers must be _on_ the net? As far as this all goes, the sender could stick _all_ packets together, PGP the whole thing, and send _that_. This would only require signing once per recipient per tick. T1, anyone? *** P.S. Could you mail me that essay? I'm long distance to the net right now. *** Adam Shostack <adam@bwh.harvard.edu>

Nathan Zook: | | Suppose Alice sends Bob a message e(M) through Chaum. Eve, a stong | opponent, wants to trace the message. She keeps track of all outgoing mail | from Alice, an MD5 hash of all incoming messages to Bob, and outgoing from | Bob. Eve then sends Chaum e(M), and waits for a matching MD5 to Bob that | doesn't correlate to an outgoing MD5 from Bob. (Eve knows that Bob is a | remailer.) | | Gentlemen, I believe that I have just stumbled upon a strong proof of | the necessity of remailer auto-encryption of all messages. Since the | session key is PRG, MD5 will change (a lot;). Furthermore, remailer auto- | encryption allows the mailers to number their messages to each other. A | low number means a re-transmit from the remailer, which is not possible, | unless some sort of ACK system is in place, and even then, would still | flag. Of course, if the remailers _sign_ their messages (on the way out) | as well, you could compare the timestamps of the signatures with the | message itself.

This is strong argument for encrypting your chain of messages, using premail, or chainmail, or something similar. Why the remailers should do this is not clear at all from your argument. Remailer operator should be discouraged from cooperation beyond that which is needed.

Adam

I think that you are missing the attack. Eve wants to prove that Alice sent a message to Bob. By resending Alice's message, it will route through Chaum just fine, producing identical output (message to Bob) as before. Assuming that Eve doesn't intercept the message, stopping Bob from getting it, Bob will know that something is up when he gets the message the second time, but by then it is too late. Eve knows that Alice's message, sent at time X, corresponds to a message received by Bob at time Y. This is exactly the sort of thing that LEAs love to use in building a case. My claim is that the only way to prevent this attack is for Chaum not to send out identical messages if he receives identical messages. Identical, in this case, would include messages identical except for "cryptographically strong random" data tacked on to the end, because if Eve had the storage space, she could compare messages _that_ way, stripping off the end bits, and getting the real message (encrypted) to Bob in the process. The natural way to do this is to super-encrypt. Of course, if Chaum just sends one rather large file to Bob each tick, Eve is hosed. BTW, if Chaum does an MD5-compare of all incoming messages, he can limit a spam to 1 per tick from his remailer with _no_ recordkeeping. Or maybe he could send a bunch of identical garbage messages to a random remailer, 85% of the time.... I really don't see how you can call this "cooperation beyond that which is needed". If the remailers default to strip nested envelopes, and to pad messages to standard sizes, the only "cooperation" between the operators is to publish PGP keys. They aren't "helping" each other, they are helping the end users. But this is all so trivial, compared to arguing operating systems. Nathan Finger or request keyserver for PGP 2.6.2 (tm) key. PGP<->Mail/News installation incomplete. Factors for modulous are not proven primes. Key may be far weaker than expected. Encode at your own risk. Key ID: 14712B4D 1994/12/26 Nathan H. Zook <nzook@bga.com> Key fingerprint = 44 B3 D8 66 3D 55 1E 2E F8 92 22 A6 33 8C DE 24 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBLywNqHmgMs8UcStNAQEgMAf/U+1rc6/5h6dZZAM9PuAJL0co25yE3JM4 vH3YSmRw31gQdjdRMw36XXZ4OLtTgV3CMBmlu5NoH5m80EAjUji3WCoRwhkin7G9 BgZnXhghR/ceLeE3MgyWZLTtApZkYO+z3zYxm1mYS4GLkuil/PENmuRrAFlihR4D jx/OgCbEU6EnR8Nyh0nGKqToOsE8wPZJfT5ff17vOSHV8hBre354ePB5tnkDoV5H MKgDTCkOx4vQJI8LNmQZHUCNyFmxuJTcYmxAM0j+8rAcdJzKo78eG7/vtJ4uxyBV AxPN7SJyCyplJGgQQ4+y9m5RkSYM6CQFy5PS+jLY66f3ZLmgDaW5vw== =Er9Z -----END PGP SIGNATURE-----