>>>>> " " == Andrew Cooke <[EMAIL PROTECTED]> writes:
Andrew,
Comments interspersed below.
> Hi,
> I asked on this list a while back for info on keytool. I had some
> private replies and have finally come up with an answer - I'm posting
> here to make leave a public record to help others in my position, in
> case anyone knows better and can correct me, and to warn of apparent
> insecurities.
> Most importantly, as far as I can tell, keytool does not generate "fully
> random" keys when used "naively".
> Although keytool appears as a standalone app in the JDK/JRE, it is
> implemented as Java code which can be inspected by getting the full JDK
> source via the Sun/Java Community Download process. Checking this code
> shows that:
> - Unless other crypto/security providers are registered, the source of
> random numbers is the Java SecureRandom class.
All of the security tools are implemented in Java. keytool uses
the default installed provider for SecureRandom. Obviously we need to
better document this fact. To be more specific the Sun providers of
KeyPairGenerator use the default (first installed) SecureRandom provider.
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.
The algorithm can perform poorly in the absence of a JIT and
so we are considering supplying an alternative provider which will
take advantage of platform specific support for an entropy gathering
device such as /dev/random or the Pentium III thermal-noise RNG.
> To use keytool securely, it seems that you must configure Java to use a
> different provider for the SecureRandom class. The procedure for doing
> this is described in the docs that come with the JDK.
> I tried to get info from Sun/Java by emailing various addresses and
> posting a question to the security forum; I did not ask on the
> java-security list as I couldn't register (no response from the LISTSERV
> password register). Although all the above is standard Java info (the
> internal state for SecureRandom is documented in the API docs) it was
> not clear that keytool is implemented in Java and, therefore, uses the
> standard Java security code.
[EMAIL PROTECTED] is a feedback alias to the security team. Messages
to this alias are archived at;
http://archives.java.sun.com/archives/java-security.html
Hope this helps.
> Cheers,
> Andrew
> Andrew Cooke wrote:
>> Does anyone know the size of the internal state for the random number
>> generator in Java's keytool? A pointer to appropriate Java docs would
>> be sufficient.
>>
>> (This seems to be pretty critical info for deciding how reliable the
>> keys are - the default random number generator in Java does not have
>> much state and to get sufficient state by seeding multiple instances
>> using Java's thread race mechanism - even if that is reliable - takes
>> longer in my own Java code than the time keytool takes to generate new
>> keys!)
>>
>> I've looked through all the docs I can find, and also checked this
>> list's archives (I could only search titles (subjects) for keytool, and
>> only did the last 6 months, so if it's under a different title or
>> earlier, could you give me the title and/or date?). I've also posted a
>> question on the Sun Java discussion foums, but had no reply.
--
mailto:[EMAIL PROTECTED] phone:+1 408-517-6979/x66979
"
!" Harpo Marx
