RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Bradford Wetmore]

 > Webrev updated again at
 >
 > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/
 > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/spec
 > http://cr.openjdk.java.net/~weijun/8051408/webrev.10/specdiff

Some initial comments.

security/java.security
======================
123-133:  Would you consider changing the ordering of the algorithm
names to be consistent between the two sections?  Say:

     NativePRNG, SHA1PRNG, and DRBG.

175:  Should we add DRBG:SUN as a backup for non-windows?

181:
# NIST SP 800-90Ar1 lists several DRBG mechanisms, each can be 
configured with
->
# NIST SP 800-90Ar1 lists several DRBG mechanisms. Each can be 
configured with

184:
request of "DRBG" SecureRandom implemented in the SUN provider.
->
request of "DRBG" SecureRandom implementations in the SUN provider.
(Other DRBG implementations might also use this property.)

188:  Can you adjust the line lengths so it looks polished, and not
edited in place?  I use a vi macro (using fmt) for this.

189:  Do you want to add "currently", or leave as is?
names are not configurable
->
names are not currently configurable

194:  Am I missing something?
is a slash-separated list
->
is a comma-separated list

198:  Should we add a short 1-liner description for the fields?  The
variable meanings (esp pr/df) may not be obvious to a casual observer.
For example, using these three fields as an example:

     mech_name: default "Hash_DRBG"
         "Hash_DRBG" | "HMAC_DRBG" | "CTR_DRBG"

+        The DRBG mechanism to use.

     pr: default "none"
         "pr_and_reseed" | "reseed_only" | "none"

+        Prediction resistance...

     df: default "use_df", only applicable to CTR_DRBG
         "use_df" | "no_df"

+        Derivation Function...

210:  Instead of pointing to 800-90A here, you should instead point to
the Sun Provider document.  That document will then reference
800-90A/Section 10, and will use the Standard Algorithm names that
you have defined for these algorithms.  (I assume you'll be adding
those to the standard algorithm name doc, right?  I don't recall seeing
that part of the review yet, but maybe haven't gotten that far.)

214: In the past, we've used spaces as a field separator for names in
a provider, I'm wondering if we should make this name something like
"3KeyTDEA" instead?

229: I hadn't noticed this before, but the Security variable "drbg"
doesn't match the style of the other variables, securerandom.* or
otherwise. I think we should use something like either:

     securerandom.drbg
     securerandom.drbg.config

229: Why an empty string here?  Why not actually specify the default here
instead of burying the default somewhere where it might changed without
a corresponding update to this file?

Thanks,
Brad