Re: Reseed testing in the FIPS DRBG implementation
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
-owner-openssl-...@openssl.org wrote: -
To: openssl-dev@openssl.org
From: Henrik Grindal Bakken
Sent by: owner-openssl-...@openssl.org
Date: 08/16/2011 05:50PM
Subject: Re: Reseed testing in the FIPS DRBG implementation
"Dr. Stephen Henson" 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
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 Au
Re: Reseed testing in the FIPS DRBG implementation
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-owner-openssl-...@openssl.org wrote: -To: openssl-dev@openssl.orgFrom: Henrik Grindal Bakken Sent by: owner-openssl-...@openssl.orgDate: 08/16/2011 05:50PMSubject: Re: Reseed testing in the FIPS DRBG implementation"Dr. Stephen Henson" 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 onlyexempted from the reseed test if you actually do predictionresistance. From what I can see in the code, prediction resistanceisn't used when using the FIPS_drbg_method(), since fips_drbg_bytes()call FIPS_drbg_generate() with 0 as the prediction_resistanceargument, hence the test is lacking.-- Henrik Grindal Bakken PGP ID: 8D436E52Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52__OpenSSL Project http://www.openssl.orgDevelopment Mailing List openssl-dev@openssl.orgAutomated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Reseed testing in the FIPS DRBG implementation
"Dr. Stephen Henson" 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 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
Re: Reseed testing in the FIPS DRBG implementation
On Wed, Aug 03, 2011, Henrik Grindal Bakken wrote: > "Dr. Stephen Henson" writes: > > > On Wed, Aug 03, 2011, Henrik Grindal Bakken wrote: > > > >> > >> Hi. I'm working on FIPS-validating a product using OpenSSL (but with > >> a crypto module spanning wider, so we can't easily use the OpenSSL > >> crypto module). During code review, some questions about the RNG > >> tests have come up. Most specifically, from what I can read, SP > >> 800-90 requires that (in 11.3.4) the reseed function shall perform a > >> known-answer test before reseeding, and from what I can read in the > >> code, this doesn't happen. > >> > >> Is there a reason for this? > > > > The OpenSSL implementation supports prediction resistance so 11.3.4 > > #2 should apply in this case. > > > > I notice however that it doesn't directly test entropy failure on an > > explicit reseed: though it does on a reseed caused by a PR > > request. I'll update it to include an explicit test too. > > Hi Steve, and thanks for your quick reply. > > Since OpenSSL supports prediction resistance, wouldn't that mean that > 11.3.4 #1 applies? However, even if it's #1 or #2, shouldn't a KAT be > performed at some point before the reseed actually takes place? I > must confess I don't really understand how SP 800-90 intends the KAT > to be carried out... > Sorry yes I meant #1. 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. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Reseed testing in the FIPS DRBG implementation
"Dr. Stephen Henson" writes: > On Wed, Aug 03, 2011, Henrik Grindal Bakken wrote: > >> >> Hi. I'm working on FIPS-validating a product using OpenSSL (but with >> a crypto module spanning wider, so we can't easily use the OpenSSL >> crypto module). During code review, some questions about the RNG >> tests have come up. Most specifically, from what I can read, SP >> 800-90 requires that (in 11.3.4) the reseed function shall perform a >> known-answer test before reseeding, and from what I can read in the >> code, this doesn't happen. >> >> Is there a reason for this? > > The OpenSSL implementation supports prediction resistance so 11.3.4 > #2 should apply in this case. > > I notice however that it doesn't directly test entropy failure on an > explicit reseed: though it does on a reseed caused by a PR > request. I'll update it to include an explicit test too. Hi Steve, and thanks for your quick reply. Since OpenSSL supports prediction resistance, wouldn't that mean that 11.3.4 #1 applies? However, even if it's #1 or #2, shouldn't a KAT be performed at some point before the reseed actually takes place? I must confess I don't really understand how SP 800-90 intends the KAT to be carried out... -- Henrik Grindal Bakken 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
Re: Reseed testing in the FIPS DRBG implementation
On Wed, Aug 03, 2011, Henrik Grindal Bakken wrote: > > Hi. I'm working on FIPS-validating a product using OpenSSL (but with > a crypto module spanning wider, so we can't easily use the OpenSSL > crypto module). During code review, some questions about the RNG > tests have come up. Most specifically, from what I can read, SP > 800-90 requires that (in 11.3.4) the reseed function shall perform a > known-answer test before reseeding, and from what I can read in the > code, this doesn't happen. > > Is there a reason for this? > The OpenSSL implementation supports prediction resistance so 11.3.4 #2 should apply in this case. I notice however that it doesn't directly test entropy failure on an explicit reseed: though it does on a reseed caused by a PR request. I'll update it to include an explicit test too. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Reseed testing in the FIPS DRBG implementation
Hi. I'm working on FIPS-validating a product using OpenSSL (but with a crypto module spanning wider, so we can't easily use the OpenSSL crypto module). During code review, some questions about the RNG tests have come up. Most specifically, from what I can read, SP 800-90 requires that (in 11.3.4) the reseed function shall perform a known-answer test before reseeding, and from what I can read in the code, this doesn't happen. Is there a reason for this? -- Henrik Grindal Bakken 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
