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

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

Hi Tomas,

See my comments inline

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.

Kind regards,

Martijn Brinkers


> On 2019-03-13 23:01, Martijn Brinkers wrote:
>> On 12-03-19 21:02, Jaime Hablutzel wrote:
>>> I'm looking the following code pattern in several places of the source
>>> code (mostly in tests):
>>>
>>> SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
>>> random.setSeed(new Date().getTime());
>>> random.nextBytes(serno);
>>>
>>> Where the setSeed call just before the call to nextBytes prevents the
>>> SHA1PRNG default implementation from feeding itself from system entropy,
>>> so it relies on the provided timestamp as its only source of entropy,
>>> which looks like a bad idea.
>>
>> According to SecureRandom javadoc, this should not have any implication
>> on the security of the random generator (i.e., the randomness)
>>
>> https://docs.oracle.com/javase/7/docs/api/
>>
>> The given seed supplements, rather than replaces, the existing seed.
>> Thus, repeated calls are guaranteed never to reduce randomness.
>>
>> Kind regards,
>>
>> Martijn Brinkers
>>
>>
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>