Flaws in OpenSSL FIPS Object Module

Thor Lancelot Simon tls at rek.tjls.com
Fri Dec 14 13:27:57 EST 2007

On Fri, Dec 14, 2007 at 08:33:16AM -0800, Joshua Hill wrote:
> You may be confusing the requirements for a KAT which is a power-up health
> check on all of the deterministic components of the PRNG (which is run on
> power-up and requires that you fix all the inputs to some specific known
> value and verify that a known result is produced) and the requirements
> for algorithm testing of your PRNG (which for X9.17/X9.31, does require
> treating DT as a monotonic counter for one portion of the test).

The PRNG test which requires DT to be run as a monotonic counter is, in
fact, a known-answer test.  To run that test at all, if one's PRNG is
implemented (as was permitted prior to the introduction of that test)
with DT as an actual clock, one has to alter the mode of operation of
the PRNG in a rather fundamental way.

> > Of course, that mode is _less_ secure (because the internal state is
> > more predictable) than the other, but given the choice between "validate
> > PRNG using special mode, run it using normal mode" or "validate PRNG
> > using special mode, run it using special mode" I know I'd pretty much
> > always take the latter.  
> That's your choice, of course.
> > In fact, the test lab we were using told us they were quite skeptical
> > about the former as well.
> So, did they require that you use your AES implementation using the test
> fixture as well?

I'm not sure what you're suggesting, but I think you misunderstand the
difference between the validation tests for AES and those for the PRNG.
The validation tests for AES do not dictate internal implementation details
of the DUT beyond the extent specified in the controlling standards, and
thus a conformant AES implementation cannot need to have its internals
rearranged in order to be attached to the test fixture.

That is *not* the case for the X9.17 PRNG and the test now specified for
it, which means that the test, itself, creates new opportunities for very
nasty bugs, or requires those who implemented the PRNG using a clock or
free-running counter to reimplement using a simple counter.  I tend to
think that this is a regrettable decrease in the strength of the RNG
but that, regardless, implementations of an algorithm should be required
to actually run the validated algorithm, not some other one that is close,
except that part of the algorithm's guts were swapped out for testing.


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

More information about the cryptography mailing list