Performance of SP800SecureRandom reseed #2255
Description
We used SP800SecureRandom in our application with "security strength" 256 (=default) , a personalization string of 32 bytes (=256 bits) and SHA256Digest, nonce null, predictionResistant=true for build hash.
Our application used this secure random to generate 12 random bytes for every request received. We observed that from that point on, our CPU workload was completely dominated by SP800SecureRandom.nextBytes():
This doesn't change (significantly) when setting security strength to 128.
For a comparison, here a similar application situation using JDK's built-in SecureRandom.getInstance("DRBG", "SUN"):
(all tests performed on Windows, JDK 25, BC 1.83, modern Meteor Lake laptop)
When using SP800SecureRandom again, but setting predictionResistant=false, the hotspot also reduces to 0%!
Is the reseeding really supposed to be soooo slow? If so, it may possibly be worth a warning in the JavaDoc...