At 09:01 PM 12/17/2001 -0600, Jim Choate wrote:
On Mon, 17 Dec 2001, Trei, Peter wrote:
and sends the contents on to the next address (yes, this type of remailer does not include nice features such as cover traffic).
And it can't encrypt that outgoing traffic since it doesn't have the key to the destination (I assume the user must nest these themselves).
Yes, the user must nest those himself. If he doesn't like doing it by hand, there are client programs that can do this automagically. The only way to get security is for the originator to do the encryption - otherwise, if ANY remailer in the chain is compromised, the Bad Guys can read the message. If the originator does the crypto, then EVERY remailer in the chain has to be compromised to break it.
The sender having to know all the steps is a major threat to the standard remailer model. In fact it's one of the major shorcomings with the current approaches. The sender should at most be able to set the number of remailers, not which ones. That way there's on evidence sitting around on their machines (and you can posit throwing the keys away each time - but then you have to go out and get them again...and around and around we go).
The remailer-stats pingers publish this information on web pages; you can retrieve it and read it by hand, or use a client program to fetch it. If you don't want to keep it, don't. And some of the clients are web pages themselves (Javascript or whatever), so you can just retrieve them. And obviously the sender needs to be able to pick the remailers to use - depending on the type of message, some messages need to be sent through remailers in appropriately safe jurisdictions, other messages don't need much security but need high reliability or high speed (so you want to pick remailers with good stats.)
On Saturday, December 29, 2001, at 03:27 AM, Bill Stewart wrote:
At 09:01 PM 12/17/2001 -0600, Jim Choate wrote:
The sender having to know all the steps is a major threat to the standard remailer model. In fact it's one of the major shorcomings with the current approaches. The sender should at most be able to set the number of remailers, not which ones. That way there's on evidence sitting around on their machines (and you can posit throwing the keys away each time - but then you have to go out and get them again...and around and around we go).
The remailer-stats pingers publish this information on web pages; you can retrieve it and read it by hand, or use a client program to fetch it. If you don't want to keep it, don't. And some of the clients are web pages themselves (Javascript or whatever), so you can just retrieve them.
As others have remarked, Choate simply has no clue how even the Cypherpunks remailers of 1992 work(ed). That he thinks "having to know all the steps" is a bad idea tells me he is just too clueless to have ever been taken seriously, even for a few months, here on this list. An old girlfriend of mine grasped the idea of envelopes-within-envelopes and how the security of the remailer chain depended on the sender deciding on a list of intermediate steps and then encrypting each nested envelope appropriately. "The sender should at most be able to set the number of remailers, not which ones. " is one of the stupidest comments I have ever seen on this list. This has been Cypherpunks kindergarten material for a decade (and many of us knew it years earlier). --Tim May
And obviously the sender needs to be able to pick the remailers to use - depending on the type of message, some messages need to be sent through remailers in appropriately safe jurisdictions, other messages don't need much security but need high reliability or high speed (so you want to pick remailers with good stats.)
--Tim May, Corralitos, California Quote of the Month: "It is said that there are no atheists in foxholes; perhaps there are no true libertarians in times of terrorist attacks." --Cathy Young, "Reason Magazine," both enemies of liberty.
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. Now, with respect to middle man routing, if each middle man routes to another layer randomly then it addresses the exact issues of a 'turned' remailer. In addition, with the current 'ad hoc' key management mechanism getting intermediate keys isn't that hard (just pose as a remailer operator and they'll gush into your keyring). A solution to this problem, that you won't accept but 'oh well', is to create the network using 'small world' approaches so that the remailers have a 'back channel' to continously validate the 'reputation' of the next stage remailers (ie ala 'igor') while at the same time not even knowing what other remailers out there might exist in the 'remailer cloud' (and more importantly not caring). This approach has a couple of additional advantage; it doesn't require the user to understand some hard to comprehend syntax for the remailers, and it doesn't require the user to keep all this evidence around a priori to their actual use of the remailer chain (ie they don't have to d/l a key from anywhere mecessarily) - traffic analysis.
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'. [other 'stuff' deleted] -- ____________________________________________________________________ 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 (3)
-
Bill Stewart -
Jim Choate -
Tim May