Hi Adam, Forwarded message:
From: Adam Shostack <adam@homeport.org> Subject: Re: Remailer chain length? Date: Tue, 4 Jun 1996 22:57:10 -0500 (EST)
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.
Not if they are on the same box, simply treat the box itself as the remailer. The internal mechanics are for the most part irrelevant to this issue. N messages go in, N messages with (number of remailers)(# of cover traffic/real message) messages of cover. My contention is that it does not matter how many remailers are on a single box. It is the number of connections in and out of the box available. The above equation is clearly linear and therefore not what I would consider computationaly challenging. If I may introduce some terminology (unless their is an existing stnd.), x number of messages y message multiplier N#() remailer number # R#() number of remailers on machine # C() number of cover messages/original messages E# number of connections on machine # T() total traffic through remailer system $i() cost per message, incoming $o() cost per message, outgoing C fixed cost items of operation (eg rent) Note: each of these represent a family of functions. My contention: T(R#(n)) is equivalent to T(R#(N1(x), N2(x)..., Nn(x))) Where, T() = R#(n)(2N#(x) + C(yN#(x))) The term 2N#(x) represents the number of valid messages the remailer handles. x incoming & x outgoing, hence 2x. The total income of such a remailer: $(T(x))=$i(x)-$o(T(x)-x)-C It is important to recognize the profit dependancy on the input/output message ratio. If it gets too high, you got nothing to spend on yourself. Your contention (if I may translate): N1(3x) is more secure than N1(x), assuming identical remailer configuration. Do you consider N#(ax) equivalent to aN#(x)? May I inquire into your reasoning?
[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.
This is a limitation of the mail-news gateway and not of the remailer technology. What it points to is a serious shortcoming in mail-news gateway software. The technology required for truely efficient newsgroup handling is something sorely in need of work.
| 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.
If the encryption technology is secure. The point I am making here is that the encryption envelope is 'secure' only so long as nobody is trying to crack it. Sooner or later somebody is going to decrypt your message, if not the entire encryption system. This is synonymous with the physical model. The paper envelope is secure as long as somebody isn't breaking the law by tampering with the mail.
| 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.)
Ok. Let's for a moment assume that to send a message to 'president@whitehouse.gov' with 'Die Bill!' is a crime. Would it not be a crime to foil a packet of encryption by inserting 'Die Bill!' messages in clear text in the encryption block? To date, provided no attempt at actual decryption is attempted, there is nothing in the standards that prevent this other than digital signatures. And again, a specific program has to be executed. A person might very well look at it as plaintext w/o ever running digital signatures (or they just assume its always right). Would this also be a crime? Jim Choate "Reality is observer dependant" \ \ \\///// | | (.) (.) ===========================oOO==(_)==OOo========================== Tivoli an IBM company CyberTects: SSZ Customer Support Engineer SOHO Consulting/VR/Robotics 9442 Capitol of Texas Highway North 1647 Rutland Suite 500 #244 Austin, TX 78759 Austin, TX 78758 Email: jchoate@tivoli.com Email: ravage@ssz.com Phone: (512) 436-8893 Phone: (512) 259-2994 Fax: (512) 345-2784 Fax: n/a WWW: www.tivoli.com WWW: www.ssz.com Modem: n/a Modem: (512) 836-7374 Pager: n/a Pager: n/a Cellular: n/a Cellular: n/a ===================================================================