I wonder if you are confusing the length in bits of a PKC key, e.g. a
prime factor of an RSA public key, with the entropy of that private
key. The prime factor may be 512 bits long, but it usually does not
have anyway near 512 bits of randomness. Usually a secret prime is
generated by adding a 128 or 160-bit random quantity to some
non-secret base and then selecting the next prime number. In such a
scheme a 20 bytes (160 bits) random pool is not unreasonable for
generating one key or a small number of keys.
On general principles I would prefer a larger pool of randomness,
especially if it is available in the operating system, but if the 20
bytes are truly random, I don't think you can call the keytool scheme
insecure.
Arnold Reinhold
At 10:10 PM +0100 4/2/2000, Andrew Cooke wrote:
>Hi,
>
>Can someone please correct the following?
>
>I expect a PRNG with an internal state of n bits to produce output that
>is predictable given n consecutive bits of output. Is that correct? If
>so, then doesn't a PRNG used to generate a key require at least as large
>an internal state as the key length (otherwise, given the first n bits,
>the rest is predictable, reducing teh effective length to n)?
>
>This is the basis of my earlier post questioning the security of Sun's
>keytool. I've included the relevant parts of my post and the reply
>below - I've also checked the FIPS document, which doesn't mention this
>(I cannot find a public copy of the IEEE document).
>
>My apologies if the reasoning above is incorrect - I would really
>appreciate comments on this as it is important that I understand whether
>or not the keytool is useful (and also, given the response, I suspect I
>am labouring under some pretty major misconception about random PRNGs).
>
>Thanks,
>Andrew
>
>
>Gary Ellison wrote:
>> >>>>> " " == Andrew Cooke <[EMAIL PROTECTED]> writes:
>[...]
>> > Most importantly, as far as I can tell, keytool does not generate "fully
>> > random" keys when used "naively".
>[...]
>> The Sun provider for SecureRandom follows the IEEE P1363 standard,
>> Appendix G.7: "Expansion of source bits", and uses SHA1 as the
>> foundation of the PRNG. Additionally, we verify that the Sun
>> SecureRandom provider complies with NIST's FIPS PUB 140-1 section 4.11.
>[...]
>> > - The Java SecureRandom class contains only 20 bytes of random state and
>> > these are initialised by some kind of thread contention process (which
>> > may not generate "really random" values either).
>[...]
>> In 1996 when SecureRandom was implemented 20 bytes of state seemed
>> sufficient for FIPS 140-1 compliance. Perhaps this is no longer a
>> sufficient target (your suggestions are welcome). The Sun provider
>> for SecureRandom mixes in other sources of entropy with the results
>> from the thread contention process. Among other things this includes
>> the current time, the state of the VM's memory usage, system
> > properties, and file system activity.
>[...]
