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

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

On Wed, Mar 13, 2019 at 5:02 PM Martijn Brinkers <mar...@gm...>
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.
>

If you read carefully, it says that it will supplement the "existing" seed,
but in a fresh SecureRandom, there isn't an existing seed as you can
confirm from
https://docs.oracle.com/javase/7/docs/api/java/security/SecureRandom.html#getInstance(java.lang.String)
:

The returned SecureRandom object has not been seeded. To seed the returned
> object, call the setSeed method. If setSeed is not called, the first call
> to nextBytes will force the SecureRandom object to seed itself. This
> self-seeding will not occur if setSeed was previously called.


Where the key is the last phrase documented: "... self-seeding will not
occur if setSeed was previously called."

But that isn't easy to spot at first sight. Anyway, recent JDK versions are
improving their documentation by including this warning at the level of one
of the setSeed method overloads. Quoting from
https://docs.oracle.com/javase/10/docs/api/java/security/SecureRandom.html#setSeed(byte%5B%5D)
:

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.



>
> Kind regards,
>
> Martijn Brinkers
>
>
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>


-- 
Jaime Hablutzel -  RPC 994690880