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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Sun, 29 Dec 2013 02:19:23 -0800
From: coderman <coderman@...il.com>
To: Full Disclosure <full-disclosure@...ts.grok.org.uk>,
 cpunks <cypherpunks@...nks.org>
Subject: 30c3: The Year in Crypto default engines loaded
 in openssl-1.x through openssl-1.0.1e]

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@...il.com> wrote:
> as per the FreeBSD announcement[0] and others[1][2] direct use of
> RDRAND as sole entropy source is not recommended...

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/