CDR: Re: Disposable remailers

[despot]

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