How important is FIPS 140-2 Level 1 cert?

[lists]

On 27 Dec 2006 14:10:10 -0500, Thor Lancelot Simon wrote:
> On Tue, Dec 26, 2006 at 05:36:42PM +1300, Peter Gutmann wrote:
>> In addition I've heard of evaluations where the generator is required to use a
>> monotonically increasing counter (clock value) as the seed, so you can't just
>> use the PRNG as a postprocessor for an entropy polling mechanism.  Then again
>> I know of some that have used it as exactly that without any problems.

I have never heard of the seed being required to use a clock value,
and, under FIPS 140-2, using only a clock value to seed a PRNG is not
going to pass the key management requirements.

> This (braindamaged) requirements change was brought in by the creation of
> a Known Answer Test for the cipher-based RNG.  Prior to the addition of
> that test, one could add additional entropy by changing the seed value at
> each iteration of the generator.  But that makes it, of course, impossible
> to get Known Answers that confirm that the generator actually imlements
> the standard.  So suddenly the alternate form of the generator -- in my
> opinion much less secure -- which uses a monotonically-increasing counter
> for the seed, was the only permitted form.

Now we are talking about something different, the date/time (DT)
vector of the X9.31 PRNG, which is not the seed of the X9.31 PRNG.

I don't think anything changed with the introduction of a power-up
PRNG KAT or PRNG algorithm testing. Even the NIST-defined PRNGs, which
are based upon the X9.31 PRNG, are open in regard to what an
implementer chooses to use as the DT vector.

Take the power-up PRNG KAT. By definition, this requires the use of
known values, which means, for an X9.31 PRNG, even the DT vector needs
to be set to a known value. Adding in entropy violates this
requirement, but, after the KAT is performed (and passed), the PRNG is
required to be seeded with "real" data before assuming its normal
operational state.

Take algorithm testing. This testing too requires the use of known
values, in this case provided by a testing lab, which are run through
an implementation to produce results that can then be verified by a
testing lab. For an X9.31 PRNG, this testing requires access to a
parameter (DT) of the X9.31 PRNG that may not normally be accessible
outside of the PRNG. It is just fine to have a test mode to provide
this access, and then the counter woes can be made to go away as part
of this test mode. (Note: Algorithm testing is once off testing
performed by the vendor and not normally deployed in a product.)

> I have yet to hear of anyone who has found a test lab that will certify
> a generator implementation that uses the mono counter for the KAT suite
> but a random seed in normal operation.  For good reason, labs are usually
> very leery of algorithm implementations that come with a "special test
> mode".

It seems to me that an implementation of an X9.31 PRNG without a test
mode makes no sense, for the reasons cited above. This mode would be
used in a self-testing state, or during algorithm testing, but not in
normal operational state.

As an example of a module with public source code, OpenSSL made it
through FIPS validation doing this. Their X9.31 PRNG normally uses
clock data for DT, but, in test mode, DT can be set from the outside
instead. This test mode is utilized for the power-up KAT as well as
algorithm testing. I can imagine this is not a unique occurrence.

-Andrew

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com