>At 01:50 PM 8/2/99 -0400, Paul Koning wrote:
>>What we need is a minimum of ONE decent quality additional
>>entropy source, one that works for diskless IPSEC boxes.
That's unfortunately outside the scope of IPSec :-)
If you don't have random number hardware,
you can't get hardware random numbers.
That means if you don't have a disk, you need to add something else,
whether it's a sound card or /dev/geiger or whatever.
At 03:35 PM 8/2/99 -0400, John Denker wrote:
>1) Hardware TRNG
>2) Network timing
By the way, you can help network timing if you've got a router
in front of your IPSEC gateway - it won't protect you from
inside observers, but it'll do some randomization that outside
wiretappers can't see. Of course, if you're using a 10ms clock
instead of a 1us or 5ns clock, it's not much use.
>3) Deposits from a "randomness server"
>4) Just rely on PRNG with no reseeding.
.....
>4) I don't think my customers would be very happy with a system that could
>not recover from a transient read-only compromise.
You can at least help the PRNG problem by encrypting the PRNG output
using some secret key and crypto algorithm before using it as a random number
(or encrypting some constant value with the PRNG output as the key.)
This is probably stronger than simply hashing the PRNG output,
because the crypto was designed for different attacks than a hash.
It's not something /dev/urandom can easily incorporate,
because of Stupid Export Law Tricks, but IPSec does encryption anyway
and isn't written in the US. The key doesn't have to be constant;
you could update it from the randomness stream also,
but it may be more resistant to attacks or give you something more
to bootstrap randomness from if your gateway's been compromised.
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
