On 9 Jul 2007 16:08:33 -0600, Darren Lasko wrote:
>>> 2) Does FIPS 140-2 have any requirements regarding the quality of the
>>> entropy source that is used for seeding a PRNG?
>> Yes.  The requirement imposed by FIPS 140-2
>> (http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf)
>> are in section 4.7.2:
>>  "Compromising the security of the key generation method (e.g., guessing
>>  the seed value to initialize the deterministic RNG) shall require as
>>  least as many operations as determining the value of the generated key."
>> (which would apply to any RNG output that became a key)
>> and in section 4.7.3:
>>  "Compromising the security of the key establishment method (e.g.,
>>  compromising the security of the algorithm used for key establishment)
>>  shall require at least as many operations as determining the value of
>>  the cryptographic key being transported or agreed upon."
>> (which would apply to any RNG output that is used in a security relevant
>> way in a key establishment scheme)

  For whatever reason, I get asked FIPS 140 questions and this one about
FIPS 140-2 comes up on occasion. It is good someone finally asked in
public and received a public reply. A bit convoluted, and this says
nothing about seeding requirements for a PRNG not used for key
generation/agreement, but it is the logic of FIPS 140-2 with regards to
PRNG seeding.

> Again, good information.  However, it seems pretty nebulous about how
> they expect you to measure the number of operations required to
> compromise the security of the key generation method.  Do you know
> what kind of documentation the labs require?
> SP 800-90, Appendix C.3, states that the "min-entropy" method shall be
> used for estimating entropy, but this method only uses the
> probabilities assigned to each possible sample value.  I'm guessing
> that measuring ONLY the probabilities associated with each sample is
> insufficient for assessing your entropy source.  For example, if I
> obtain 1 bit per sample and I measure 50% 0's and 50% 1's, I have
> "full entropy" by that measure, even if my entropy source always
> produces "1010101010101010....".
> Is the "NIST Statistical Test Suite" sufficient for evaluating your
> entropy source, and will the certification labs accept results from
> the STS as an assessment of the entropy source?

 From what I have seen, the labs understand what will pass muster with
NIST/CSE for FIPS 140-2 based on their experience with the many FIPS
140-2 validation efforts performed to this point, so they are a good
gauge of what NIST/CSE will smile upon here, even though there has been
little formal guidance. Most labs are fine with standard techniques for
gathering entropy from a system, such as polling various timings for
things like disk access, plus whitening, such as running the results of
the polling through a FIPS-approved hashing algorithm. Hardware RNGs,
such as a noise source, which can be used either as just another source
in the polling, or as the only source. When using a hardware RNG, most
vendors focus on this as the primary source of entropy, and labs will
often require many details about the hardware RNG as a result.

As far as what to provide, well, you need to describe how the PRNG is
seeded, give code pointers to the seeding and any entropy gathering
routines, include details on any hardware RNGs, and construct a general
rationale for why all this adds up to meeting the requirements. The labs
can take it from there and ask for more information as needed, such as
sample output from the entropy gathering routines to examine. If you are
concerned about not meeting the requirements, chatting with a lab or
consultant about what is required is not out of the question - it might
even provide some metric as to how friendly and responsive the team you
are considering working with for your validation will be.

FWIW, up to this point in time, I have rarely seen formal calculations
of entropy by vendors in the rationale for meeting these requirements
(those few times were mostly with vendors that built their own hardware
RNGs), and I have seen statistical tests used by vendors a little bit as
a part of the rationale behind meeting these requirements.


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

Reply via email to