in 30c3: The Year in Crypto with djb, Nadia Heninger, Tanja Lange http://www.youtube.com/watch?v=Fty107Us7oc at ~28min discussion of RDRAND, Intel's pass the buck to NIST no-comment, (after initial "just trust us, we looked at a lab sample close" didn't fly far enough...) alt slides: hyperelliptic.org/tanja/vortraege/talk-30C3.pdf also, Tor 0.2.4.20 (Mon Dec 23 07:21:35 UTC 2013) updates to avoid direct RDRAND use in specific circumstances: https://lists.torproject.org/pipermail/tor-talk/2013-December/031483.html per previous discussion on OpenSSL use of RDRAND directly when engines on.[0] TL; DR - very rare case you may want to re-gen relay and hidden service keys now,, you may wonder if IETF could apply resistance to NSA seducing of NIST, but you'd be stepping into a quagmire :P http://arstechnica.com/security/2013/12/critics-nsa-agent-co-chairing-key-cr... http://www.ietf.org/mail-archive/web/cfrg/current/msg03554.html [specifically, all of Dan Harkins "appeals for legitimacy" bear striking resemblance to other demonstratively failed approaches to failure by default designs. Dragonfly is not sufficiently justified. insert pleas to appeal to decency and step away from CFRG and IETF authority roles for propriety sake, regardless of any reasonable claims or other implications best exemplified by RSA[1]] also,, SIMON and SPECK is lulz; no really: fuck those guys! and remember that AES GCM is a choice between: - user-land side channels galore /or/ - hardware instruction back-door . . 2013 was indeed a year for crypto let's not do this again soon? best regards, 0. "BADRAND and testing OpenSSL engines enabled behavior with direct RDRAND engine" https://peertech.org/goodrand BADRAND lets you link a test version of your application or library against OpenSSL 1.0.1e that uses a specific sequence of deterministic "random numbers" in OpenSSL. e.g. standard C lib function rand() seeded at zero replacing RDRAND. the debug logging to stderr can identify bad fork() assumptions. 1. Dual-EC-DRBG is bad and RSA should feel bad. No excuses. https://gist.github.com/0xabad1dea/8101758 IETF standards not a good reference for "formal proof" level thoroughness, and highly deployed does not mean highly used nor scrutinized (WEP, LEAP, OpenSSL's Dual_EC_DRBG implementation, [the set is large]) X. "see that one top post ..." [was: RDRAND used directly when... On Sat, Dec 14, 2013 at 4:33 AM, coderman wrote:

as per the FreeBSD announcement[0] and others[1][2] direct use of RDRAND as sole entropy source is not recommended...