Hi Amit, Consider changing "securerandom.strongAlgorithms" to "NativePRNGNonBlocking:SUN" in your Java's "lib\security\java.security". The default is "NativePRNGBlocking:SUN" and is really enthropy thirsty on startup as it runs it's self tests and seeds its PRNG
George -----Original Message----- From: Amit Pande <amit.pa...@veritas.com> Sent: Tuesday, November 24, 2020 9:22 AM To: Tomcat Users List <users@tomcat.apache.org> Subject: Bouncy Castle FIPS on RHEL 7.3 Probably not directly related to Tomcat but still sharing. Advanced apologies for that. I am using bouncy castle FIPS library and observed that specifically on RHEL 7.3, the library usage is causing tremendous slowness. e.g. below key tool command taking several minutes to finish. keytool -providerpath /root/Downloads/bc-fips-1.0.2.jar -providerclass org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider -genkeypair -keyalg RSA -keypass "Test123" -validity 3650 -dname "CN=Test_HostName, ou=My Org Unit, o=My Org" -storepass "Test123" -keystore "/tmp/test_bc.bcfks" -storetype BCFKS -v -alias test_entry However, when I add the JVM option -J-Djava.security.egd=file:/dev/./urandom instead of the default /dev/random, all problems go away. It's rather strange that multiple 7.3 RHEL systems are showing this behavior very consistently. RHEL 7.2, 8.0 seem just fine in my testing. No issues when using /dev/random along with JKS type key stores (including RHEL 7.3). Even Tomcat is flagging the slowness to generate the secure random numbers. "17-Nov-2020 19:24:59.142 WARNING [Catalina-utility-2] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [68,745] milliseconds." Apparently, according to FIPS experts we should not use /dev/./urandom. So, while I continue to explore further, sharing this in case any one has seen this behavior or be aware of such potential issue as it may tie in to their Tomcat (or web apps to be deployed in Tomcat). Thanks, Amit --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
