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