RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

[Anthony Scarpino]

On 04/26/2016 12:27 PM, Bradford Wetmore 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>:
>
>      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 have not read the spec, but this sounds like something when FIPS is 
enabled, not during normal operation.  Are you sure a POST is required 
during normal usage?

Tony