Re: Remailer chain length?
Hi Scott, Forwarded message:
Subject: Re: Remailer chain length? Date: Fri, 31 May 1996 14:55:58 -0500 From: Scott Brickner <sjb@universe.digex.net>
If this is strictly true, why not simply run several instances of a remailer on the same machine. Then randomly chain them prior to sending them off site. This would be a lot cheaper and faster than trying to convince hobbyist to set it up or businesses to to use their profit & legal council.
Because it's not strictly true. Implicit in traffic analysis is looking at the "envelopes" of the traffic. Since this means intercepting those envelopes, once you've put your monitor on the first remailer at a site, you've probably gotten all the rest at the site for free.
I don't think multiple remailers at the same site help anything.
I agree completely. If traffic analysis is going to be done on a single box it isn't going to matter how many remailers are there. The monitor will simply grab them all. At this point it simply maps them thusly: incoming message > remailer #1 > .... > remailer #n > outgoing That this really maps to is obvious: incoming message > remailer #1-#n > outgoing The only thing this does is increase the number of valid entries in the From: field. Succesful traffic analysis does not require that the From: field contain only a single item. As a matter of fact it makes no difference what the headers contain unless the body is put in some kind of envelope for final delivery. Why? Because all one has to do is look at the body of the text which will not have changed. This leads to a simple model, based on a physical remailer: 1. Physical remailer receives an evelope addressed to them. 2. They open it and find a $1 money order (for paying the remailer) and another envelope with another delivery address on it. 3. Remailer puts $1 in bank and the interior letter in the mail. To convert this to electronic means: 1. Remailer receives a email that is encrypted except for the header. 2. Remailer decrypts mail (ie removes the outer envelope) and find three items, block of encrypted data (ie inner envelope) with header to next site and e$ token for $1. 3. Remailer sends the data on its way. There are a couple of points to be made. 1. No traffic is handled in the clear except for the header to the current destination all others are nested in encryption. 2. Remailer chaining is handled entirely by the customer (ie customer addresses the envelopes) 3. $1 is the smallest amount normaly accepted as a fee for a valid contract. 4. Remailer can't look at data because there is no way to find the correct sequence of keys to unlock the nested encryption. 5. Automaticaly limits spamming unless a remailer allows cloning AND all recipients share a commen private key. 6. It maps 1:1 onto the physical remailer model with the same limits on information at each stage. This allows one to directly apply the current history of precedence involving anonymity and physical remailers. Under todays current legal and social structure this is the only model that will prevent remailers from being held accountable for their traffic and at the same time provide enough income to keep legal protection at hand. Note that I am not saying you still can't be brought brought up on charges, simply that you (as a remailer) now have the structure in place to fight it succesfuly. This is the basic model that the Austin Cypherpunks are working on at the currrent time. The big problem we have right now is determining if the body is actualy encrypted. We have done some basic tests of encryption-spoofing using pgp and it is looks to be a thorny problem. It simply is not trivial to look at a block of characters and determine if they are actualy encrypted. You can't rely on the wrapper around the data put there by the encryption program because this can be kept intact and the data changed. As long as the checksum matches it all looks the same. Even if the test is done with a dictionary this won't help because rsa does not guarantee that once the data is encrypted that the output would be gibberish, sort of like the "All the monkeys in the world typing create Shakespeare" story. It is completely feasible (though unlikely) for the encrypted text to be something meaningful in some language or another. Jim Choate
Jim Choate wrote: | > I don't think multiple remailers at the same site help anything. | > | | I agree completely. If traffic analysis is going to be done on a single box | it isn't going to matter how many remailers are there. The monitor will | simply grab them all. At this point it simply maps them thusly: | incoming message > remailer #1 > .... > remailer #n > outgoing | | | That this really maps to is obvious: | | | incoming message > remailer #1-#n > outgoing Analyzing the traffic through three remailers is more difficult than analyzing the traffic through one. One remailer with three N messages per day is more secure than an equivilant remailer with N mesasges. [much good thought deleted.] | 5. Automaticaly limits spamming unless a remailer allows cloning | AND all recipients share a commen private key. Or unless the remailer mails to a mail to news gateway. | 6. It maps 1:1 onto the physical remailer model with the same limits | on information at each stage. This allows one to directly apply | the current history of precedence involving anonymity and | physical remailers. With physical remailers, you can open the inner envelopes and read the message, leaving the end user to wonder where the post office lost the message. With 'real' remailers, the lost message can't be read, only not delivered. | This is the basic model that the Austin Cypherpunks are working on at the | currrent time. The big problem we have right now is determining if the body | is actualy encrypted. We have done some basic tests of encryption-spoofing | using pgp and it is looks to be a thorny problem. It simply is not trivial | to look at a block of characters and determine if they are actualy | encrypted. You can't rely on the wrapper around the data put there by the I'm not sure I see why this matters? If you check that the message is not obviously readable, why not assume that its well encrypted? You're rarely required to contort yourself to ensure your customers are obeying the law (weaponsmiths, cryptographers, and banks excepted.) Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume
participants (2)
-
Adam Shostack -
Jim Choate