SHA256( from RSA Key Helper) hangs under BouncyCastle FIPS library

Question

We moved to BC FIPS version 1.0.1 and since then RSA Key Helper hangs for extended periods of time (stack below).

We had a similar issue in Linux that was solved by increasing entropy (urandom/haveged/etc.)

Is there a similar workaround that can be employed for the Windows environment? Our previous BouncyCastle implementation worked fine.

Daemon Thread [http-bio-18080-exec-10] (Suspended)  
                    owns: Object  (id=2939) 
                    owns: Boolean  (id=2940)             
                    owns: SocketWrapper<E>  (id=117)          
                    SHA2$SHA256(SHA2).implDigest(byte[], int) line: 98         
                    SHA2$SHA256(DigestBase).engineDigest(byte[], int, int) line: 181               
                    SHA2$SHA256(DigestBase).engineDigest() line: 160          
                    MessageDigest$Delegate.engineDigest() line: 592              
                    MessageDigest$Delegate(MessageDigest).digest() line: 365          
                    ManifestEntryVerifier.verify(Hashtable<String,CodeSigner[]>, Hashtable<String,CodeSigner[]>) line: 207  
                    JarVerifier.processEntry(ManifestEntryVerifier) line: 241 
                    JarVerifier.update(int, byte[], int, int, ManifestEntryVerifier) line: 228       
                    JarVerifier$VerifierStream.read(byte[], int, int) line: 482  
                    URLClassPath$JarLoader$2(Resource).getBytes() line: 124             
                    Launcher$ExtClassLoader(URLClassLoader).defineClass(String, Resource) line: 462              
                    URLClassLoader.access$100(URLClassLoader, String, Resource) line: 73    
                    URLClassLoader$1.run() line: 368               
                    URLClassLoader$1.run() line: 362               
                    AccessController.doPrivileged(PrivilegedExceptionAction<T>, AccessControlContext) line: not available [native method]              
                    Launcher$ExtClassLoader(URLClassLoader).findClass(String) line: 361       
                    Launcher$ExtClassLoader(ClassLoader).loadClass(String, boolean) line: 424            
                    Launcher$ExtClassLoader(ClassLoader).loadClass(String) line: 357              
                    BouncyCastleFipsProvider.<init>(String, SecureRandom) line: not available            
                    BouncyCastleFipsProvider.<init>(String) line: not available             
                    BouncyCastleFipsProvider.<init>() line: not available        
                    RSAKeyHelper.<init>(String, String) line: 35           

Schistosome

Your stack track doesn't look like something related to entropy. If this stack trace actually represents where your code hangs, it looks like for some reasons your code handgs inside a classloader, particularly inside jar verification process. This sounds quite strange as it should be reasonably fast and determenistic process (here SHA2$SHA256 seems to be actually SHA256 inner class of sun.security.provider.SHA2 from the rt.jar). Are you sure your stack trace is actually where the code hangs? Also, as a wild guess, don't you somehow load some of your jars over a slow network? – Maulmain

That is interesting! This is def one of the hanging places, the other is key generation itself. Since it is a windows vm in a corporate environment, I wonder if somehow the storage where the JRE sits has some wild latency going on, or maybe the AV software is holding the class a bit longer...I will check on Monday! – Schistosome

Could be a circular dependency/circular initialization issue - as in you are loading SHA-X implementation from a JAR signed by the same SHA-X algo. – Eellike

Would a circular dependency unlock after a few minutes though? – Schistosome

Which JVM implementation are you using and which version? – Intravenous

Sun JVM 1.8u112 – Schistosome