CDR: Re: Disposable remailers

[Sean Roach]

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.

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.


>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 
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