RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Bradford Wetmore]

On 4/25/2016 11:25 PM, Wang Weijun wrote:
>
>> On Apr 26, 2016, at 8:48 AM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
>>
>> but the runtime "Health Testing" I was talking about is in the diagram of Section 7, and details in section 11.3:
>
> I haven't touched this area yet.
>
> If you think it's necessary, I would like to add the test inside the static <clinit> block of AbstractDrbg$SeederHolder. The test will be on Hash_DRBG/SHA-256 and whatever mech/algorithm defined by securerandom.drbg.config (They are the same by default). The test will be in the same thread (otherwise I don't know how to report an error). If it fails, a RuntimeException will be thrown.

Please read over this section, but I *THINK* you are supposed to run a 
known-answer test on each SecureRandom instance created, not just the 
single one used as a seeder during <clinit>:

     Known-answer tests shall be conducted on each DRBG function within
     a boundary or sub-boundary prior to the first use of that DRBG
     (e.g., during the power-on self-testing sequence).

Which may mean that you'll need a known-answer test for each 
configuration type.  Unless I'm interpreting this wrong.

> I can extract the test from CAVP, instantiate + reseed + generate with both non-null personalization string and additional input, and PR on. It won't take long.
>
> This is purely internal and automatic, maybe a new abstract method in AbstractDrbg is needed.
>
> Can we do this after the JEP?

That's fine with me, but the answer needs to be resolved (either work 
completed or it will not be done) by FCS/GA.

> BTW, I probably will not be able to send out a new webrev today. Tomorrow is OK.

Tomorrow is fine, it will allow me to respond to your other Q's.  ;)

Brad