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.
[...]

Reply via email to