RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Wang Weijun weijun.wang at oracle.com
Thu May 5 08:34:55 UTC 2016


Hi Brad

I did't expect I need a new updated version at

   http://cr.openjdk.java.net/~weijun/8051408/webrev.14/

Changes include:

1. The new wording you suggested below.

2. All health-test related codes (even if they were not called in webrev.13 at all) removed.

3. Revert the change in ByteArrayAccess.java [1] and make proper change in SHA5.java. Valerie will be making more changes to this file and I'd better not touch it.

No new spec/ and specdiff/ generated. In fact, I haven't grayed out webrev.13/index.html at all.

Bonus: new interdiff link [2].

Thanks
Max

[1] http://cr.openjdk.java.net/~weijun/8051408/webrev.13/src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java.udiff.html
[2] http://cr.openjdk.java.net/~weijun/8051408/webrev.14/interdiff.patch.html


> On Apr 29, 2016, at 2:46 AM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
> 
> We were on the same page after all.  I completely misunderstood your point in a previous email.  What you have is fine (change limit->limited), or a minor suggestion below (take it or leave it):
> 
> Some random number generators can only generate a limit amount
> of random bytes per invocation. If the size of {@code bytes}
> is greater than this limit, the implementation should invoke
> the process multiple times to generate enough random bytes
> in a single {@code engineNextBytes} call.
> ->
> Some random number generators can only generate a limited amount
> of random bytes per invocation. If the size of {@code bytes}
> is greater than this limit, the implementation should invoke
> its generation process multiple times to completely fill the
> buffer before returning from this method.




More information about the security-dev mailing list