Re: [Ejbca-develop] Dangerous pattern of seeding SecureRandom instances

[Martijn B. <mar...@gm...>]

>> On 14-03-19 13:18, Tomas Gustavsson wrote:
>>> Yes the javadoc says so, but analysis of the java source code tells me
>>> otherwise. Unless I, and another guy in the Internet, read it
>>> incorrectly, is a subtle interpretation issue of the javadoc in the
>>> actual implementation.
>>> setSeed makes the internal seeding not to run, causing the setSeed to be
>>> the only seeding. But subsequent calls to setSeed will supplement the
>>> first call.
>>>
>>> I made the same interpretation as you from the javadoc, but checking the
>>> implementation changed my mind.
>>
>> It looks like you are right when using SHA1PRNG. It is not the case when
>> you create an instance of the default SecureRandom because that is using
>> the NativePRNG (at least on Linux).
>>
>> The Javadoc is very unclear about this. To me it looks like a bug in the
>> implementation of SHA1PRNG.
>>
>> That said, in my view you should never call SecureRandom#setSeed unless
>> you want to seed it with a more secure random source than what is by
>> default provided.
> 
> In the test code setSeed is probably used just no _not_ make it wait for
> self-seeding, you want tests to run fast.
> Changing it to just Random for tests seems reasonable imho.

Yes using it for testing is reasonable. It might be used for example if
you want a reproducible test case.

I did some additional reading and the Javadoc for Java 9 are more clear
on the seeding subject

"A PRNG SecureRandom will not seed itself automatically if setSeed is
called before any nextBytes or reseed calls. The caller should make sure
that the seed argument contains enough entropy for the security of this
SecureRandom."

https://docs.oracle.com/javase/9/docs/api/java/security/SecureRandom.html

They now also mention that SecureRandom is thread safe. In previous
Javadocs they did not mention anything about thread safety and you
therefore had to assume that SecureRandom was not thread safe (at least
in my view :)

Kind regards,

Martijn Brinkers