Re: CNN.com on Remailers
Depending on the recipient, you might or might not be encrypting the message. But the important security you're protecting is the connection between the sender and the recipient. Depending on the application, the sender may be trying to prevent the recipient from knowing his address, or the two of them may be trying to prevent outside eavesdroppers from knowing that they're communicating, but in either case, you only have that security if you can trust the remailer system not to divulge the relationships. If you let the sender's system do all the encryption, then the entire chain needs to be compromised for the connection to be revealed; otherwise any remailer along the way can rat him out. That doesn't mean that you can't gain some security by remailers in the middle also adding hops on their own, but the sender can't depend on that (at least unless he trusts the remailers that are doing that), and of course you risk routing loops, which are ugly things to detect in connection-obfuscating environments. At 10:02 AM 12/29/2001 -0600, Jim Choate wrote:
On Sat, 29 Dec 2001, Bill Stewart wrote:
At 09:01 PM 12/17/2001 -0600, Jim Choate wrote:
The only way to get security is for the originator to do the encryption - otherwise, if ANY remailer in the chain is compromised,
Actually this isn't the 'only' way. ALL (!!!) that is required to keep the security of the email traffic is that it is source encrypted for the destination; it's gibberish to all middle-men. What the remailer chain does is break the causal connectivity, it provides plausible deniability. ....
the Bad Guys can read the message.
At no point can anyone other than the recipient 'read the message', unless it was sent in the 'clear' in the first place (silly thing to do).
If the originator does the crypto, then EVERY remailer in the chain has to be compromised to break it.
ROTFLMAO. ONLY(!!!) if the source didn't destination encrypt to begin with. A critical step you seem to not quite 'get'.
On Mon, 31 Dec 2001, Bill Stewart wrote:
Depending on the recipient, you might or might not be encrypting the message. But the important security you're protecting is the connection between the sender and the recipient.
Agreed, assuming that something in the text itself wouldn't be identifiable or traceable. In any sort of real world application such a breach of security is considered incompetent. Since most real world assume that something in the text itself is incriminating (it's sort of axiomatic to the whole point of encrypting in my mind) we can assume it is encrypted at the source, using the destination keys. Then one takes the string of remailers that one wishes to chain through in reverse order, encrypting each step along the way. So that all that would be visible to any MINTM is a header with the next To: and a block of encrypted text.
you only have that security if you can trust the remailer system not to divulge the relationships.
Agreed. It's the primary weakness (at least in my mind) of the current approach, too few numbers by several orders of magnitude. I also think that a major underestimation made by the vast majority is the actual estimation of cost. When one considers that most real world examples will have outside issues that will at least direct Mallet to one of the participants. At that point it would not be that expensive to grab a snapshot across some time window (say 24 hours) of the remailer network given some sort of 'trigger'. The cost would probably be well within the range organized crime, third world countries, and some of the wealtheir individuals. It wouldn't be cheap but I doubt it would cost $1BUS for a 24 hour snapshot via black bag jobs (I'd be so bold as to say that a few million might be enough if the planning and skillset are there). -- ____________________________________________________________________ Day by day the Penguins are making me lose my mind. Bumper Sticker The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------
participants (2)
-
Bill Stewart -
Jim Choate