First, what FIPS 140-2 says.
There are two issues here.
First, there are two sections of FIPS 140-2 that are about self tests.
One is 4.9.1. That is about power on self tests. That is where all the
known answer tests are mentioned. Obviously reseeding is not done at
power-on. The other is 4.9.2. That is where the "conditional tests"
are. Those have to be done on every call. The only requirement (for
generators whose output is at least 16 bits wide) is that you check that
the consecutive values are not equal. (The text is somewhat garbled.
It looks like they might have intended that the first value be saved and
compared with subsequent values, but that's not what it actually says.
Note that saving values spoils backtracking resistance a bit, but that
is another topic.)
But it appears that the requirement you are referring to comes from NIST
SP 800-90. If you read that carefully, you see that the tests apply to
the _implementation_, not the _instantiation_.
Note the quote in Section 11.3, it says, that "Note that testing may
require the creation and use of an instantiation for
testing purposes only." So you can make a new "instance" (typically a
context pointer points to an instance) for testing the reseed.
Alas, however, there is a really stupid requirement that will complicate
things: "All data output from the DRBG mechanism boundary (or
sub-boundary) shall be inhibited while these tests are performed." This
means that in a multi-threaded application, you can't have one thread
doing a self-test on it's own instance (context structure) while other
threads are doing normal work with their instances. You will be stuck
with a mutex and condition variable, and a complicated system of
blocking normal users, waiting for a user count to go to zero, etc.
Finally, Section 11.3.4 has this requirement: "When prediction
resistance is not supported in an implementation, the reseed function
shall be tested whenever the reseed function is invoked and before the
reseed is performed on the operational instantiation." Note that it
says only the the "reseed function shall be tested". It does not say
that the reseed function of the operational instantiation needs to be
tested.
--David
On 8/20/2011 6:20 PM, Peter Waltenberg wrote:
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
[email protected] wrote: -----
To: [email protected]
From: Henrik Grindal Bakken <[email protected]>
Sent by: [email protected]
Date: 08/16/2011 05:50PM
Subject: Re: Reseed testing in the FIPS DRBG implementation
"Dr. Stephen Henson" <[email protected]> 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 <[email protected]>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org Development Mailing List
[email protected] Automated List Manager [email protected]
------------------------------------------------------------------------
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 10.0.1392 / Virus Database: 1520/3847 - Release Date: 08/20/11
