Design review: JEP 273: DRBG-Based SecureRandom Implementations

[Wang Weijun]

There's been a long time, the current status is

http://cr.openjdk.java.net/~weijun/8051408/webrev.03/
http://cr.openjdk.java.net/~weijun/8051408/webrev.03/specdiff/java/security/package-summary.html

Two main changes:

1. s/EntropyInput/EntropySource/g.

2. Two methods in EntropySource, getFullEntropy() is only used by CtrDRBG without a derivation function and all generateSeed(), getEntropy() is used elsewhere.

To be determined:

1. As 800-90Ar1 9.1 says, the nonce "shall not be provided by the consuming application". Currently the only usage for DrbgParameters.Builder#nonce is the DRBG CAVP test (not included in webrev yet). Shall we remove the related public methods (in DrbgParameters) for compliance? Or, add a comment that these methods "shall not" be called by applications unless they can guarantee the uniqueness?

2. 800-80Ar1 9.2 and 9.3.2 allow requested_security_strength and prediction_resistance_request parameters for the reseed and generation functions. We don't support this now. Unless a child class of SecureRandom is defined, we cannot add these parameters directly to SecureRandom#nextBytes. One solution is to add a SecureRandomParameters parameter there, but we need a place to clearly document which fields inside the parameter is used.

3. The current algorithm names are HashDRBG, HmacDRBG and CtrDRBG. This matches IBM JDK's HASHDRBG name. Or shall we use the names in 800-90Ar1? i.e. Hash_DRBG, HMAC_DRBG, CTR_DRBG? At least as aliases?

4. It seems there should be a "hasPredictionResistance()" method for EntropySource, since reseed() needs to know it. But this JEP is only about DRBG and EntropySource is a very complicated concept. Maybe we can just pretend every EntropySource has prediction resistance at the moment.

Thanks
Max


> On Nov 21, 2015, at 10:40 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
> 
> 
>> On Nov 20, 2015, at 8:23 AM, Wang Weijun <weijun.wang at oracle.com> wrote:
>> 
>>>> 2. For each of these, if you have getInstance(alg, params), there is no getInstance(alg). Obviously, for SecureRandom we need to have both.
>>> 
>>> Right, this is the first case where we have both variants of getInstance.
>>> 
>>> Just looking through the code, it looks like you can change Provider.Service.newInstance() to call the appropriate constructor depending on whether the constructorParameter is null or not. Can you try that?
>> 
>> Good. I'll try.
> 
> I first made this change
> 
> -        addEngine("SecureRandom",                       false, null);
> +        addEngine("SecureRandom",                       false,
> +                            "java.security.SecureRandomParameters");
> 
> and then update this method
> 
>     private static Object newInstanceUtil(final Class<?> clazz,
>         final Class<?> ctrParamClz, final Object ctorParamObj)
>         throws Exception {
>         if (ctrParamClz == null) {
>             Constructor<?> con = clazz.getConstructor();
>             return con.newInstance();
>         } else {
> -            Constructor<?> con = clazz.getConstructor(ctrParamClz);
> -            return con.newInstance(ctorParamObj);
> +            try {
> +                Constructor<?> con = clazz.getConstructor(ctrParamClz);
> +                return con.newInstance(ctorParamObj);
> +            } catch (NoSuchMethodException nsme) {
> +                if (ctorParamObj == null) {
> +                    Constructor<?> con = clazz.getConstructor();
> +                    return con.newInstance();
> +                } else {
> +                    throw nsme;
> +                }
> +            }
>         }
>     }
> 
> For an existing implementation without <init>(SecureRandomParameters), <init>() will be called instead.
> 
> Thanks
> Max
>