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

[Jaime H. <hab...@gm...>]

I filled a couple of bug reports to Oracle for fixing and improving the
current documentation:

- https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8220730
- https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8220732


On Thu, Mar 14, 2019 at 9:12 AM Martijn Brinkers <mar...@gm...>
wrote:

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


-- 
Jaime Hablutzel -  RPC 994690880