D. J. Bernstein wrote: > More recently, NSA's Dickie George is on video claiming that NSA generated > the Dual EC points randomly and that Dual EC is secure.
Do you have a link to the video? Such a comment is surprising as it is a very bad PR strategy. “No comment” is a far better strategy. This is what I found: https://www.youtube.com/watch?v=qq-LCyRp6bU <https://www.youtube.com/watch?v=qq-LCyRp6bU> IMHO, it’s quite an interesting talk. Dual EC_DRBG is discussed between time-marks 30:00 – 34:00. The last comment I saw was: "With hindsight, NSA should have ceased supporting the Dual EC DRBG algorithm immediately after security researchers discovered the potential for a trapdoor. In truth, I can think of no better way to describe our failure to drop support for the Dual EC DRBG algorithm as anything other than regrettable." https://www.ams.org/journals/notices/201502/rnoti-p165.pdf <https://www.ams.org/journals/notices/201502/rnoti-p165.pdf> I didn’t dive into the EC_DRBG scandal (had more interesting things to deal with). But I seem to recall that NIST and ANSI standards allowed verifiable random point generation (from the publication you cited), so there was no need to use the NSA random points, unless you were building devices for NSA: During the development of the ANSI standard based on the NIST publication, members of X9F1 (the ANSI-approved working group responsible for cryptographic tools) raised concerns about the potential that elliptic curve points used as parameters for the Dual EC_DRBG could harbor a trapdoor secret known only to, and exploitable only by, the person who generated the points. As a result, the X9F1 committee expanded the standard to include verifiable random point generation. Since the NSA was using the algorithm at the time and had generated elliptic curve points for protecting Department of Defense users, the NSA-generated points were included in the standard. In other words, any implementation that used the NSA-generated points would be deemed compliant. Shortly thereafter, NIST negotiated with ANSI to use the ANSI Random Number Generation Standard as the basis for an NIST Random Number Generation Standard. ANSI also approved submitting a version of this standard to the ISO. I think it is good with increased participation from government agencies in the IETF. Suite B, CNSA 1.0, and ZTA are all very good recommendations from NSA, significantly surpassing what was typical in deployments at the time they were introduced. We would not be prepared for PQC if it was not for the NSA. https://web.archive.org/web/20150831131731/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml <https://web.archive.org/web/20150831131731/https:/www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml> Concur 100%. IMHO, CNSA 2.0 is also pretty good – except that I’d rather see a DSA with smaller signature and public key sizes (e.g., like HAWK?). Well, maybe CNSA 2.x would include that. (And I’m not crazy about LMS/XMSS, but that’s me – I hate stateful signatures 😉).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
