Joseph Ashwood wrote:

[Jim Choate wrote]:

...

The next major question is to determine where the drops are happening. Inbound, outbound, inter-remailer, intra-remailer?

That matters from a correction view but not from a usage view, which I assume we're taking. Basically we don't care what technology the remailer uses as long as it is correct technology and trustable. From there we care only what remailers are disfunctional and which are useful.

Hear, hear.

Correcting this is much more difficult, but would only take the use of digital signatures and encryption on all the messages traversing the network.

The quick and dirty way to do this is to sign and encrypt traffic between remailers with gpg. But, I doubt this will be necessary. (At some point something like this should be done, however, especially as the added encryption makes flooding attacks much harder.) It would be dumb for an adversary to attempt sabotage by causing message drops because we can definitively solve the problem and in doing so we may detect it, thus revealing the operation. For example, two remailer ops could collude to the extent of keeping checksums of their mutual traffic and comparing offline. This is indetectible to the active attacker, but his or her presence will be revealed. Once revealed, the ops can methodically and quietly track down how the attack is being performed. This would be big news. Far more effective is for an attacker to run a remailer perfectly, but quietly watch everything going by. (Hope nobody's taking notes! ;-)

...

If at all possible all measurements should be made anonymously and as stealthily as possible.

Agreed I was beginning to adress this above, it still has some major problems.

This isn't necessary if you have identified a working set of remailers. When they just work, you don't have to identify the bad ones. (Trust and reputation might be a faster way to get there than statistics.) The level of reliability specified, roughly 1 in 5000 messages dropped, is barely detectible and is thus a good value. If you send 10,000 messages in a month, that's about 330/day. For example, you might be feeding a few newsgroups through the mixmaster network to a friend. If the "packets" are sequenced and none are lost, then the goal has been achieved. This test could be performed as a side benefit of some other activity. Also, if the 1 in 5000 figure is truly independent (a stretch, perhaps), sending the message three times gives you less than one in a billion chance of failure. Good enough for government work.