[9] RFR: 8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations

Wang Weijun weijun.wang at oracle.com
Tue May 10 07:43:52 UTC 2016


For all:

- If you can remember the old "securerandom.drbg.config" value to reset it in a finally clause, there is no need to othervm.

- All DRBG mechanism names contain "_DRBG", therefore I'd rather change NON_DRBG.contains(mech) to !mech.contains("_DRBG"). The same technique can be applied everywhere. In fact, you can also add "DRBG" as a test algorithm, i.e. using the default "securerandom.drbg.config". If so, you have to reset the value after every call.

GetAlgorithm.java:

- You can but check on line 60 into lines 51 and 54, something like check(name, SecureRandom.getInstance(...))

ApiTest.java:

- Please remove tests for SHA-1 and "3KEYTDEA" ("3 KEY TDEA", "DESEDE"), we are going to remove them soon.

- I don't fully understand what lines 144-147 mean. If an NSAE is thrown, checkException() only fails if alg is invalid. Maybe you should also fail if strength check inside it is false? For example, line 192, it's OK for SHA-1 to fail if strength > 128, but not if it's less.

- MoreDrbgParameters is internal. I suggest you stuff info about alg and df inside "securerandom.drbg.config". Probably no need to test nonce and es then. Or, if you still want to test on MoreDrbgParameters, move the test inside sun/security/provider/SecureRandom.

EnoughSeedTest.java:

- What if SUCCESS has been false once, but turns true in the last loop? Is that a success? Maybe you should "SUCCESS &= ..."?

- same with "success" inside forEachSeedBytes?

- What's the theory behind this test? Who said seed cannot ends with one or more zero? Zero is just as normal as any other byte which has its own 1/256 of probability to appear.

GetInstanceTest.java:

- Why name it DRBG_SEC_PROP?

- You use MoreDrbgParameters again. Is this necessary? I don't see how the 2 EntropySource are different.

MultiThreadTest.java:

- Lines 135-144: If it's out System.out.printf, then it's useless. There are theories on quality of RNGs. For example: https://www.random.org/analysis/.

SerializedSeedTest.java:

- The SHA1PRNG bug is pending. At the moment, can you just generate 32 bytes of data with nextBytes() inside check()?

Thanks
Max


> On May 8, 2016, at 9:57 PM, Sibabrata Sahoo <sibabrata.sahoo at oracle.com> wrote:
> 
> Hello,
>  
> Please review the tests for “JDK-8141039:Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations”.
>  
> Bug: https://bugs.openjdk.java.net/browse/JDK-8141039
> Webrev: http://cr.openjdk.java.net/~ssahoo/8141039/webrev.00/
>  
> The tests covers the new DRBG API with different set of parameters. It also covers the behavior of all SecureRandom mechanism supported in Java in Serialized as well as in multithread context.
>  
> Thanks,
> Siba




More information about the security-dev mailing list