RFR 8051408: JEP 273: DRBG-Based SecureRandom Implementations

Bradford Wetmore bradford.wetmore at oracle.com
Tue Apr 26 00:48:44 UTC 2016


On 4/24/2016 9:13 PM, Wang Weijun wrote:
>> I didn't see any health tests.  What is your plan for that?
> *** If by health test your means the CAVP known-output tests, I am going to put it into test/closed since it's reading a huge (13MB) external file and should be stored on an artifact server.
>
> That said, I'll be happy to extract a subset of it and make it a public test.

So the running the full set of CAVP known-output tests in closed is good 
for build/test time algorithm correctness, but the runtime "Health 
Testing" I was talking about is in the diagram of Section 7, and details 
in section 11.3:

     11.3 Health Testing
     A DRBG implementation shall perform self-tests to obtain assurance
     that the DRBG continues to operate as designed and implemented
     (health testing).
     ....
     All data output from the DRBG mechanism boundary (or sub-boundary)
     shall be inhibited while these tests are performed.
     ...
     11.3.1
     ...
     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).

I don't see in my admittedly brief look at this part of 800-90A when or 
how often these tests are supposed to run after POST (power on self 
test): as a thread in the background, or at power on, or what have you.

You're also supposed to enter a error state from which it requires the 
operator to recover.  I didn't see that code either.

I'll try to get to the other comments tomorrow.

Thanks,

Brad



More information about the security-dev mailing list