...

(Furthermore, most remailer structures still can't erase some other security concerns -- 1: remailers acutally can be hacked or physically compromised 2: clients really can be screwed 3: etc.

To help solve the first, you'd want a two-box setup doing remailing, with the security-critical stuff loaded on a box not directly connected to the Net with something 140-1ish to make tampering harder, a secure OS, etc. -- or, of course, you can scrap all that to get really big remailer count.

As long as you do not see the box and do not control its manufacture, I see no reason why you should have ny more trust in it.

Well, you shouldn't have complete trust -- a tamper-resistant net could be compromised, too -- but there's a good reason to have more trust in it than in the existing one. More on that after a parenthetical remark. (This brings up the "hardware web-of-trust" issue; you can set up such a web with trusted spot-checkers and statistical/cryptographic means of assuring the user that the box works as advertised, if your threat model demands it. There's more about it in the "Beyond Class (A1)" section of the Orange Book, although the section's use to Cypherpunk types is limited because it's written without any thought to, say, doing things cheaply or having a decentralized setup.) The tamper-resistance simply means that if the mailer was set up secure, it's not going to become compromised. Instead of having to trust that one of the remailer operators is currently honest and has always done all the necessary homework to ensure the system was safe, you have to trust that this entity was honest and diligent when the remailer was set up (unless, of course, you think the tamper-resistance was circumvented); if the operator is bribed after the remailer's set up and the public key is published, there's no way to suddenly and invisibly make messages traceable, as there is in a "normal" Mixmaster remailer. (This is because, given the normal assumptions about crypto strength, it takes the remailer's private key to process a Mixmaster-like packet and that key is generated by and stays within the tamper-resistant box) My predictions about the biggest attacks on a tamper-resistant remailer net: 1: traffic analysis. Until the net structure is overhauled, this will always be possible. 2: propagation and exploitation of faulty server software. Related to the whole web-of-trust issue. 3: direct attacks on specific clients. Again, no web of trust. 4: creation of bad remailers and attempts to shut down good ones. More messages could be traced in a world with 6 good and 47 bad remailers than in one with 9 good and 3 bad. 5: direct attacks on new remailers 6: attempts to make an operator feign a catastrophe and set up a new, compromised remailer. Users, however, would know that the new key not signed by an old one means that they must now trust that the remailer was not compromised before the publication of the new key. 7: attacks on tamper resistance ... n: attacks on crypto n+1: etc.