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

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

Great bug reports imho.


On 2019-03-15 19:45, Jaime Hablutzel wrote:
> 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...
> <mailto: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...
>     <mailto:Ejb...@li...>
>     https://lists.sourceforge.net/lists/listinfo/ejbca-develop
> 
> 
> 
> -- 
> Jaime Hablutzel -  RPC 994690880
> 
> 
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>