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

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

On 2019-03-14 14:51, Martijn Brinkers wrote:
> 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.

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.


> 
> 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
>>
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>