JDK-6614946 : error in jre/lib/security/java.security configuration file
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2007-10-10
  • Updated: 2023-11-29
  • Resolved: 2013-01-14
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Client VM (build 1.6.0_03-b05, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Linux xxx 2.6.18-4-686 #1 SMP Wed Apr 18 09:55:10 UTC 2007 i686 GNU/Linux

probably applies to all unix platforms

A DESCRIPTION OF THE PROBLEM :
SecureRandom (Brad Notes:  SHA1PRNG) always uses "/dev/random" for seed initialization
even if we specify to use "/dev/urandom" (either by the default configuration
file "jre/lib/security/java.security" or by a "-Djava.security.egd=file:/dev/urandom"
option.

[Brad Notes:  Please see 4705093 for more details about this issue as to what is read and when.]

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Compile the java program given below

2) Run repeatedly the command "time java Foo".

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Normally all the runs should take the same (rather small) amount of  time
ACTUAL -
The first runs run very fast (as expected) because /dev/random "contains"
some already calculated random bytes.
However subsequent runs will run slower and slower, as the first
bytes of /dev/random are consumed and new ones are generated rather slow.

NOTE #1: Avoid using the keyboard or moving the mouse too much
(otherwise kernel makes random bytes available to /dev/random much
faster). Actually it is rather funny, speeding up the program by just typing
frantically on the keyboard :-)

NOTE #2: To make the program run even slower, in a separate window run
the command "od -b /dev/random" and let it run continuously (this
"consumes" the bytes from /dev/random so there are even less available
for our poor java program)

NOTE #3: You can also run
        strace -f -tt java Foo.java
and you will notice that /dev/random is opened twice. The first time it is
not read. However after it is opened for the second time, the read that
follows hangs for a long period of time.




REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.security.*;
    public class Foo {
        public static void main(String[] args) throws Exception {
            SecureRandom x = SecureRandom.getInstance("SHA1PRNG");
            byte[] b = new byte[10];
            x.nextBytes(b);
        }
    }

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
line 69 in jre/lib/security/java.security" is:
    securerandom.source=file:/dev/urandom
and should be changed to:
    securerandom.source=file:///dev/urandom
(i.e. it should be a proper URL)
Similarly if you use the "-Djava.security.egd=file:/dev/urandom" option
you should change it to "-Djava.security.egd=file:///dev/urandom"

Comments
This is being fixed as part of 6425477 in JDK 8.
14-01-2013

EVALUATION Should update the java.security file, and/or the Sun Provider doc.
13-07-2010

SUGGESTED FIX [Brad notes: This comment is not quite correct. Only if the string is "file:/dev/urandom" will the NativePRNG be added *BEFORE* SHA1PRNG, otherwise it will be added *AFTER* SHA1PRNG. Again, please see 4705093 for more details about this issue as to what is read and when.] I believe the java.security file needs updating as well. # On Solaris and Linux systems, if file:/dev/urandom is specified and it # exists, a special SecureRandom implementation is activated by default. # This "NativePRNG" reads random bytes directly from /dev/urandom. It should say something like: # On Solaris and Linux systems, if "file:/dev/random" or "file:/dev/urandom" is # specified, a special SecureRandom implementation is activated by default. This # "NativePRNG" reads random bytes directly from the system default random number # generator (i.e. /dev/random).
30-05-2008

SUGGESTED FIX Read CCC
11-10-2007