Posted by Synopsys Editorial Team on January 6, 2014
During a recent application assessment at Synopsys, a question came up regarding whether calls to SecureRandom can ever block. This led me to look into several SecureRandom implementations (four in Oracle JRE, and six in IBM JRE) in more detail, and I discovered some interesting facts. There seem to be at least three security issues related to SecureRandom. Let’s take a look at each one below.
All SecureRandom implementations attempt to seed themselves if you don’t explicitly supply a seed. However, if you attempt to seed the following implementations before obtaining any output from the SecureRandom implementation, you will bypass the internal seeding mechanism of the SecureRandom implementation:
That is, one of the four SecureRandom implementations in the Oracle JRE and five of the six SecureRandom implementations in the IBM JRE behave this way. This may be desirable in some situations; for example, if you need to generate the same outputs multiple times, you can seed your SecureRandom implementation with the same seed each time. However, when unpredictability is required, bypassing the internal seeding mechanism of the PRNG is not a good idea.
Some SecureRandom implementations in the Oracle JRE for *nix use /dev/random to get entropy at certain times. Since /dev/random can block if sufficient entropy is not available, your code will stop executing if you call certain SecureRandom methods at times when /dev/random does not have sufficient entropy available. The following SecureRandom implementations have this potential problem:
This problem can occur in the following instances:
Note that we did not discuss the deprecated getSeed() method, which behaves differently than generateSeed(). Since it’s deprecated, we will not discuss it further.
Some SecureRandom implementations seed themselves using entropy obtained from the underlying operating system. In some cases, these can be configured to gather entropy in other ways. Other SecureRandom implementations attempt to generate entropy without relying on the underlying operating system. The following implementations generate entropy without relying on the underlying operating system:
Generally, relying on the operating system to generate entropy is better because the operating system has access to more sources of unpredictable data.
There are many more interesting details about several of the implementations above. I’ll write about the particular implementations in the upcoming weeks and will provide a lot more detail.
See other posts on SecureRandom
Get the latest Software Integrity news, thought leadership, and more.