That interpretation seems - brain dead - to be polite.
The problem is that running the health check trashes the state of the DRBG you are using, so running it on every reseed means that the DRBG is re-initialized each time - and you may as well be in PR mode anyway.
O.K. you could save and restore the state before reseeding - but it's excessive and pointless - and if you restore the state, running the health check proves nothing.
It's really really unlikely that the DRBG *code* is corrupted even in a general purpose OS (and even more unlikely if it's a hardware implementation) and far more likely that it's internal state *data* is messed up - which the health check won't find.
I think your contact at the lab. needs to check the meaning of this with NIST.
Peter
The problem is that running the health check trashes the state of the DRBG you are using, so running it on every reseed means that the DRBG is re-initialized each time - and you may as well be in PR mode anyway.
O.K. you could save and restore the state before reseeding - but it's excessive and pointless - and if you restore the state, running the health check proves nothing.
It's really really unlikely that the DRBG *code* is corrupted even in a general purpose OS (and even more unlikely if it's a hardware implementation) and far more likely that it's internal state *data* is messed up - which the health check won't find.
I think your contact at the lab. needs to check the meaning of this with NIST.
Peter
To: openssl-dev@openssl.org
From: Henrik Grindal Bakken <h...@ifi.uio.no>
Sent by: owner-openssl-...@openssl.org
Date: 08/16/2011 05:50PM
Subject: Re: Reseed testing in the FIPS DRBG implementation
"Dr. Stephen Henson" <st...@openssl.org> writes:
> The OpenSSL DRBG implementation tests all variants during the POST
> and also tests specific versions on instantiation. That includes an
> extensive health check and a KAT. So in that sense there will be two
> KATs before a reseed takes place but no KAT immediately before a
> reseed takes place.
>
> According to my reading of the standard you don't need a KAT before
> ressed if you support PR. However different labs will have different
> opinions and should we require one it can be added easily enough.
I've now asked our contact at the lab, and he says that you're only
exempted from the reseed test if you actually do prediction
resistance. From what I can see in the code, prediction resistance
isn't used when using the FIPS_drbg_method(), since fips_drbg_bytes()
call FIPS_drbg_generate() with 0 as the prediction_resistance
argument, hence the test is lacking.
--
Henrik Grindal Bakken <h...@ifi.uio.no>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
