Re: SUFFERANCE remailers

[jamiel@sybase.com (Jamie Lawrence)]

At 8:11 PM 9/27/94, Gary Jeffers wrote:

>   Anybody got any idea at all how to build a Fortress remailer?

As I see it, the main things one must defend a single machine
acting as a remailer against are physical accesibility, denial
of service and violation through monitoring mail flow.

The physical accesibility problem is tricky, but obviously has
been done for other physical items.. Stick it somewhere secret.
Of course you can't know how secret it is until someone tries
to find it. Wireless communication, as others pointed out, are
pretty nessessary for this.

The other two problems are software, and have been discussed quite
a bit here.

The answers above aren't bery compelling, and I don't see much way
around this. Groups with large amounts resources are typically good
at finding things when they put thier minds to it.

The solution here, and I think this has been talked about here, too,
is to create redundant destributed remailers.

Issues here are trust, protocol and availability.

Trust could be developed through the web of trust method, encouraged
by existing remailers using this protocol, but the key issue is being
able to trust a message going over potentially insecure remailer nodes
can be considered valid if delivered. That way if Julf ends up being a
under-deep-cover NSA agent and this hypothetical remailer-web is infested
with bad-guys, there is still nothing they can do except render a message
undeliverable.

I'm trying to come up with something good here, but am still working
on it. The vision I have for remailers in a perfect world is that
everyone runs one and bounces around message 'packets' (small parts of
the message (all signed and encrypted multiple times, of course)
according to specific instructions. In a less than perfect world,
a smaller network running this method could be created.

This takes the form of the originator dumping the message into the
stream, and forwards them off to some other sites. The message would
be split into small packets which are encrypted multiple times to
multiple different sites into the stream. This would probably have
to be done by software, as it would be a complex task to manually
split, encrypt etc. any but the smallest message. The software would
need to be kept up to date about all potential public keys to encrypt
to, and need to pick a set at random from this info. It would also
insert routing intstructions as needed.

The next site checks to see if it can decrypt the packet it
recieves. If it can, it does so and  sends it forwards it somewhere
else, and repeat. If not, it just sends it onward. This continues for
n layers of encryption for each packet, with the final message in the
form of x packets encrypted only once ending up at the proper destination,
which reassembles  the message. All remailers reorder packets and insert
noise as apporpriate.

Obvious problems are bandwidth, time delay and having a site the
message was signed to go down. The last issue can be taken care of
by having group keys for this purpose, so that a given layer of
encryption can be decrypted by any one of n sites with key m. This
adds the problem of someone collecting all the keys and being able
to crack the whole thing, but I think this is surmoutable.

Band width and time delay stem from the same problem, and obviously
this system would never work on the internet as it stands. If this
web were, say, 300 sites worldwide, then they could work conjunction
with the pre- existing remailers now available.

Also, if the network grew to the point where it was impracticle to bounce
at random, intermediate steps could be added, such as 'send me to austalia'
or 'send me to mafiaNet', which would then cut down the number of bounces
before a layer of decription was achived.

As far as availability, well, it doesn't exist.

Comments? Is this dumb? Did I just duplicate someone elses idea?