From: Jim choate <ravage@bga.com> Date: Fri, 10 Jun 1994 14:07:49 -0500 (CDT)

From: Jim choate <ravage@bga.com> Date: Fri, 10 Jun 1994 15:33:44 -0500 (CDT)

[Sez Weaver:]

...

How about the sender encrypting with the REMAILER'S public key, and the remailer sending out encrypted with its own private key? That way no registry is necessary. If a sender doesn't trust the remailer, let the sender sub-encrypt the message inside the remail headers.

I am not worried about their trusting me, I *don't* trust them...

If the sender wants to encrypt that is fine. I will encrypt ALL outgoing with the recievers public key. Assuming the original reciever wants to reply the original sender will need a key in order for me to encrypt to them.

Please excuse my density, but against what are you defending by this measure? What don't you trust them about?

Why should I trust them at all? Why should I willingy become an occomplice in any of their activities? I don't anyone, including me, being able to figure out what is going on. But more importantly you seem to assume that these pair of communicators are not trying to determine something about me with their traffice. By encrypting the outgoing the reciever is shure that it came from my re-mailer and not somebody else. If the sender wants to be shure the reciever can verify it is from them they can use their own set of keys to pass the encrypted traffic. With this technique they can be shure that the remailer they intended to handle it did so correctly as well as the original source.

...

I hope some header field can be defined to specify a maximum delay, and perhaps use the random number as a proportion of that maximum.

All messages will recieve a time stamp for transmission that will be no more than 24hrs away. The time stamp will be random. Until the clock matches the stamp it sits encrypted w/ the recipients keys in a cache. Submitters will have no say in how long the message waits. If you want encryption and security you have to give something up. Besides if a user don't like the way I run it they don't have to use it.

True. Then again, if it's your goal to provide something useful that'll be used, well, a fixed 12-hour-average delay places a pretty tight upper bound on usefulness.

Really? Exactly what are you sending that 24 hrs makes a damn as far as the reciever getting it? If it is that time critical you aren't going to use a public re-mailer anyway, too unreliable. With a public re-mailer there is no guarantee that I don't keep a image of the original and go ahead and pass along a image. I think usefulness is something we each have to decide on. If it works for me and not for you that means absolutely nothing. If others won't use it, fine by me. I run my system for me and a close group of associates, if other callers (it is open to the public) find it inconvenient or strange, too bad. Let them spend their own money and time and build something exactly like they want.

...

3. We intend to support anonymous as well as explicit addressing.

Could you amplify on this?

Yes, a sender will be able to designate whether they wish their return accdress to be hidden behind an anon system or else we leave it on there relying on the encryption for security.

Cool. Will it employ "anon handles" like some of the personals remailers use?

Well I intend for it to use pseudonyms (ie ravage) for this sort of stuff. I will create a libary of rules (probably in REXX) that will generate a list of names on demand. I really don't find 'anonxxxxx' that interesting. The users will be able to either select their 'nym or else can generate it for them.

On the issue of traffic analysis:

It occurs to me that simply monitoring a remailers feeds and their traffic analysis will provide enough information to determine the difference between bogus (ie random generated) and real traffic. While it may be possible for a sysadmin to make their systems traffic appear confusing *if* they don't factor in their feeds traffic when a spook looks at not only the target system but the feed systems and the traffic analysis on them you could determine to some degree of precision the amount and possible the actual bogus packets v the real traffic. Just a thought...

If I understood this properly, maybe you could scale back the "Potemkin" traffic to level out the load.

Unfortunately I don't have control over the traffic on these other systems, and I suspect most other sysadmins don't either. The bottem line is that if all a spook looks at is my system I can hide the traffic. If they include in their analysis the 'surrounding' systems then I am out of luch unless they also take active measures to hide their traffic patterns. The problem I see with this is who pays for it? I spend a couple hundred a month on my systems feeds and such, this is a tidy chunk of change out of my pocket (I work at a community college) and I suspect few people will find such expenses worth the effort. Also since my feed is a SLIP bandwidth is at a premium, bogus packets are not something I will spend a lot of time generating. In a network of mailers like I envision the layers of encryption is what provides the protection along w/ the 'nyms.

From: Jim choate <ravage@bga.com> Date: Fri, 10 Jun 1994 16:34:05 -0500 (CDT)

Why should I trust them at all? Why should I willingy become an occomplice in any of their activities? I don't [want?] anyone, including me, being able to figure out what is going on. But more importantly you seem to assume that these pair of communicators are not trying to determine something about me with their traffice.

So you're trying to prevent the users from finding something out about you? What, exactly? Trying to understand the issue here.

There is no issue. I simply do not choose to trust those who use my system. Seems prudent to me. If you would like to trust total strangers that is your perogative.

By encrypting the outgoing the reciever is shure that it came from my re-mailer and not somebody else.

If you encrypt it with the remailer's private key, yeah. I thought you were saying earlier that you'd encrypt the outgoing messages with the recipient's public key. Did I misunderstand?

I have to encrypt w/ my private key and their public key. All they have access to is my public key. The point is to verify where the packet came from, not what is in it.

On a related note, should encrypting remailers have the keys changed regularly? The RSA-IDEA combination isn't very suspectible to known plaintext attacks, right?

Zeke

Personaly I think that is up to the individuals who are transmitting the messages. If they for some reason feel it is prudent then do it. Otherwise there are probably other more interesting things to work on.