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 [EMAIL PROTECTED]