Amit,
On 11/24/20 11:21, Amit Pande wrote:
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.
Note that BC is pure-Java, so you should pretty much expect "tremendous
slowness". The reason that the Sun JCE/JSSE provider is (or can be) very
fast is because it's using both native code (which is only marginally
faster than well-JIT'ed Java bytecode, if at all) and also hardware
support when it's available. There is no way that I know of for BC's
pure-Java crypto implementations to use hardware acceleration. AES on
silicon is *much* faster than AES in software.
e.g. below key tool command taking several minutes to finish.
Uhh... that's not software versus hardware. You might expect an order of
magnitude difference between BC and hardware-accelerated SunJCE. But
minutes to generate a 2048-bit RSA key? Something is wrong.
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.
Classic entropy problem.
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.
Correct. FIPS assumes that 100% of your cryptographic operations are of
the *utmost highly-classified state-secret-style nuclear-launch-code
flashing-purple* security level.
Sometimes you just don't need to have perfect entropy.
For long-lived keys, really good entropy is a Good Thing. So to generate
your RSA keys, I'd say go ahead and use the "high quality entropy
source". But for randomness for session id generation, and for
temporary, bulk encryption TLS session keys, /dev/urandom is perfectly fine.
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).
You might be able to justify using /dev/urandom (which must be spelled
/dev/./urandom to force Java to actually use it) in your web
application, but I would go ahead and let keytool take as long as it needs.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
