CDR: Re: Disposable remailers
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
On Fri, 6 Oct 2000, despot wrote:
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
This reminds me of something I was looking at this spring. Markus Jakobsson has two papers on "A Practical Mix" and "Flash Mixing" which look at mix-nets in a different way than we see in remailers. There, instead of a message being successively encrypted for a particular path through a series of remailers, the remailers pass a prepared encrypted message around and perform a distributed computation on it. At the end of the computation, the decrypted name of the recipient automagically pops out. These kinds of remailers are not original to Jakobsson - but previous efforts that I know about are ridiculously inefficient. The number I remember for one of them is 1600 modexps per message per server. Jakobsson's "Practical Mix" proposal is more like 160. The "Flash Mixing" paper investigates ways to use precomputation to get this to 160 multiplications. I should mention here that Yvo Desmedt and Karou Kurosawa showed in Eurocrypt 2K that the original "Practical Mix" paper has a flaw -- an evil node can cause one of the distributed computations to abort without being caught. They noted that their results didn't extend to the "Flash Mixing" paper; it's been a back-burner project of mine to look at this for...well...too long. Anyway, both papers deal with a collection of mix servers fixed in advance. It seems that disposable remailers would work well with extensions of these protocols modified to deal with dynamic leave and joins of servers. Add this to wireless and you have mobile disposable remailers. Slightly related would be the idea of using commodity computation to do remailing -- just tell people to "go to this page, download this applet, become a remailer!" (or have your HD erased, but...) There are massive issues with trusting new remailer nodes, unfortunately. Imagine what happens when your adversary decides to show up with polynomially many of her closest friends. So a further question would be whether we can design a mix protocol which can a) take advantage of all these cheap, (hopefully) distinct devices and their computation power but b) doesn't give the commodity devices enough power to break the mix, even if many (almost all??) of them act in concert.
On a side note, what other throw-away internet-ready devices would be of interest? Motion detectors? Access control devices? Door locks?
Pretty much everything, if you believe some people. The Oxygen project at MIT has a vision of computation in absolutely everything. Desmedt has an intriguing article about just what might happen then.. -David
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
participants (3)
-
despot -
dmolnar -
Sean Roach