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.w...@oracle.com> wrote:
>
>
>> On Nov 20, 2015, at 8:23 AM, Wang Weijun <weijun.w...@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
>
