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

[Tomas G. <to...@pr...>]

Hi Martijn,

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.


Cheers,
Tomas

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
>