Re: My anonymous remailer

: Still, though, I think this would do more harm than good.  I get about
: 20 to 40 messages a day through my remailer, and only 5 or 10 of those are
: encrypted.  Switching to a policy that would require chaining and encrypt-
: ing to make it useful would make it a lot harder to use the remailer.  If

Agreed, but it would also force us to get off our butts and make integrated
remailer-aware mailers work properly, as opposed to the broken kludges
we have at the moment.  In the long term it would be for the better.
(Every single time I've tried anything fancy with chaining and encryption,
it hasn't been delivered.  And I don't consider myself incompetant.)

: The other problem I see with Graham's idea is that I'm not sure the
: technology is there to provide good security in the face of this much
: information.  Not many of the remailers add delay, and a lot of people don't
: like it when they do.  In that case it may be easy to figure out what

Again, fixing this up would be for the better good.  You can just imagine
that the FBI is already watching all remailers closely under arm-twisting
from the Software Publishers Association, not to mention the NSA doing
likewise for their own reasons.  I think we *should* force ourseles to make
traffic analysis visibly impossible.  If we can crack an anon posting
path with the same information available to an attacker who can monitor
all the lines, our system is broken.  We should put it up for peer-group
testing just like a new encryption algorithm.  I believe the security
of current remailers is a joke against a real attack.  It's *only*
good enough to hide identity from other usenet readers.  We might
as well all use only one-hop remailers and stop kidding ourselves
that the multi-hop stuff does any good at all.

(I don't believe the anti-traffic analysis support of the current remailers
is any good, which is why any postings I've made through remailers have
been single-hop in clear.  I just don't post anything that would get me
in legal trouble.  OK, maybe a couple of posts I've made would be
personally embarrassing if I were outed, but I wouldn't be by any LEAs
that were watching.  They'd just be able to use logged postings in
criminal cases)

: path even a chained encrypted message took.  Even the delaying remailers,
: if they published message sizes, would usually reveal their in-to-out
: correspondance.  So I think it is premature to do this.  Until we have
: remailers which can support cryptographically strong message padding
: with standard message sizes, running on un-hackable systems with delays
: and batching to confuse the in-out relationships, it would be counter-
: productive to do what Graham suggests.

Precisely my point.  Except I see it the other way - as long as we're
not forced to implement these measures properly, they'll never happen.

: service it's hard to know what features to provide.  In particular, if
: cleartext output is prevented, how much does that impair the usefulness of
: the network?  My instinct is that it hurts a lot, although it would be nice
: for the operators since it would eliminate most sources of complaints.

I meant that cleartext *input* should be prevented.  Cleartext output
however can be 'outed' in accordance with policy, even if it's personal
mail.  Also it can be silently dropped on the floor by the last-hop admin
without any comeback, for whatever egregious reason he chooses, or even
randomly.  It's up to the sender to pick a route that works.  If some remailer
admin (like JGdeA, or was it John Stanley?) choses to allow M.M.F postings,
then he can take the heat for them personally.

It's impossible to tell an email recipient apart from a mail to news
gateway, so we can't enforce encrypted output only, if we allow
posting.  However, the 'outing' policy makes it in people's best
interests to encrypt to the destination user if they can.

Unencrypted *mail* as well as news is also fair game for the
last-hop remailer admin to delete on his personal whim.

G

PS When I say we should out all information, I'm only talking about
information that's visible going in and out.  If we ever get my
earlier idea of chained encrypted reply-addresses to work, with
time-sensitive keys that are deleted after a few days, I'm not
suggesting publishing those keys.  Certainly, we should assume
that a few sites will be broken into, or even many sites, but
as long as one site remains uncompromised, there's a strong link
in the chain that holds up the entire chain.

Again, the best way to build a secure remailer is to have one that sends a
fixed "remailer-packet" to other mailers for internal communication with other
remailers on the "network"

These packets should all be super-encrypted and of a fixed size.  This size
should be as small as possible.  Say around 200K or so.  Why?  Because this
serves to prevent email spamming by severly delaying a message.   Also if there
is some quota of say, no more than 100 messages a day from a user, it serves
to limit spamming quite a bit.

Basically all incoming mail is spooled on the remailer's hard drive in encrypted
form by the remailer.  When a new message is sent to the remailer, the remailer
will go through all the received messages and look for duplicate messages and
also count the number of messages sent by the user who just submitted another
one.

At the end of the day, at a certain hour agreed upon by the remailer operators,
the remailer will split up its cached messages and split them among several
remailers with a RANDOM number of hops set in the message.  These packets will
then be randomly padded inbetween messages with null messages which would be
eaten by the receiving remailer.  The padding serves to limit traffic analysis
and the automatic hop number helps idiot users from being caught.

The packets will then be compressed and then would be encrypted with the 
respective public key of the target remailer and sent as a fixed sized block
again with rand padding at the end... perhaps via ftp or some other protocol,
but not necessarily via sendmail.  Having them as binary makes them easier to
handle than by sendmail...

When the packet is received by a remailer it would first decrypt it, then
decompress it, then remove null messages, then decrement the number of hops
and if it's zero, it would invoke sendmail to send them.

I strongly suggest that the remailer packet protocol be openly published so that
users can build their own packets to forward to remailers in encrypted form
rather than using sendmail.  I suppose that using sendmail to a remail should
still be allowed, but slowly phased out so as to force users to encrypt their
email.  Client software can be written for Windoze and Macs to use TCP/IP or
even Zmodem a packet into a remailer.

You may think that spamming can still occur by allowing users to send packets
themselves, however if the recepient remailer will limit the size of a packet
it will receive to a very small size (especially if it's coming from an unknown
site,) and refuse to receive more than one packet per day from that site, it
would prevent a lot of spamming and creeping detweilerism.

Perhaps remailers can work out a set of special private keys which they share
between them to speed up mail, or the size of the packet can be increased for
remailer-remailer transfers.

Anyhow, the system has to be balanced so that mail gets there in at most a
day or so, at best only a few hours depending on how often remailers talk to
each other.  If traffic at a remailer should suddenly increase, the remailer
should issue instructions to the other remailers that it'll send larger packets
or send more often.  But only after it receives permissions from the other
remailers should it send.

Perhaps if a remailer is too filled it should bounce a message to the sender
(if it knows his/her address...) or perhaps they can be polled to see if they're
busy, or better yet, the message can be forwarded to another remailer in the
old fashioned way (losing some security I guess)