Hal <hfinney@shell.portal.com>

I still don't quite follow this.

Clearly. ;) Okay. You are right that the first remailer derives no primary benefit, and engages in no primary risks from verifying signatures. Alice, however does, and Chaum is, after all, providing a service to Alice (and Frank). He does wish to provide all the benefits that he can to them. What benefit does Alice gain? 1) Plausible deniability. Remember, "reasonable doubt." Remember Abscam? The gov't is in a good position to fake source info. This squishes that. (It squishes even better if Chaum _requires_ signatures.) 2) If Chaum sends Alice a copy of the message that failed the signature check, Alice knows that someone is trying to spoof her. This information may be critical in determining how serious her opponents are. What risks does Alice take? If the final message to Bob is encrypted, and Chaum is not compromised, none. If Chaum _is_ compromised, Alice is chaining anyway, so it still doesn't matter. What might Chaum gain from checking or requiring signatures? Various net abuses often involve faking names. Requiring validated signatures would pressure these abuses away from the remailers. Reducing the net abuses going through the remailers is a PR goal.

PGP already includes a cryptographically protected length field in the message. It will ignore any data past that, according to my experiments. All that is needed is a simple patch to add junk data to the end.

Soapbox mode: It seems to me that hacking PGP requires considerably more cooperation between remailers, and more work than just allowing recursive opening of PGP packets, automatic padding (or concatenating) of data, and automatic encryption of out-goin mail. Subways and MixMaster both appear to have far more working required to implement, far more cooperation between remailers, and far more room for failure than my idea. (Emphasis: appear. I've not seen Lance's paper, yet. He's getting it to me.) I also believe that hacking PGP is a bad thing (tm), because it means that every time an upgrade comes out, it will need to be re-hacked, and once you start hacking, when do you stop? Although, it would be nice to have a STD_LEN variable for such things. OTOH, you seem to be agreeing with me here. Who hacks PGP? Who is PGPing their outgoing stuff? Don't we have to have standard packet _inside_ the net? And you achieve this by using PGP? ?????

I still don't quite follow this. Exactly what attack would be possible against Miron's remailer if it allowed encrypted reply blocks (as all others do) which would fail if the messages were wrapped as you suggest?

The most obvious one: Eve checks messages (in vs out) for matching tails. If the tails match, the messages match. The only way around this is for the entire message to be wrapped. Thus, the extropian requirement. When I say that the Mark I remailers are laughably easy to crack, I mean laughably easy. Is the message a clear set of ::Request-Remail-To:? Pull & log. Is the message clear, with encrypted headers? Match, pull, and log. Is the message encrypted separately from the headers? Match, pull, log. Is the whole message encrypted? Take the ones that are left, match the largest. Match the next largest. Match the next largest. Pull & log. Get stuck? Need a hint? Resend a message. Watch for the repeat on the out. Laugh. The only reason that our systems are actually able to do any good is that our threat model _is not_ an LEA--with government resources, and government patience.

Alice may not have a key whe wants the general public to use - she may just be using one for her private correspondents.

If she wants to be able to recieve untraceable mail, she is going to have to have a key that remailers can use when forwarding mail to her. See below.

Actually it seems to me given the nature of remailing that it would be superior if it were easy for people to "spoof" my use of the remailer. That would give me more credence to claim innocence. The more useless return addresses are, the less we even need remailers.

I think you are arguing to ignorance here. The assumption so far on the list has been that if Alice is root, she is in the best possible postion to protect herself. I disagree. Alice has been hauled into court. The Feds claim that she is the one that actually sent messages M1,...Mx to Bob through Chaum, even though these messages have varied From: (and From) lines. As root, she cannot claim that this is not possible. OTOH, if Chaum requires a match, the Feds would have to claim that she compromised the secret keys of all of all the cooresponding From: addresses. Much tougher.

It's not my job to fix the damn Internet. So what if I get mail claiming to be from abc when it's actually from def? I of all people care the least, specifically because I throw away this data. Virtually everyone else on the net cares where their mail comes from, but I don't. My whole purpose is to discard the information about where it comes from. That is why I am so confused about your emphasis on checking signatures.

We care because we are good people. ;-) Seriously, if a sight is being shadowed, then it is insecure. It is to our advantage to know this. You are right that we "don't care" where a message comes from only if we assume that the message _didn't_ come from an LEA. (Or a big corporation. Some of them probably have the power to do this, too.) If it did, then the remailer net is under attack, and we most definitely _do_ care about that.

Although I agree with Wei Dai's mathematics, to my mind it points up the importance of successful countermeasures rather than implying that the remailer network is inherently insecure. For example, if you send one identical message every batch, Wei's math shows clearly that you can't be traced. Let's not get rumors started about how the remailers don't work.

I'm lost here. I thought that sending an identical message (producing identical output) every tick would be the equivalent to an attack. But what exactly constitutes "successful countermeasures"? How do you prevent an attacker from taking over a sight, thus compromising it, w/o the knowlege of the operator? How do you prevent long/short matching of the remailer net _as a whole_? How do you prevent tail matching? How do you prevent middle matching, for that matter? How do you prevent the repeated message attack?

Do you see your suggestion as protecting against Wei's in/out correlation attack?

Yes! Well, not by itself. My suggestions about "rational use of garbage" do that. If Bob recieves x messages each tick, 0 to x of which are real, Eve is hosed--if all messages are standard sized & encrypted!. Eve is even more hosed if the x messages are concatenated & superencrypted. If Alice sends y messages each tick, Eve is hosed. Even more so if the messages are concatenated & superencrypted.

I don't see it. If fixed-sized packets are used, with chained encryption, I think you have as good a system as you do with all of your inter-node encryption and signing.

The way you suggest to standardize packet sizes leaves the system vulnerable to matching the top of the body of the messages in a repeated- message attack.

Suppose one good encrypted message enters the net with 10 unencrypted ones. Won't the full path of each of the 10 be visible to an outsider? Even if the remailer helps out those 10 doltish users by encrypting them from there on out, the outsider already saw their whole paths! They will know how many unencrypted messages are going out to each destination, and from that determine where the encrypted message is going.

Not with rational use of garbage. With rational use of garbage, the system could protect a single encrypted message--if the recipient or sender is "in the box". BTW, it may be impractical for senders to be "in the box", as described, as they cannot know exactly when ticks occur. I believe it can be done, though.

Of course it was Chaum himself in his 1981 paper (which I think is available from the CP FTP site) who described the duplicate-message attack. I don't see that inter-remailing encryption helps much, because the attacker can still notice that whenever they inject message A, _something_ goes to Bob. The real solution, as Chaum pointed out, is that the remailer must reject duplicate messages, even when separated by days. Doing this without keeping a database of all messages ever sent is left as an exercise.

I disagree. If identical input to Chaum does not produce identical output to Bob, how does Eve coorelate them? Repeating, she can match the top of the body of messages, so random tails reveal the actual encrypted message, for whatever that is worth. And if Bob receivs x packets per tick, or a BIG packet every tick, how does Eve trace it?

Another aspect worth mentioning is that message splitting can make the kinds of statistical correlations that Wei Dai was looking at more of a danger.

More than being the ONLY file in the net of your (approximate) size?

It's one thing if I send a message along with thousands of other people, and Bob gets a message along with everyone else. But if I send 10 messages and Bob gets 10 from that batch, that fact alone can help to link us up. So splitting my big message into 10 standard ones isn't that great if they're all sent at once. Ideally you'd want to dribble them out at some standard rate, a rate at which you always send a message whether you have something to send or not. But this may introduce unacceptable latency.

"Dribble them out at some standard rate". Yes. y packets per tick. Set y equal to your average number of real packets per tick, plus 3 standard deviations. Since you are chaining, the latency of you input will be less than the latency of the remailernet. Nathan "PGP?" "ITAR!" "Oh, RKBA!" |--------------------------------------------------+ ----------------- 14712B4D 1994/12/26 Nathan H. Zook <nzook@bga.com> ) |44B3D866 3D551E2E --------------------------------------------------- |F89222A6 338CDE24/ | -----------------