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