Blumenthal, Uri wrote: >This is what I found: 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. Very interesting indeed... That Dual EC_DRBG was used in classified systems before being standardized could make sense. Government systems often has intercept as a feature. But Dual EC_DRBG was still designed for intercept.
Blumenthal, Uri wrote: >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: Yes, but nobody did use any other points except the hostile nation state that backdoored the backdoor and used it to attack critical infrastructure in the US. It is a fact that many SIGINT agencies globally are trying to weaken security to enable intercept. It is excellent that Dan is constantly putting light on this fact. A sad effect of SIGINT weakening security is that it enables and encourages attacks from hostile nation states on critical infrastructure. The Dual EC_DRBG backdoor was quickly backdoored by a hostile nation state. https://blog.cryptographyengineering.com/2015/12/22/on-juniper-backdoor/ The lack of PFS in AKA has led to massive attacks on SIM card vendors and mobile operator databases. The keys are then used to passively and at scale eavesdrop on phone calls. SIGINT has actively been fighting introduction of PFS in AKA. https://theintercept.com/2015/02/19/great-sim-heist/ The lack of e2e security and acceptable security protocols for phone calls encourages attacks by hostile nation states on critical infrastructure. The latest, but not first or last, example is the Salt Typhoon attack on the US. SIGINT has actively been fighting e2e and good security for phone calls. I hope Salt Typhoon will be a wakeup call. https://www.washingtonpost.com/national-security/2024/10/11/china-hack-telecoms-salt-typhoon/ But be warned that many companies are selling "privacy theater" https://propertyofthepeople.org/document-detail/?doc-id=21114562 https://edition.cnn.com/2024/01/12/tech/china-apple-airdrop-user-encryption-vulnerability-hnk-intl/index.html https://www.wired.com/story/google-floc-age-privacy-theater/ Blumenthal, Uri wrote: >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 😉). I intentionally left out CNSA 2.0 as it is not a recommendation significantly surpassing what was typical in deployments at the time they were introduced. Stateful signatures are hard to recommend, best practice is to hybridize structured lattices, SHA-3 is technically superior to SHA-2, and AES-256 does not provides state-of-the-art security. From: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> Date: Sunday, 15 December 2024 at 05:44 To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>, tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement 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 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 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 😉).
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
