-----BEGIN PGP SIGNED MESSAGE----- From: Nathan Zook <nzook@bga.com>
The traffic analysis that we've seen so far mainly just documents tcmay's "everybody a remailer" concept. If you look, you will notice that these analyses all assume that Alice and Bob are _not_ remailers themselves, and for a good reason. If Alice and Bob _are_ remailers, analysis of the type used here is worthless, especially if Alice and Bob have a policy of not sending any mail unless they first receive garbage, and of sending out garbage whenever they get a letter.
Realistically, though, everybody is not a remailer, and there are no prospects of everybody becoming a remailer anytime soon, so the analyses of Wei and others are certainly relevant.
HOWEVER, the analysis makes another assumption--that messages are indistinguishable. This assumption does not correlate, as I understand it, with the current remailer net.
Mixmaster is supposed to do splitting and, I think, padding. I hope to have time to look at it soon. It sounds very good.
First, the message is signed with the sender's key. (More on that later.)
I did not see why this should be done.
Suppose a signed message to be forwarded is smaller than the standard packet size. The sending remailer adds a Cutmarks: header. At the end of the message, the cutmark is added, followed by sufficient garbage to fill out the standard packet size. The message is then pgp'ed to the recipent _with COMPRESS = OFF_.
A better approach IMO is to embed the message length in the encrypted information (as PGP does) and pad with cryptographic random garbage (which PGP could be patched to do).
Upon receipt, the message is decrypted, and its origination can then be triply verified (at least). From: line, packet size, and PGP signature. Since the message claims to be from a packeting remailer, the packet size should be the standard one. The recipient now has the message that was sent to it. This message is probably itself encrypted, so it can be handled (almost) as if this message were just received. This includes stripping the garbage and (probably) decrypting the message to get the forwarding information.
Why does the remailer care where the message came from? What difference does that make? I can see the final recipient caring about the original sender, so a PGP sig makes sense at that level, but why at each hop?
Note that this system would allow the extropian remailer to be compatible with Matt Ghio's alias system. (Right now, the remailer doesn't like separate pgp packets, or packets it can't read, or something.) Under the current system, the precausion is entirely warranted.
I don't think so. The problem with Miron's extropy remailer is that it only passes through the contents of a PGP block. For anonymous addresses to work, the (chained,encrypted) address must be in a PGP block which precedes the message body. I don't see how any cutmarks idea would affect this.
To make life even more fun, there is no good reason that non-remailers cannot be in on the action! Alice, sending to Bob through Chaum, pretends to be a remailer. That is, she prepares her message to Bob, (encrypted), and adds the Request-Remailing-To: Bob@nowhere.org, and signs it. She then observes that the message is too small, so she adds the Cutmarks: header, etc. When Chaum receives the packet, he opens it, removes the cutmarks, and sees a signature he does not know. Chaum then sends a request to pgp-key-server@omniscient.gov for the key, and holds the message until he gets it. He then compares the address and name on the key recieved to the message. The signature is good, so he is ready to send the packet to Bob.
Again, why does the remailer go to all this trouble to verify a signature from Alice? That sig is for Bob! She may not even want to post her public key for everyone; Bob may be the only one who has it. I don't understand why the remailer, which exists to hide identities, is going to such trouble to verify them on its own.
But Bob can be in on the game as well, since there is no reason that he cannot handle the Cutmarks:, the signature, and the nested encryption. In fact, Alice could include a copy of Bob's key in the message for Chaum to use, after a Recipient-Key: header.
Alice is the one who should encrypt the message for Bob, not the remailer! Are you suggesting that she should let the remailer see the message contents?
Bob can also verify that the message was actually routed through Chaum.
Why on earth does he care? I really don't see what problem you are solving here with all this checking.
If Chaum is concerned that, at some future time, Eve might supeona his key ring in order to demonstrate that Alice and Bob are using Chaum, Chaum can alternately request keys that he does not need from the servers, and delete (older) keys in the ring.
Eve would be more likely to subpoena Chaum's secret key ring. A public key ring proves nothing.
In other words, if all the remailers can handle nested pgp packets and cutmarks, we are close to moving all small messages to a standard size.
This mostly makes sense (although as I said I prefer simply enhancing the crypto program to take a parameter for output pad size) but I don't see where all the rest of it came from.
What if the file is too big?
If the file is too big, break it in pieces. We need a header, Multipart Message: n of m. Note that since this is assumed to be _inside_ a pgp wrapper, it is secure. The recipient could hold and merge the files as needed. If the message to be forwarded is too big, split and continue. Since the messages are ascii armored, the split/combine protocal is to concatenate. Message parts could be made equal size to minimize the chance of a message barely bumping over the limit as it moves. Of course, Alice could break her message to Bob directly, but we cannot assume that all would do this for us.
I believe Mixmaster provides a client mode to do this. I prefer putting more functionality in the hands of the users and not relying on kindly old Uncle Remailer to do it for you.
This also means that if Alice sends a message to Bob in the clear through Chaum, and David, that the message will be encrypted from Chaum to David. Thus, if Eve wants to know which message from Chaum to David is the one from Alice to Bob, (perhaps to know that it is _not_ the message from Frank she is interested in) she knows only that it was one of the messages from Chaum to David after Chaum got the message from Alice, and before David sent it to Bob. While Chaum and David can both read the message, it still provides mixing capabilites inside the remailer net itself, and thus, some protection to Frank. (Who apparently needs the help.)
This is a commonly made suggestion, but philosophically I am opposed. We got into this fix (lack of privacy) by letting people rely on others to do things for them. It's time for people to take responsibility on their own. The kind of thing you are suggesting provides the illusion of privacy. Never trust remailer operators!
A word on remailer keys: Since pgp uses square-and-multiply for exponentiation, we see that the amount of work needed to sign a message is d(m) * (d(e) + o(e)) where d(m) is the digits of the modulous, d(e) digits of the exponent, and o(e) is the number of ones in e. (I don't remember the technical term.) Since the public key is small, each of the parts of the private key will be large, BUT, there is no reason to assume that we cannot get lucky, and find an m such that d(e) + o(e) is much smaller than expected, (d(m) * 3/2, roughly) thus greatly reducing the system demand of the remailer. In fact, it might be possible to move to 768-bit keys for those that have kept their sizes down in the past. If pgp handles each prime separately, we look for a double-lucky modulous. (And a source of random numbers that does not involve striking keys!)
Since the secret key d is effectively a random number from 0 to m, you would have to create, say, 1000 key pairs to have a good chance of finding a d that was as much as 10 bits shorter than m. Then o(d) might be 5 bits shorter. So you'd be done from 768+384 to 758+379 or about a 1% reduction in time. And it will take a while to generate 1000 keys. To get a 2% reduction you would have to generate 1000000 keys. I hope you have a lot of time on your hands. I'm sorry to have been so negative, but this message is part of a long tradition advocating putting more responsibility into the remailer net. I strongly feel that better solutions put power into the users' hands. I oppose centralized solutions. Hal -----BEGIN PGP SIGNATURE----- Version: 2.6 iQBVAwUBLyqgIRnMLJtOy9MBAQF1YAH/Yu68NkN0NnbCTfxDoGm4oc6lCs+dCp6V pmjinw8zdwBM133eAaaorjtW0KhEvBNMGQTFHeiGJTOt94bE8ELB5g== =owIt -----END PGP SIGNATURE-----