From: rjc@gnu.ai.mit.edu (Ray)
Date: Mon, 4 Apr 94 22:12:11 PDT
To: cypherpunks@toad.com
Subject: Re: REMAIL: Ray's improved anonymous remailer
Message-ID: <9404050511.AA10240@geech.gnu.ai.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain


Hal writes:
>These mostly sound like great features.  The virtual addresses are something
>we have needed for a long time.  The idea of keeping records of which remailers
>are responding should help with the use of the network, too.  The one problem
>with this is that it might be tempting for the users to just trust the
>remailers to choose their chain paths.  It would be much better for the user's
>own software to hook up, find out which remailers are operating, then choose
>a chain.  Ray's software will allow this, but this function could be split
>off from the remailers to a specialized server, perhaps.

   Good idea. The remailer assumes a few things. 1) if you don't
give an explicit chaining path, and chaining is turned on, the
remailer automatically picks the remailers with the heaviest usage for
chaining. 2) if you give an explicit path, do not override it unless a 
remailer in the path doesn't respond

   A better idea might be a sort of "domain remailer naming service"
which locates users on a remailer network (instead of explicitly
giving out the remailer that your virtual address is located on) This
DrNS would have to be trusted and secure, but it does cut down the
number of trust entities since you only have it to trust, not every
remailer on the network which has a copy of where your virtual address
is located. Julf's APS is sorta like this already.

   I like the decentralized approach best. Let's say you don't want
any plaintext associated with your real e-mail address. Simply
set up two virtual addresses as follows:

Remailer1: foo -> rjc@gnu.ai.mit.edu
Remailer2: AnonymousRay -> foo#remailer1

  Now when a plaintext arrives at remailer2, it is encrypted for
remailer1, and with *your* public key (associated with "AnonymousRay")
if one is present.

  So one remailer sees (plaintext, foo#remailer1), the other one
sees (ciphertext, rjc@gnu.ai.mit.edu), but neither sees
(plaintext, rjc@gnu.ai.mit.edu) Of course, collaboration is a problem,
but you can always increase the chain length to take care of that.

  You can include SASE standard cypherpunk remailer blocks too if you
want to further confuse the issue.

>I'm not sure about the advantages of remailers signing and encrypting messages
>between themselves.  It seems to me that the network should work even without
>this.  Ideally we don't want the remailer network to be too centralized and
>close-knit.  It's better for them to be strangers to each other since if they
>coordinate their efforts they can defeat anonymity.

  Ah, I didn't explain this. Originally, I planned to implement some
remailer network level commands such as "add/change my stats in your
list of remailers", "put a link to this virtual user in your networking
map", "change my public key", etc. To do this, I assumed that
only *trusted* remailers would be added to your remailer network list so 
that only trusted entities could do network level commands (by signing
them) and only trusted remailers could introduce other remailers to the
network. Now I think I'll require the operator to do this stuff manually
so if you change the parameters of your remailer, you have to manually
notify others on the network and they have to update the configuration
files manually.

  Encrypting messages between remailers is useful because you want
to make sure there is no correlation between incoming requests and
outgoing ciphertexts. You not only want to encrypt them, you want to
alter the sizes of them. I didn't think it was wise to pad a
1,000 byte message out to a 100,000 byte message if both were in the
"mix" Instead, I opted to "packetize" the messages and quantize the
packet lengths to an operator configurable length. Each packet is
encrypted separately and I'm investigating the feasibility of
sending them through separate chains. The problem is, all the pieces
must end up at some remailer where they are reassembled. This
situation would be alleviated if there was a standardized remailer
client operating on the receiving/user side. Even cooler, a 
telescript/postscript like language for splicing and dicing incoming
mail streams. Sort of a PGP/Mail scripting language that can't do any damage
executing scripts embedded in incoming mail.

>>p.p.s. e-mail commands are of the same form as the extropian's mailing
>>list, backwards compatibility with the cypherpunks pasting token is not
>>supported. Why? All headers in the message are ignored (and in socket-mode,
>>there is no header anyway) and the prefered mode of operation is to encrypt 
>>the body and the commands so no outside eyes can see the remail request
>>destination nor the message subject.

>This was one reason I suggested supporting both old-style CP and the
>extropians-style syntax ("::Anon-To").  As Ray suggests, in some cases we
>might not have message headers in the RFC822 sense.  I think it is simpler
>to think about a message which has remailer commands at the top.

   It was an easier implementation issue for me to just handle
commands in the body vs. header and body. Putting commands in
unencrypted headers seems to be a bad idea (especially if you are
giving the remailer an explicit chain. You want to defeat traffic
analysis, not help it) 

>> Socket mode provides a more secure form of operation by bypassing the
>>standard sendmail delivery mechanism allowing a message to be
>>piped directly to the remailer. In addition, the socket mode remailer
>>functions as an information server allowing clients to request
>>a publically networked list of public keys and up-to-date list of
>>\rem servers. The port number can be anything but I'm suggesting we all 
>>agree to use port 2258.

>The number of sites which allow users to run socket servers is far smaller
>than the number which allow mail filters, so not many people will be able
>to use this feature.  OTOH the mail-only sites are generally of low security
>and an owned-and-operated system should be able to use this feature.  So it
>is definately a plus for those who can use it.

   This works already. The remailer is written such that it doesn't
care whether the data is coming from a sendmail STDIN stream, or a
socket. All it does is redirect the socket to STDIN once the
"DATA" command is given. Then, the same routine which processes the
mail side of the server works on the socket data.

   The socket-mode is pretty much a 'free' feature (didn't take
any special logic in the command processor). The software
can run without it, but it works better for internet users.

>Ray had mentioned above that these user handles can also map to encrypted
>remailer strings.  This way users don't have to trust any one remailer op-
>erator to keep their identity secret.  This need for trust is one reason
>I am not enthusiastic about user#remailer1#remailer2#remailer3 as an
>address, although it is admirably concise and easy to use.  The problem is

  Karl Barrus suggested that I use the usenet style FIFO format as in,
remailer1#remailer2#remailer3#user (like foo!bar!user) I'm not sure
which is more intuitive, but I would like some feedback on this.
I agree that one must trust a remailer operator, but I think there's
already too much trust in the single non-networked remailer currently used.
(operator logging easily catches any anonymity)

>that it exposes the path to the first remailer in the chain.  I really feel
>that paths must use nested encryption to be of much value.  Similarly, the
>darkmodem#*#*#deepanon requires the user to really trust the first remailer
>in the chain.  Perhaps it deserves such trust, but I feel that a system which
>does not require such trust would be superior.  (Again, Ray's proposal is
>broad enough that it will allow non-trust modes of operation, as I understand
>it; my main concern is that these other options are so easy that they will
>tempt people to be lazy and slip into modes where they are vulnerable to
>unscrupulous remailer operators.)

  I agree completely. This is always the danger which is why I think
remailers should have ratings, flags, and comments in the list of
remailers, and that remailer operators should only include those
that they trust. I also feel that virtual addresses should always be
many levels deep. (user -> foo#remailer1 -> bar#remailer2 -> 
baz#remailer3 which is an encrypted Eric Hughes style cypherpunk
remailer block.  The only problem is that since Eric's software isn't
part of the notification net, the software has no idea whether the
remailer is up and running or not)

  Some security through obscurity will be needed.

>I am really looking forward to seeing Ray's software.  It sounds like a
>good package of functions.

  Thanks. I still have a lot of work to do on it. I got side tracked
for the last two weeks and my undertaking was a little too ambituous.
When I announced it, most of the library I/O functions were done, but
the major network logic still needs to be written. It should be beta testing
in the next few weeks. Make any requests/suggestions now. ;-)

  Thanks for the comments,

-Ray



-- Ray Cromwell        |    Engineering is the implementation of science;   --
-- rjc@gnu.ai.mit.edu  |       politics is the implementation of faith.     --