SecureRandom initialization slow on Windows

Question

We have a couple of machines in our lab that expose a 2 minute delay whenever a SSL connection is established first. This looks similar to the slow initialization of SecureRandom in 1.3.x, but we are using 1.4.2_05. Here's a thread dump of the method in which it seems to be stuck most of the time:
"AWT-EventQueue-0" prio=7 tid=0x187103c8 nid=0x580 runnable [1946e000..1946fd88]
at sun.security.provider.NativeSeedGenerator.nativeGenerateSeed(Native Method)
at sun.security.provider.NativeSeedGenerator.<init>(NativeSeedGenerator.java:28)
at sun.security.provider.SeedGenerator.<clinit>(SeedGenerator.java:95)
at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:168)
- locked <0x10183fe8> (a sun.security.provider.SecureRandom)
at java.security.SecureRandom.nextBytes(SecureRandom.java:381)
- locked <0x10183420> (a java.security.SecureRandom)
at java.security.SecureRandom.next(SecureRandom.java:403)
at java.util.Random.nextInt(Random.java:191)
at com.sun.net.ssl.internal.ssl.SSLContextImpl.engineInit(DashoA6275)
at javax.net.ssl.SSLContext.init(DashoA6275)
[rest omitted]
This shows only on some Windows machines, not all. We've particularly noticed it on older (< 1GHz) Pentium III systems. Has anybody ever seen anything like this before?

Answer 1

Reading the source file (available in the SCSL source code), you can see that SecureRandom tries to use the MS CryptoAPI CryptGenRandom, using the default cryptographic provider (usually MS Base Cryptographic Service Provider v1.0. ). If it can't use the MS CryptoAPI it tries to span several threads, does some operations, and measures the time. It could waste a lot of time in thread creation and time measuring.
Check if the machines suffering from slow initialization times have different versions of Internet Explorer or service packs (the MS Base CSP is in the file rsabase.dll and is updated whenever you update Internet Explorer.)