Re: PRNG design document?
Anton Stiglic [EMAIL PROTECTED] writes: It is important to chose both a random seed and random key, and FIPS 140 has no provision for this. Yes it does, you just have to interpret it correctly. The post-processed pool output [from the cryptlib generator] is not sent directly to the caller but is first passed through an X9.17 PRNG that is rekeyed every time a certain number of output blocks have been produced with it, with the currently active key being destroyed. Since the X9.17 generator produces a 1:1 mapping, it can never make the output any worse, and it provides an extra level of protection for the generator output (as well as making it easier to obtain FIPS 140 certification). Using the generator in this manner is valid since X9.17 requires the use of DT, a date/time vector which is updated on each key generation, and cryptlib chooses to represent this value as a complex hash of assorted incidental data and the date and time. The fact that 99.% of the value of the X9.17 generator is coming from the timestamp is as coincidental as the side effect of the engine-cooling fan in the Brabham ground-effect cars [Reference]. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PRNG design document?
On Fri, Aug 29, 2003 at 11:27:41AM +0100, Ben Laurie wrote: As you mentioned, the FIPS-140-2 approved PRNG are deterministic, they take a random seed and extend it to more random bytes. But FIPS-140-2 has no provision for generating the seed in the first place, this is where something like Yarrow or the cryptlib RNG come in handy. Actually, FIPS-140 _does_ have provision for seeding, at least for X9.17 (you use the time :-), but not for keying. I think there's some confusion of terminology here. A time, Ti for each iteration of the algorithm, is one of the inputs to the X9.17 generator (otherwise, you might as well just use DES/3DES in any chaining or feedback mode, for all practical purposes). However, it has always been permitted to use a free-running counter instead of the time, and indeed the current interpretation by NIST *requires* that a counter, not the time, be used. As for keying, you're allowed to key with whatever you want, whenever you want, but at least from my conversations with a number of people during a recent certification, you'd better be prepared to explain why your source of key material is strong. One implementation with which I was involved essentially rekeyed the generator as soon as enough entropy had accumulated from a hardware source; another rekeyed it depending on the number of output blocks. Both approaches are permissible. I do have some more thoughts on the quality of the various generators the standard allows but I haven't had time to get them down in writing; I'll try to do so before this thread is totally stale... -- Thor Lancelot Simon [EMAIL PROTECTED] But as he knew no bad language, he had called him all the names of common objects that he could think of, and had screamed: You lamp! You towel! You plate! and so on. --Sigmund Freud - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PRNG design document?
On Fri, Aug 22, 2003 at 10:00:14AM -0700, Bob Baldwin PlusFive wrote: Tim, One issue to consider is whether the system that includes the PRNG will ever need a FIPS-140-2 rating. For example, people are now working on a FIPS-140 validation for OpenSSL. If so, then the generator for keys and IVs MUST be a FIPS approved algorithm, whether or not there are That's not quite right. 1) Various entities have already had various versions of OpenSSL FIPS-140-2 certified. 2) It is permissible to use a non-Approved deterministic RNG for IV generation, though not for keying. Since it's permissible to rekey the Approved PRNG, and there is no requirement for _how_ it is rekeyed save that the input must not have demonstrably less entropy than the output, it is possible to use, if not Yarrow, a _very_ similar design by using an entropy pool collecting input from one or more hardware sources to periodically rekey the Approved X9.17 generator. I am informed that in the past, implementations using Yarrow have, in fact, been certified, passing the code examination in the lab by documenting that Yarrow's output stage is, in fact, algorithmically equivalent to the X9.17 generator. Unfortunately, since those products were certified, there have been some particularly ill-considered interpretations of the X9.17 RNG specification by NIST which I believe would now make it impossible to have a Yarrow implementation certified; but you can get very close. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
