[cryptography] on using RDRAND [was: Entropy improvement: haveged + rngd together?]

coderman coderman at gmail.com
Tue Dec 3 18:25:22 EST 2013


On Mon, Dec 2, 2013 at 11:02 PM, Stephan Mueller <smueller at chronox.de> wrote:
> ...
> Interesting: I have the same type of discussion (SP800-90B) to prepare (and
> even went through it -- see [1]) and I do not see it that problematic, if you
> have the right hooks into your noise source implementation (and I could
> imagine that this is a challenge with the current RDSEED/RDRAND
> implementation).

one of the beautiful aspects of the RDRAND/RDSEED design is that
un-trusting consumers can use it concurrently without leaking any
useful information between them. consider multiple guest OS'es using
the instruction directly.

raw sampling of the sources would provide bias that _might_ be useful
to a malicious consumer attempting to compromise the entropy of other
processes or domains, if done naively.

this means that raw access to the entropy sources cannot just be
"turned on" without impact.  i appreciate the complexities involved.
there are solutions to this problem, of course, and it this effort
which i am continually agitating for.

we've gone over this  in parts; i'd love to see a comprehensive
"reference for cryptographically secure entropy" with explanations and
history around the myriad aspects of hardware entropy designs,
whiteners, compressors, digests/cipher generator state masking,
entropy estimation and sanity checks, proper seeding in kernel and
application pools, etc.



> I spoke with several NIST folks involved in the RNG process in September. And
> they are not ignorant. Therefore, I would not suggest that we imply anything
> here!

are there other organizations that might provide some weight to these
efforts?  IETF?


best regards,


More information about the cryptography mailing list