Re: Flaws in OpenSSL FIPS Object Module

[Thor Lancelot Simon]

On Tue, Dec 11, 2007 at 04:00:42PM -0500, Leichter, Jerry wrote:
> | > It is, of course, the height of irony that the bug was introduced in
> | > the very process, and for the very purpose, of attaining FIPS
> | > compliance!
> | 
> | But also to be expected, because the feature in question is
> | "unnatural": the software needs a testable PRNG to pass the compliance
> | tests, and this means adding code to the PRNG to make it more
> | predictable under test conditions.
>
> Agreed.  In fact, this fits with an observation I've made in many
> contexts in the past:  Any time you introduce a new mode of operation,
> you are potentially introducing a new failure mode corresponding to
> it as well.

In fact, I was in the middle of a FIPS-140 certification at level 2
a number of years ago when the Known Answer Test for the X9.17 block
cipher based PRNG was introduced.  One unanticipated side effect of
this test was to make it impossible to actually use a clock or free
running counter as the counter in the PRNG, since the KAT expected
the simplistic "increment counter by 1 every time a block is extracted"
behavior chosen by most implementers.

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.  In fact, the test lab we were using told us
they were quite skeptical about the former as well.

Fortunately, the requirement for the PRNG KAT was delayed long enough
to let us get our code out the door without having to actually choose
either of the unpalatble ways.  But it does highlight a certain tension
in the process: they want to know that algorithms have predictable
(correct) results, but RNGs are supposed to have unpredicatable (correct)
results.  So any PRNG that is testable as part of the certification
process pretty much _has to_ have two modes, and bugs like this may
be more likely to occur in normal operation.

Thor

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]