RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Wang Weijun]

> On Apr 27, 2016, at 3:27 AM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
> 
> 
> 
> 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>:

Not the single one, but also the mech/alg pair defined in securerandom.drbg.config, which I think is the only configuration type that a user can create. We don't really need to test for each instance, right?

Please note I won't run the test on any real instance, I'll just call the *Algorithm methods directly (more like a static method), this method will be inside each implementation class.

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

OK, you also say "each configuration".

Thanks
Max