At 04:34 PM 10/6/2000, despot wrote:
Perhaps this idea would work on low volume remailers. An iButton could be loaded with an applet to perform public key crypto, and thus, a sort of mixmaster remailer could be constructed. But, the memory constraints on iButtons (I believe 134K is the max currently available) and their slow speed may even rule this out for a low-volume remailer. And, as Bill mentioned, latency and reordering would not be feasible. Without those features, the amount of anonymity is reduced.
If the net is sufficiently large, then the remailers can be considered to be registers, each holding one message for a random length of time, and allow reordering just by that alone. Of course, for this to work, traffic analysis has to be defeated in another way. Probably in ZKS's planned, but last I checked, not implemented, constant activity among nodes. Of course, the more traffic, the easier it will be for the intranets where these things are set up to locate them, and take them down.
I'm envisioning that the code would announce itself to some set of web servers so that people can know where to find a few of these transient remailers when they wanted to send some messages.
Problems occur if the locations of these tini remailers are spread through such means. If the addresses are posted to a web site, tracking down such remailers would be simple, quick, and as thorough as the list of the remailers.
An alternative might be the method that gnutella uses. Each remailer connects one time to a web page put up by the installer. That web page has a limited number of URL's, mostly of other remailers also put up by that same installer, or that installers gang, (substitute cell, orginazition, liberation front, family, user's group, etc). A few are shared by mundane means among cells probably through alt.anonymous.messages, or similar. This allows the remailers to be linked across parties. Each remailer keeps as many remailers in memory as it can, not to exceed a set number, for the safety of the others, and not to drop below another number, set based on practical use of the remailer. (As an example, if a node only remembers 1 other, it no longer is useful for anything but an input or output node. If it only remembers 2, all it can do is pass a message from one to the next.) All this is kept in volatile memory. The nodes ping each other on a regular basis, if a node fails to respond to a ping, that node is written off. Perhaps the next general cover traffic includes information that such-n-such node appears to be compromised. If a node receives NO pings, then it might also write itself off, and blank memory. If extra nodes are occasionally inserted into the system by hailing known nodes and "topping off" their "neighbor list", then well hidden nodes can continue to be used, even after all the original neighboring nodes have been revealed and deactivated. This could even be done through the node network. If a minimum of 3 neighbors is set, and a maximum of 7, and if each URL requires 8+8+8+8+16 bits to store an address, then each remailer needs 18-42 bytes extra in which to store addresses. The URL for the web page can fill this memory for the first run, and would allow for, beyond the URL, 12-36 characters in the address. Actually, message space could also be used to store this boot address, and therefore, shouldn't be a problem at all. It could even be stored as a standard non-ip-number URL. (Say www.geocities.com/hollywood/rodeo/1324/weblist, please note that if this url is functional, I don't know it.) After setup, the node should forget everyone but it's neighbors, to protect them, anyway.
Also, due to the small memory footprint, it doesn't look like a lot of messages can be stored locally, so there's not a lot of room for latency and message re-ordering.
Use of these tini remailers should really only be done in a remailer-chained message. Of course, the chain would need to include one or more non-tini remailers. This way, even if all tini remailers are monitored, you still have a remailer that provides some level of obfuscation through latency and reordering.
But, this disposable remailer idea is solid. As a quick example scheme, if there were some sort of remailer protocol that functioned like routing protocols, as disposable remailers came online, they could announce themselves to other remailers. Pseudorandom hopping from one disposable remailer to another could occur in a remailer-chained message, instead of manually encrypting a message for a chain of remailers. The sender could encrypt the message for the gateway and final non-disposable remailers and then specify a hop count. The first non-disposable remailer would decrypt one layer of encryption, decrement the hop count, pick pseudorandomly a disposable remailer to pass this message to, encrypt this message and pass it on. When the hop count hits one, the message is just forwarded to the final non-disposable remailer in the chain, which would then decrypt the final layer of encryption and passes it on to the recipient. Of course, this example is just something I pulled out of my ass...read up on more advance schemes if interested.
The dynamic property of such a scheme would be ideal for disposable remailers. As they are discovered and removed, the system would compensate. With cheap cost, simple set up, and ease of hiding, disposable remailers could be brought online faster than they are taken down. And, if placed anonymously, there will no one to be held responsible for the devices.
So, are small devices like tini's the ideal form of the future remailer? Is some sort of distributed, dynamic remailer scheme based on small devices the way to go? The stable remailer running on a box is subject to all sorts of legal issues, isp problems, etc. These covert, anonymous remailers have a great deal more freedom.
On a side note, what other throw-away internet-ready devices would be of interest? Motion detectors? Access control devices? Door locks? ... All of the above. Take home that I-coffee pot, add a tini, take it back to
As I said above, if the latency is random, and the traffic suficient, re-ordering will just be a matter of one message taking a different, and longer, route than another, but by artifically increasing traffic, or even traffic increasing on it's own, you reduce the expected lifespan of the node. the store and apologize that you already had one that you're new inlaws gave you. Same with the door lock, then apologize that your apartment super won't let you install it after all. An extra level of obfuscation is thus created in that dupes install the very remailers that you rigged. They are far less likely, as homeowners living in an electronic age, to realize there is more traffic going over thier connection than they bargained for. Big brother becomes unwitting courier for the underground. Or did you mean in addition to disposible remailers, instead of ways to hide, distribute them? Good luck, Sean Roach