Profile Image
neeraj bhatt

Java application is using DRBG in Kubernetes pod instead of NativePRNG

We checked the JFR of our application and it shows threads get blocked for some duration. We expect our application to use NativePRNG to generate SecureRandom UUID but instead it is using DRBG (showing in stacktrace). Any idea why is it not using NativePRNG

 

We use jdk 17

java.vm.version    17.0.9.0.101-zing_23.08.300.0-b2-product-linux-X86_64

docker env CentOS Linux release 7.9.2009 (Core)

uname: Linux 5.15.0-1053-azure #61~20.04.1-Ubuntu SMP
libc: glibc 2.17 NPTL 2.17 

 

Below is the stack trace of the blocked thread.

 

Stack Trace    Count    Percentage
void sun.security.provider.AbstractDrbg.instantiateIfNecessary(byte[])    1    100 %
void sun.security.provider.AbstractDrbg.engineNextBytes(byte[], SecureRandomParameters)    1    100 %
void sun.security.provider.AbstractDrbg.engineNextBytes(byte[])    1    100 %
void sun.security.provider.DRBG.engineNextBytes(byte[])    1    100 %
void java.security.SecureRandom.nextBytes(byte[])    1    100 %
UUID java.util.UUID.randomUUID()    1    100 %

  • securerandom

  • blocking

  • drbg

  • drbgprovider

Please Sign In or to post your comment or answer

Profile Image

Ram Lakshmanan

Hello Neeraj!

 

 Greetings. Your application using DRBG instead of NativePRNG is most likely related to configuration settings and the security provider preferences of your Java environment. What Java version and K8 version you are using?
 
 Below are few steps to diagnose this problem:

 

1. Check Java Security Configuration:

 

The Java security properties file (java.security) controls the default SecureRandom implementation. Ensure this file is configured correctly. 

 

You can find the java.security file in your JDK's lib/security directory.

 

Look for the property securerandom.strongAlgorithms. It should list NativePRNG as one of the algorithms. If DRBG is listed first, that might be why it's being used.

 

securerandom.strongAlgorithms=NativePRNG,DRBG,....

 

2. Specify to Use NativePRNG:

 

Explicitly specify the algorithm when creating instances of SecureRandom.

 

SecureRandom secureRandom = SecureRandom.getInstance("NativePRNG");

 

If your UUID generation code does not allow for specifying the SecureRandom instance, consider setting the java.security.egd system property to point to a source that uses NativePRNG.

 

-Djava.security.egd=file:/dev/urandom

 

3. Check Docker and OS configuration:

 

Ensure that /dev/urandom or /dev/random is available and accessible within your Docker container.

 

Sometimes, containers might have restricted or different configurations for entropy sources.

 

4. Security Provider Logging:

 

Enable debugging for security providers to see detailed logs which might help in understanding why NativePRNG is not being used.

 

-Djava.security.debug=sun.security.provider.SecureRandom


By following these steps, you might be able to diagnose why NativePRNG is not being used.

Got something else on mind? Post Your Question

Not the answer you're looking for? Browse other questions tagged
  • securerandom

  • blocking

  • drbg

  • drbgprovider