[cryptography] [liberationtech] Heml.is - "The Beautiful & Secure Messenger"
coderman at gmail.com
Sat Jul 13 21:39:24 EDT 2013
On Sat, Jul 13, 2013 at 2:17 PM, Patrick Mylund Nielsen
<cryptography at patrickmylund.com> 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*
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...
More information about the cryptography