Am Montag, 15. Dezember 2014, 05:45:31 schrieb George Spelvin: Hi George, >>> You will agree, I hope, that the result from get_random_int *does* >>> include the entropy of a high-resolution timestamp? Which is >>> cryptographically equivalent to including the unobfuscated >>> timestamp? >> >> get_random_int does provide entropy, but my gut feeling (I have not >> done measurements) is that it is in the range of maybe 2 / 3 bits >> per invocation. > >You said you didn't want to start a conversation about entropy, >remember? >:-) So I'm not discussing the issue, but please don't interpret that > >as conceding anything. ;-) > >As I said, it doesn't matter; my goal is just to do what the spec asks >for, as faithfully as possible without introducing any stupidities in >the process. > >>> Which is why I'm trying to follow the spec as precisely as possible. >> >> If you only look at the regulatory side, then you must be aware of >> SP800-131A applicable at least to the US side. X9.31 is sunsetted by >> the end of 2015 and even not FIPS 140-2 certifiable any more for new >> validations. > >Well, if nobody wants it, why not simply rip it out? All I referred to was the US regulatory side. And the US is not the world. Note, even NIST considers X9.31 as a strong RNG after speaking with their cryptographers a couple of weeks ago. The only drawback it has is the missing reseed requirement which is brought in by SP800-90A. After implementing SP800-90A I have to admit that I like the X9.31 for its simplicity (which is en-par with the HMAC DRBG which I therefore marked as default in the DRBG). The other two DRBGs (Hash and CTR are too complex for my personal taste -- but they are there for completeness). Thus, I think the X9.31 does have a purpose as it implements a reasonably simple DRNG. > >I'm assuming there are other requirements documents that refer to >those documents, and haven't been updated to reflect tha changes. There are other regulartory bodies which still approve of the X9.31 -- like the German BSI, provided you can show that your use case ensures proper reseeding. > >That's what tends to happen: requirements flow downstream over >a period of years. NIST may change its mind, but my contract >hasn't noticed yet. Exactly -- there are use cases where the latest NIST regulations either accidentally or deliberately are not considered. The biggest issue is today's "bad smell" of the SP800-90A standard after the Dual EC DRBG fiasco. Thus, I think people should think twice before using a NIST developed standard (which X9.31 is not, albeit IIRC it came out of the NSA realm long time ago). > >I know this from personal experience: I've had frustrating discussions >about a "too hard to change" requirement for 1024-bit DSA *and* FIPS >140 certification. Hehehe, been there, done that, experienced the same. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
