>> The other one, which I have to think *very* hard about, is whether >> using the same seed material as /dev/random in this much weaker >> cryptographic construction will introduce a flaw in *it*. > I have no idea what you are referring to here. The caller is requred to > seed the DRNG. Typically that is done with a call to get_random_bytes. > As Neil mentioned, the X9.31 DRNG implementation does not seed itself. Er, yes it does. Not the key, but the IV vector V[]. Here's the closest thing I can find on-line to a direct quote from the ANSI Spec: http://www.untruth.org/~josh/security/ansi931rng.PDF "Let DT be a date/time vector which is updated on each iteration." This timestamp is a source of continuous reseed material. The spec doesn't impose specific resolution requirements, but it's hopefully obvious that the finer, the better. The goal is a vector which changes per iteration. There are limitations due to its finite entropy and lack of catastrophic reseeding, as Kelsey & Schneier pointed out: https://www.schneier.com/paper-prngs.html but it is intended as an entropy source. Hopefully very soon I'll have a patch series to post. (Unfortunately, I just managed to oops my kernel and need to reboot to continue testing.) If I don't do much more, it'll be patch 13/17 in the series. I think the use of get_random_int() is a good compromise between the raw random_get_entropy() timestamp and the (too heavy) get_random_bytes(). -- 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
