Re: back to programming projects...

[Jim choate <ravage@bga.com>]

> 
>    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.