On Sat, Jul 13, 2013 at 2:17 PM, Patrick Mylund Nielsen <[email protected]> wrote: > ... > "The fact is, even if you worry about some back door for the NSA, or some > theoretical lack of perfect 32-bit randomness, we can pretty much depend on > it. We still do our own hashing on top of whatever entropy we get out of > rdrand, and we would still have all our other stuff. Plus the instruction is > public and testable - if Intel did something wrong, they'll be *very* > embarrassed.
1. this is a weak argument; the kernel entropy pool is the proper place to _securely_ mix entropy into the available host pool. while sufficient for hash tables or stochastic shaping, it is insufficient for cryptographically strong entropy. 2. the RDRAND instruction is designed and implemented in such a way that you are unable to verify any noise source bias or working condition yourself - instead intentionally stone walled off from purview with the sole reviewer a third party company issued a non-production, test piece of hardware. there is a tedious thread in cryptography at random bit for the masochists among us which discuses all of these considerations and more! in short: this design does not inspire confidence. worth mixing into host entropy pool? sure. using directly or as the sole source of entropy in a system? not advisable. > ... and allow us to > get away from /dev/random running out of entropy. you can do this with a proper user space entropy daemon that validates and enforces the correct behavior (or at least not permitting clearly broken behavior) from physical entropy sources available on a system. again, these work best with access to the raw physical bit stream sampled from the entropy sources. the output of AES/$digest post-TRNG processing is of little use for statistical or correctness checks. yet this is all RDRAND provides... _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
