"Leichter, Jerry" <[EMAIL PROTECTED]> writes: >| From: [Name Withheld] >| Actually you cant even guarantee that because the FIPS 140 requirements >| for the ANSI X9.17/X9.31 PRNG include a pile of oddball things that made >| sense for the original X9.17 use (where it was assumed the only source >| of entropy was a DES3 key embedded in secure hardware) but are severe >| restrictions on current implementations. As a result a FIPS 140- >| certified key generator will be worse than a well-designed non-FIPS-140 >| one because the FIPS requirements prevent you from doing several things >| that would improve the functioning like injecting extra entropy into the >| generator besides the DES3 key. >I think this was changed as FIPS 140 evolved. Several things about the >random number generator evolved. For example, in earlier versions, you had >to run some tests on your generator at every startup. That disappeared by >FIPS 140-2.
That was because for a good RNG the only thing you'd ever get are false positives, so it acted as a "make your generator fail randomly" test. >(It makes sense for a hardware generator, but never did for software.) There are already a pile of huge mental leaps you have to make to apply some of the more hardware-oriented bits of FIPS 140 to software implementations, if you read Microsoft's CryptoAPI FIPS docs you'll see some examples of these in there. For example the physical module boundary is the case of the PC that Windows is running on, the role-based access control covers one single user, whoever's using the PC at the moment, and so on - it's compliance by creating paperwork rather than by engineering. (I'm not trying to bash Microsoft here, other vendors have to resort to the same thing, see e.g. the Crypto++ docs for another public example of this). The problem here is that FIPS 140 was designed for military-security-model crypto hardware, has been stretched to cover embedded device crypto, and has been seriously over-stretched to try and cover software crypto (that is, instead of creating a distinct profile to cover software implementations, the hardware implementation was taken into places it was never meant to go). The only way to reconcile the two is through increasingly tortuous interpretations of various hardware-derived requirements that don't really work for software. >You're definitely free to set the starting state using any source of entropy >you like. I *think* you can add extra entropy along the way; though even if >this were not allowed, you could probably declare that you were restarting. Depends entirely on who's doing the eval. For example if you read the OpenSSL FIPS docs (http://www.openssl.org/docs/fips/) they have an entire appendix dedicated to a discussion of the absence of fork protection, which they weren't allowed to add: The fact that this 'fork protection' is absent in the FIPS object module PRNG concerns many in the OpenSSL developer and user community, and will be the primary obstacle to making the fips configuration option a default. 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. (Maybe we could come up with a cross-reference of who will allow what, and then people could choose the most sensible evaluator to submit things to). Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]