-
Type:
Bug
-
Status: Open
-
Priority:
P4
-
Resolution: Unresolved
-
Affects Version/s: 12, 13
-
Fix Version/s: tbd
-
Component/s: security-libs
-
Subcomponent:
A DESCRIPTION OF THE PROBLEM :
java.security.SecureRandom#setSeed(byte[]) javadoc says:
> ...
> A PRNG {@code SecureRandom} will not seed itself automatically if
> {@code setSeed} is called before any {@code nextBytes} or {@code reseed}
> calls. The caller should make sure that the {@code seed} argument
> contains enough entropy for the security of this {@code SecureRandom}.
And given that this applies to java.security.SecureRandom#setSeed(long) as well, it should be indicated in its own javadoc or at least a "@see" tag should be added to #setSeed(long) as shown:
/**
* ...
* @see #setSeed(byte[])
* @see #getSeed
*/
Failing to do so leaves to much room for unaware users to seed the SecureRandom in the following tempting but insecure way:
SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
random.setSeed(new Date().getTime());
random.nextBytes(serno);
java.security.SecureRandom#setSeed(byte[]) javadoc says:
> ...
> A PRNG {@code SecureRandom} will not seed itself automatically if
> {@code setSeed} is called before any {@code nextBytes} or {@code reseed}
> calls. The caller should make sure that the {@code seed} argument
> contains enough entropy for the security of this {@code SecureRandom}.
And given that this applies to java.security.SecureRandom#setSeed(long) as well, it should be indicated in its own javadoc or at least a "@see" tag should be added to #setSeed(long) as shown:
/**
* ...
* @see #setSeed(byte[])
* @see #getSeed
*/
Failing to do so leaves to much room for unaware users to seed the SecureRandom in the following tempting but insecure way:
SecureRandom random = SecureRandom.getInstance("SHA1PRNG");
random.setSeed(new Date().getTime());
random.nextBytes(serno);