Re: Remailers: The Next Generation

In article <2hq9sv$cdq@uudell.us.dell.com> you write:
>From: jim@bilbo.toad.com (Jim Miller)
>Message-Id: <9401212232.AA06926@bilbo.suite.com>
>Date: Fri, 21 Jan 94 16:32:13 -0600
>To: cypherpunks@toad.com
>Subject: Re: Remailers: The Next Generation
>
>Since the remailer system works better (harder to track messages) as  
>message traffic increases, then perhaps the remailers should circulate  
>bogus messages around the mix in order to sustain a minimum level of  
>traffic.  As more real messages enter the system, the remailers would  
>decrease the number of bogus messages they issue.
>
>How would a remailer tell the difference between a real message and a  
>bogus message from another remailer?  It wouldn't, but that's ok.  All a  
>given remailer cares about is the number of messages coming in versus the  
>number messages that constitute a "good" level of traffic.  If a remailer  
>isn't seeing enough traffic, it would issue some bogus messages that would  
>pass through a random set of remailers and eventually come back to itself.

Hm... actually what one could do is set up a remail/DC-Net combination,
maybe this has already been suggested in a different form, but first
you set up your anon-net, as a virtual ring topology between your remailing
sites.  Alice wants to send an annonymous message to Bob, such that
Bob can reply back without revealing Alice's email address.  First off,
Alice public key encrypts a message to remailer site "Zeta".  This
message contains an encrypted message block to remailer "Iota".  This
message block contains a reply header to remailer "Epsilon".  Zeta receives
a message encypted to it.  It decrypts the messages picks a new remailer,
at some random distance (n/2 + R) hops away.  In this case remailer "Gamma".
Zeta encrypts the message to "Gamma" and inserts it into the
anon-net ring.  When Gamma receives the message, it takes it, decrypts it,
puts the plain message(still encypted by Alice to "Iota") back in.  Iota
gets the message, re-addresses it to yet another remailer chosen at random,
"Delta".  Iota actually builds the final outgoing mail message and that
is what is encrypted to "Delta".  Delta takes the message and mails it
to Bob.  (Alice of course first encrypted the message with Bob's public
key).  Bob can of course reply to the message by prepending the "Epsilon"
message block to his reply, and using encrypting remailing to some remailer,
"Sigma", Bob can reply to Alice's message, protecting Alice's identity
in several different ways.
	Because of the remailer ring using a random number of hops, i.e.
the distance (N/2 + R, where R is between N/2 - 1 and 1), message
latency is random.  Because each message is ecrypted to the upstream
neighbor, direct monitoring is foiled.  By using a fixed size message,
say ~100K, and each site padding any data to the fixed size and including
that in the encrypted data sent to the upstream site, an outside
agency can't monitor packet size to determine anything.  No even
if a spy is in the net, say a remailer at "nsa.gov" any messages passing
through are protected by the difficulty of the encryption.  The site
will know which remailer sites on the ring are being sent to, but
because the the random remailer step in the middle it can't even tell if
the message is incoming or outgoing.  Two sites i.e. "fbi.gov" and nsa.gov,
could work together, but still not getting useful information
most of the time.  Thus, as long as the entrance port to the ring
is not a spy no one knows you are sending anonymous mail.  And assuming
the exit port is not a spy no one knows Bob is receiving aonymous mail.
	Just by putting a few of these ring nodes in places like 
Finland, or even on commerical backbone sites(Alternet, Sprintlink, etc)
makes government monitoring more difficult(or even non government 
monitoring).
	I think this can actually be improved on by hiding the internal
ring identities, but my  brain is not working as well as I would like
and I can't find any detailed info on the "dining sterlight net".
	Actually I think something like this might work well at the
socket level to give a higher bandwidth to directly connected sites,
using mail and mail agents to simulate a token ring network, is not
the most efficient usage of bandwidth, particularly with things like
message length restrictions.
	I've been wanting to set up and play with remailer's but,
my unix host doesn't want to allow |'s in .forward's or the sendmail
aliases.  (I'm assuming this is a feature due to the sendmail bug from
several months ago, I haven't had time to learn sendmail or ask
our resident sendmail expert how to fix it).  


-- 
 Jeremy Porter  -----------------  Systems Enginneering ----
 Dell Computer Corp. --- jerry@terminus.us.dell.com --------
 ------------------------------------------------------------
  Support your Second Amendment rights to encryption technology.

The following is the specifications of the proposed anonymous remailer
system ( described by various people here ) as I understand it.

   1)  all messagess are PGP ( or otherwise ) encrypted to hide their
       content.
   2)  real headers and to/from lines are stripped and replaced
       with a code which the system uses to retrieve that information
       when the message is answered ( double-blind ).
   3)  from their first entry into the remailer system, messages
       are rerouted using one or more of the following methods
       in attempts to defeat message traffic analysis and tracking:

          i) random garbage prefix/suffixes used to pad messages
         ii) multiple messages combined with possibly dummy messages
             before remailing through random number of stops in
             remailer system
        iii) message remailings are delayed by a possibly message-sender-
             defined amount of time.
         iv) messages are sent via atleast one non-American remailer


Given that my understanding is basically correct, why couldn't
the remailer system be set up similarly to the way IRC is?

detailed example :

When one wants to send a message, she would load up a local Anonymous
Internet Remailer (AIR) daemon which would attempt to connect to one of
the AIR clients running elsewhere on the Internet.  Then she would send
a PGP pre-encrypted message down the line, prefixed with the e-mail
address of the person who is to receive the message.

At this point, the AIR-client sends out a general message to the other
AIR-clients.  This message contains an encrypted copy of the receiver's
e-mail address.

The response to this message is two-fold.  First a response is
circuitously sent back to the original AIR-client, telling it that an
alias has/has not already been assigned by that AIR-client to the
receivers e-mail address; further, if one has been then a reference
number would be assigned to the message ( which it does not have a copy
of ) and be sent back in the same message.  Second, if the alias exists
then the responding client sends a circuitous message to the receiver's
e-mail address telling him that he now has AIR-MAIL waiting for him.

If none of the responses about the alias are positive, then one is
assigned by the original AIR-client, and encrypted 'add new alias'
messages are sent to two other randomly selected AIR-clients to ensure
that the alias is redundandly recorded.  The original AIR-client would
then assign the reference number to the message.

In either case, the reference number would always be used to reference
the message.

The encrypted message is then sent circuitously to a random number of
other AIR-clients.  After all of these have responded to the original
AIR-client that the message was received, the original AIR-client would
then choose atleast two of them ( again for redundancy ) to keep the
message, all others to purge it.  This same encrypted hold/purge message
would then be sent circuitously to ALL of the holding AIR-clients.
Finally the original AIR-client would purge its copy of the message.
(this does not however, preclude the original AIR-client's being one of
the holding AIR-clients)

The AIR-client <=> AIR-daemon and AIR-client <=> AIR-client connections
could invisibly handle further encryption and padding.

Finally, the message needs to be picked up by the intended recipient.
He would run the AIR-daemon on his machine, which would then connect to
one of the AIR-clients ( this being hereafter the receiving AIR-client
). He would send the message reference number, which the AIR-client
would then encrypt and send out in a general message to all of the other
AIR-clients... requesting that they send this message.  If an AIR-client
has the requested message then it pads, encrypts and sends it...
otherwise if the AIR-client does not have the message it creates a
garbage file which it encrypts and sends to the receiving AIR-client.

The receiving AIR-client would then send one copy of the message with
the correct reference number to the receiver's AIR-daemon, where it
could be saved on disk.

This system has several advantages over a purely e-mail based system:

     i) messages would no longer be limited to 60k in size as it is now,
        due to the fact that none of the messages would actually be sent via
        e-mail.
    ii) every site and daemon could have a unique encryption key for use
        by the other sites.
   iii) even if the message is tracked to its holding client, the trackers
        still have to chase it again when the receiver requests its delivery.
    iv) the receiver need not necessarily be at his home e-mail address when
        he requests the message.  he could choose to run the AIR-daemon
        on a remote host several rlogins from his home site.
     v) if coded well, any user could run an AIR-client on her home site,
        thus permitting the network to grow to hundreds or thousands of
        sites very quickly, each with much lower overhead than the current
        non-networked, anonymous remailers available.

        Futher, as administrator of that particular AIR-client, the user could
        configure her AIR-client's involvement in the overall AIR-network based
        upon the resources of her system.  She could for example, choose that
        her site be only a remailer site and not a holding site, or vice
        versa... thus adding further message tracking problems for any snoopers.


Futher hairyness which could be added:

     i) AIR-daemons could accept command-line parameters rather than
        being full interfaces, thus allowing redirect.
    ii) listserv software could be configured to allow connection to
        the AIR-network, thus allowing someone to send a PGP-encrypted
        message to the listserv for forwarding via the AIR-network.
        A further advantage of this is that users from non-Internet sites,
        such as CompuServe or RIME could still make use of the remailer.
   iii) the receiver could send the message code to a listserv for
        message retrieval.
    iv) when a user starts up an AIR-daemon on his machine, make it
        automatically continue to run and become another non-holding bounce
        site, thus accounting for why messages are suddenly being sent
        to a non AIR-network site.
     v) one could have several completely separate AIR-networks running
        on the Internet.  These would dynamically expand as more people
        ran daemons.


Constructive comments solicited...

-Garet          {Garet.Jax@nitelog.com}

While you guys are thinking about where to take this stuff at the
application level, how about giving some thought to how you might do
it at the IP level?

Since IP is a much more fundamental Internet service than mail, any
anonymity functions we might add to it could have much wider
applicability.  For example, consider anonymous FTP sites that a)
insist on your IP address having an inverse DNS entry, whether it is
under your control or not, b) insist on a user's name and c) log every
file retrieval? An anonymous IP service could effectively put a stop
to this practice.

Phil

Phil Karn <karn@qualcomm.com> wrote:

> While you guys are thinking about where to take this stuff at the
> application level, how about giving some thought to how you
> might do it at the IP level?
>
> Since IP is a much more fundamental Internet service than mail,
> any anonymity functions we might add to it could have much
> wider applicability.  For example, consider anonymous FTP sites
> that a) insist on your IP address having an inverse DNS entry,
> whether it is under your control or not, b) insist on a user's
> name and c) log every file retrieval? An anonymous IP service
> could effectively put a stop to this practice.

Well, it would make tracing FTP difficult, altho, at least intially,
some FTP maintainers might try to block known IP rerouters.  Of course,
if such rerouters became commonplace, it would eliminate that problem.

I think the real problem is hardware costs and availiablity.  Running a
remailer is cheap and easy (for some people).  However, running a decent
IP rerouter would require your own internet node, supported by at least
a 56K connection, if not a T1.  Very few people own or have access to
that kind of hardware.

Does anyone how much it costs to get a continuous 56K internet
connection?  What about a T1?  How easy is it to get and set up?

Why not set up a mailgroup (such as cypherpunks.pgp) wherein ALL
messages are PGP encrypted?  Once one subscribes to the group, she would
receive a message containing both the standard further information about
the group as well as public and PRIVATE PGP for the mail group keys to
add to her PGP key ring.

Then whenever she sent a message to the group remailer
(cypherpunks.pgp@toad.com) it would already be PGP encrypted with the
group key.  And anyone who received that message would be able to open
and read it because they would already have the private key for the
group.

The remailer could check the messages before forwarding them to the list
subscribers to make sure that they are PGP encrypted.  If they aren't
then they wouldn't be sent... a nice side effect of this would be that
the list subscribers would no longer receive those 'unsubscribe user'
messages as most likely these would not have been encrypted before
mailing.

-Garet          {Garet.Jax@nitelog.com}