On Mon, Dec 2, 2013 at 11:02 PM, Stephan Mueller <[email protected]> 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, _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
