30c3: The Year in Crypto default engines loaded in openssl-1.x through openssl-1.0.1e]

[coderman]

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-crypto-standards-body-should-be-removed/
  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 <coderman at gmail.com> wrote:
> as per the FreeBSD announcement[0] and others[1][2] direct use of
> RDRAND as sole entropy source is not recommended...