mjr@TIS.COM writes:
One possibility is to treat part of the random seed as if it was your secret RSA key. Systems like PEM store the RSA key encrypted on disk someplace - you could also store an encrypted random seed which you decrypt when you retrieve the secret key, use to bootstrap your PRNG, and then replace with some output from the PRNG when you're done. That way, the seed is (by definition) hidden, and an attacker is going to have much more trouble attacking your PRNG by searching your random seed space.
You don't want to do that... that would amount to using one seed [...]
I was under the impression that mjr's suggestion was to use the randseed the same way it's being used now, only to store it encrypted instead of clear. This has some advantages - stealing it is now much less useful. On the other hand, it means you need to use your secret key when encrypting files, as well as when decrypting or signing them, which increases the exposure of your secret key as well as being annoying.
Since the relationship between a random seed and the IDEA key is known, one can be reproduced from the other.
If the IDEA key is generated by a one-way function such as MD5, it's ostensibly 2**128 work to duplicate an MD-5 hash, and potentially 2**400-2**500 work to generate the input to the hash (which is essentially impossible, since the input:hash is N:1, not 1:1.) Of course, it's still easy to implement wrong, leading to lossage :-) But even something as simple-minded as sessionkey = MD5(randseed+constant) newrandseed = MD5(randseed+differentconstant) would be pretty secure (and the real thing also includes timestamp and MD5 of the message, further randomizing it; haven't looked at the randseed code.) # Bill Stewart wcs@anchor.ho.att.com +1-908-949-0705 Fax-4876 # AT&T Bell Labs, Room 4M-312, Crawfords Corner Rd, Holmdel, NJ 07733-3030