On Sat, 11 Aug 2001, Joseph Ashwood wrote:
On Sat, 11 Aug 2001, Joseph Ashwood wrote:
Actually you can start with just one trusted remailer.
Bull.
Well technically you begin by granting trust to someone, the easiest being yourself. Then you build trust in something else, use trust in one thing to build trust in another. Regardless you have to establish trust in a single location, before you can build trust in multiple.
The point is that one remailer isn't sufficient (especially if you've got some sort of fixed latency, which is pretty much a given even if the window is 24 hours). Assume a single remailer. Both input and output stream are sampled. We must assume that the from: and to: are observable. To deny the from: implies a secondary anonymizing layer, contrary to our intial assertion. To deny to: implies that there is an additional layer between the last remailer and the recipient of the traffic. The goal of a remailer is to break the connection between a given incoming and a given out-going (ie mix the to:/from: relation) - not to hide either necessarily. So, even if we generate cover traffic a comparison of all outgoing with each incoming is clearly realizable using modest resources (not including the tap itself). As long as your sample window around each from: event is greater than the latency, you'll find a statistical correlation to the to: event. It takes at least two remailers and they must in addition talk with a shared keyset different than either from: or to: might use to encrypt the body. Now, let's talk about that cover traffic for a moment... It's random, so subsequent comparisons based around to: or from: events will cancel out because they won't be repeated often enough. There is the additional question of just exactly who we're sending that cover traffic to since we're the only remailer. In addition there is the problem of exactly how we produce all that bogus traffic. My suggestion is keep a steady flow of messages (ie #msg/t >= C, dmsg#/dt = 0) to a well known set of addresses (remailers of course) and then randomly replace the bogus traffic with real traffic in a round robin selection process. Any real-world realizible system requires(!) at least two remailers who are not(!) in collusion with each other, and they must share a different set of keys than either to: or from: might use. The only workable solution to that, which doesn't involve 'trust' per se, is to move to a distributed environment with autonomous process execution. There is of course a discussion of self-sufficiency w/ respect to e-cash schemes in here, but that's a different topic. Additionaly there is the Plan 9 process bidding mechanism that fits in here as well. Then you request a image of that program (which is running other images elsewhere) to run in your own process space. You can verify the signature of the image by comparing it to known good signatures (and the algorithm they were used). This way each image of the program gets 'paid' for by being run by the user directly (though they have zero control over its environment mind you - excepting hacking the process mechanism in the OS - which recurses to the remailer getting a signature of the OS and itself to verify it hasn't been hacked. Some nifty problem/solution sets in here). You could of course do this today with the existing mix-masters to a certain extent. Linux would of course be a good example, though from a image used - signature perspective MS would be more stable with all the custom Linux kernel compiles (and over 180 distro's). (If any of these ideas are patentable then I put them in the public domain) -- ____________________________________________________________________ natsugusa ya...tsuwamonodomo ga...yume no ato summer grass...those mighty warriors'...dream-tracks Matsuo Basho The Armadillo Group ,::////;::-. James Choate Austin, Tx /:'///// ``::>/|/ ravage@ssz.com www.ssz.com .', |||| `/( e\ 512-451-7087 -====~~mm-'`-```-mm --'- --------------------------------------------------------------------