On 4/25/2016 11:25 PM, Wang Weijun wrote:
On Apr 26, 2016, at 8:48 AM, Bradford Wetmore <bradford.wetm...@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
