On Thu, 5 Oct 2000, Bill O'Hanlon wrote:
It might not be able to have crypto. I'm not sure if something PGPish can be ported to it and still leave room for the incoming message. It comes with less than 300K of useable RAM. However, the TINI does have a socket on it for an Ibutton, so one of Dallas' Crypto or Java buttons might be able to take on the crypto load. That's more money per unit, however.
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.
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.
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? -andrew