From: nobody@neva.org (Neva Remailer)
Date: Fri, 7 Nov 1997 21:14:27 +0800
To: cypherpunks@cyberpass.net
Subject: Re: Privacy Software
Message-ID: <199711071306.HAA06073@multi26.netcomi.com>
MIME-Version: 1.0
Content-Type: text/plain




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

Adam Back wrote:
>Java isn't so bad.  Just in time compilers are being shipped with
>some browsers (netscape on some platforms).  Sun now has native
>bigint library (good for you know what, and exportable because they
>haven't included the few lines required to implement public key
>encryption with it).

Okay, Java sounds pretty good.  The native bigint library clinches it!

>> While it may seem crazy to toss compatibility, it has some
>> advantages.  For instance, the only people who will use it are the
>> hardcore types.  I like the idea of an exclusive crypto system that
>> only cool people who are fairly with it use.
>
>I think there would be advantages to always tunneling the encrypted
>messages inside PGP, that way no snoops know you're using it, until
>it's too late.

Aside from political correctness issues, why not?  It would also be
nice to have an encrypted SMTP channel which happens to be riding on
IPSEC.

>> If the protocol doesn't accept multiple keys for a message it is
>> slightly CAK/GAK resistent.  And, it's a nice statement of intent.
>> It's also nice to have tools which help you to behave securely
>> without carefully thinking about it when you are using them.
>
>Forward secrecy is what you want for GAK resistance -- can't get much
>more GAK hostile than burning your keys seconds after message
>receipt.

The more I think about the more the separation of authentication keys
from communication keys seems like the way to go.  If both parties can
connect to each other's machines in real time, then a negotiated key
which is discarded is great.  More often everybody's offline, but that
just means you have to publish many different communications keys,
perhaps sorted by hours.  (Given remailer lag you might have to keep
communications keys around for a day or two after expiration, but
that's not too bad.)

>> The randseed.bin file has always bothered me.  What we really want
>> is some good sources of entropy in which we have tremendous
>> confidence.
>
>What's wrong with the randseed.bin and the public and private key
>rings is that they should all be encrypted with a key derived from
>your passphrase.

It's also complicated and hard to understand.  The Right Thing (TM) is
to simply solve the entropy problem correctly.

>> >I wonder how good linux's /dev/urandom would be if MD5 becomes even
>> >more suspect.
>> 
>> Well, neither of these would be good for a one time pad, of course.
>
>Linux's /dev/random might not be bad.  There is some real entropy in
>key strokes and mouse movements, and they are quite conservative
>about entropy estimation.  You can easily make it more conservative
>-- XOR together a load of it to derive a smaller key.

The problem with computers generating entropy is that they are
complicated machines which are designed to be deterministic.  While it
seems reasonable that keystrokes and mouse movements have some
entropy, its hard to really convince yourself that there couldn't be
patterns arising from the OS somehow.  For example, maybe the sample
times form weird patterns which are related to the scheduler.

By all means this can be XORed in, but it seems dangerous to rely upon
it if you are trying to be hardcore and use one time pads.

>> It would be neat to have, say, three sources of hardware randomness
>> and then XOR the result with the above pseudo random output.
>
>That'd be fine.  Personally not being a hardware type, I am
>suspicious of hardware RNGs.. I can't tell when they are going
>wrong.. failure modes can be dangerous (whoops lead fell of geiger
>tube), etc.

Most plausible failure modes in hardware should be detectable with the
usual tests for "randomness".

>Software and computers are easier to understand.  Provided you XOR
>the lot together you should be fine though.

Software and computers are highly complex devices and we don't truly
understand every aspect of their operation.  We can say it's unlikely
that there are patterns in the bits they generate, but if we resorting
to one time pads, it seems to me that the entropy question has to be
nailed down completely.  (Not that I have a good solution, yet.  As
you pointed out, one time pads consume a lot of entropy.  It takes a
long time to flip a coin 1.5 MB * 1024 bytes/MB * 8 bits/byte times!)

Monty Cantsin
Editor in Chief
Smile Magazine
http://www.neoism.org/squares/smile_index.html
http://www.neoism.org/squares/cantsin_10.htm

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBNGK7tpaWtjSmRH/5AQH1Rgf7BWVm8IsauXUry7vzL1Wiw/jlISKXO+q2
SWXOW0ce2jH1wKH+X3FbiONLYihzhp8UIvyn6FO7rVXHMdXoDXFVhrpyhbphcejM
hokty69o1hQqLU9aX6z7OAA7Vjj2zKZXWc7U596UGkc0+G64qpJfh7kZoHY+Q332
uWMhEHu0AOnv9wGK9Fip4J4n/4jh/ob00VXXeTGG9peJ/AZBqtJMHV9tLW8Xu2EA
Yc+zdUmk2jjSHvi2a/9u8NTsJapUVFiEaZ8+iQCZYeP8SG6oAsMmMb0rrCj1y+DK
EtMt0rtC6jHGl8dag7zfZLpiIrl6mObMexbh5gAJ40Fb6Ei0HLbZ0g==
=4BA0
-----END PGP SIGNATURE-----