[Ejbca-develop] Dangerous pattern of seeding SecureRandom instances

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

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.

Anyway, the only one production code that I see being affected by this is
one overload of the method org.cesecore.util.CertTools#genSelfCertForPurpose,
and even when I can't find any real security impact (after a quick trace of
the usages of this method), wouldn't it be better to remove all the calls
java.security.SecureRandom#setSeed anywhere (even in tests code)  to
prevent any future problem or mistake?.

Regards.

-- 
Jaime Hablutzel -  RPC 994690880