RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Bradford Wetmore bradford.wetmore at oracle.com
Wed Apr 20 00:54:42 UTC 2016

 > 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.

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?

# 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

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:


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?


More information about the security-dev mailing list