back to programming projects...

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?

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

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

   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.

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

   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?

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

-----BEGIN PGP SIGNED MESSAGE-----

    From: Jim choate <ravage@bga.com>
    Subject: Re: back to programming projects...
    Date: Fri, 10 Jun 1994 16:34:05 -0500 (CDT)
    
    Why should I trust them at all?

I think that this is a very reasonable question.  Clearly, you
shouldn't.  If you let just anyone use it, your trust level is zilcho.

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

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLfkHBRVg/9j67wWxAQEDEQQAsPWAPfzlDTwuARm6cJMAtp056KhP135X
RE4BVW3xAsuS3oXsWYuMWOortRJcdE0XdJCqAYFS+ULu842Cj6s/P+dKS/vmMptH
mrky+KPvWEKCnV0aD5L5nlj1KaiFJCn7ZtXZi5Zxn3+JpNxIIW2oASaHL9hk7Xnd
sqiHNzWgjw4=
=TMio
-----END PGP SIGNATURE-----

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

-----BEGIN PGP SIGNED MESSAGE-----

    From: Jim choate <ravage@bga.com>
    Subject: Re: back to programming projects...
    Date: Sat, 11 Jun 1994 17:39:05 -0500 (CDT)
    
    > 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.

I wasn't asking about anything to do with what projects were interesting to
anyone in particular.  If I want to know what you're interested in working
on, I'll ask directly.  I was asking about something that might be equally
interesting to users and maintainers.

Is the RSA-IDEA combination known to be suspectible to any known/chosen
plaintext attacks?  Has anybody published a known/chosen plaintext attack
that works against what PGP does better than a brute force attack?

If a known/chosen plaintext attack works against PGP, then a PGP remailer's
keys aren't as secure as other keys cuz an attacker can encrypt arbitrary
text with them.  If nobody's figured out a known/chosen plaintext attack,
then remailer's keys are as good as anybody else's.

Zeke

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLftKjhVg/9j67wWxAQHiSwP/dop6udnScpvG6BfAG4Btn3ggGVxZ8DGO
kJNEOpNYEEbhjqDjsnPq9ApXqcWaOIF+L6yO2nxleEwHQ8g9uE/YCSPzubr1WP6C
priCJGeCB/vgjcMQul6/k13T97vHF3UkPlcVPwt0hqP/DV158wwnZMfwIOcMS3r5
5RyRWOCKxck=
=LEN+
-----END PGP SIGNATURE-----