NSA and IETF, Part 9

(cr.yp.to)

44 points | by libroot 6 hours ago

6 comments

  • philodeon 4 hours ago
    I enjoyed the @tptacek cameo. I suspect tptacek didn’t.
    • tptacek 3 hours ago
      He didn't publicly call me an NSA shill, so I got off pretty easy. Obviously, I stand by what I said. I think it would be an understatement to suggest support for what Bernstein is arguing is a minority cause among cryptographers.
      • directoron 3 hours ago
        The argument from Roberto Avanzi is reasonable: "as a codesigner of ML-KEM myself I would not trust using it exclusively: what if it gets broken mathematically and in the classical computational model (I.e. non-quantum)? Hybrid is better, and the additional time used by ECC is not significant."
        • tptacek 3 hours ago
          A majority (but not a large majority) of cryptography engineers would use hybrids at this point, and hybrids are largely the default design for any mainstream deployment. Bernstein argument isn't "use hybrids, not pure MLKEM"; it's "MLKEM is so dangerous there shouldn't even be an informational standard saying how to use it". That's a problem, because there are non-mainstream deployment environments where you can't use hybrids.

          Obviously, Bernstein is counting on you not following that level of nuance; he'd much rather you believe he's arguing for hybrids against people who are trying to exterminate hybrids.

          For clarity: I am not a cryptographer; I'm a vulnerability researcher who does some cryptography work and for several reasons I talk to a lot of academic cryptographers and cryptography engineers. You could not pay me to design a PQC transport protocol for you.

          • fwlr 2 hours ago
            I haven’t read much of the for or against, so it’s certainly possible there’s a whole hidden web of ulterior motives at play here that I’m unaware of (rather than just “there’s a lot of pre-existing bad blood I’m unaware of, which is why both sides are snippy and pedantic”), but I feel compelled to object to this “nuance” point you make. The argument I see being made is “there is NSA pressure to document standalone MLKEM, so that there can be NSA pressure to adopt standalone MLKEM”, which seems fairly straightforward and without nuance to me.
            • tptacek 2 hours ago
              Just so we're clear, you're acknowledging that this argument hinges on the idea that documenting pure MLKEM is dangerous because, once it's documented in an (informational, optional) RFC, but only if it's documented in an RFC, NSA will pressure people to adopt it.
              • timschmidt 2 hours ago
                You're working real hard here to misunderstand his point and ignore historically relevant actions by NSA which have weakened and introduced attack vectors into previous standards, facilitating their adoption by orgs worldwide.
              • fwlr 2 hours ago
                Absolutely, that’s more or less exactly what I took away from it.
          • directoron 3 hours ago
            Yes, the argument is MLKEM is so dangerous that it shouldn't be used alone. Even its codesigner says so. Why is it so hard to accept?

            Take a look at the crypto from the 80's and 90's. They are considered bad jokes nowadays, badly designed and easily breakable. Why would the first-generation PQC algorithms be any different? Of course they're going to be broken and ridiculed in 20 years, in ways you cannot comprehend yet

            • tptacek 3 hours ago
              I feel like what's most likely happening here, given your initial argument, is that you just learned that this is a debate about whether it should be forbidden to even document a particular MLKEM configuration, and you're now working backwards to the proposition that Bernstein is right.

              To that I will only add that lattice cryptography is of approximately the same vintage as elliptic curve (both started in the late 1990s) and MLKEM is past the level of maturity relative to lattices that 25519 was relative to the original P-curves. (Correct me where I'm wrong here --- this is off the top of my head). This isn't "the first generation" of anything.

              Just another nuance I think Bernstein is counting on you, the real audience for these posts, not having any intuition for.

              • directoron 3 hours ago
                That's a weak ad hominem deflection. Readers be the judge.
                • tptacek 3 hours ago
                  In addition to noticing that your argument had moved goalposts (the part you claim is an ad hominem, but is not) I also responded substantively to a factual claim you made, and you're pretending otherwise.
          • rasengan 1 hour ago
            > A majority (but not a large majority) of cryptography engineers would use hybrids at this point

            Actually, based on the WGLC, or the three of them rather, it's pretty clear that Ph.D cryptographers significantly prefer hybrid over pure ML-KEM.

            > he'd much rather you believe he's arguing for hybrids against people who are trying to exterminate hybrids.

            The brigade by the NSA (6+ votes or more if you include NSA contractors), the AD being former NSA and the moderation of Dr. Bernstein for a footnote seems pretty fair and balanced </sic>.

            Meanwhile, the lead of the EU PQC program, professors from several universities, Ph.Ds and, additionally, legendary cryptographers all expressed significant concern and even stronger opposition to the publishing of the draft.

            Finally, the chairs refused to share their methodology in determining consensus when asked by several Professors and Ph.Ds.

            • tptacek 1 hour ago
              The legendary cryptographer that isn't Orr Dunkelman that you're referring to would be...?

              What's noteworthy about the last list of sponsors of his position that Dan Bernstein posted was how few of them were cryptographers.

              • rasengan 43 minutes ago
                > Orr Dunkelman

                The great Dr. Orr Dunkelman was admirably vocal in his opposition to the publishing of this draft.

      • cassonmars 3 hours ago
        Are you a cryptographer?

        I am. I literally hold six patents around secure key generation and management. I stand by DJB's points.

        • tptacek 3 hours ago
          Amazing. Six patents! I sign literally everything I write here with my own name, so it's pretty easy to find out my background.
      • eis 3 hours ago
        I'm confused by your messages linked by DJB. You say that better cryptographers would not choose hybrids, which seems to say that you should indeed think that hybrids are not a good choice. Then you say you are not such a good cryptographer and would choose a hybrid. But if you know that more senior cryptographers think they are not the right choice then why choose them anyways? Or am I misreading "cryptography-literate" here?

        Can you explain a bit more regarding your statement that DJB's POV on the matter has no broad support amongst his peers? I'm not in the field but Bernstein seemed like a highly respected member with a long track record in the crypto community, at least from the outside. Do you think the community is wrong or is it DJB who's wrong and why? There's also a good chance that I totally missed the argument being made.

        • tptacek 3 hours ago
          I can think of several academic cryptographers (or rather, practitioners with doctorates) who think the hybrid/pure thing is silly. I didn't claim that a majority oppose hybrids. The point of the message he snipped from the HN thread is that pure MLKEM is not considered an unserious design by actual cryptographers (people on the HN thread --- generally not cryptographers, like me --- think it is). Cryptography engineers tend to default to hybrids.

          Downthread we develop more clarity about what it is Bernstein is actually in an argument about. It isn't hybrids vs. pure!

    • cassonmars 3 hours ago
      frankly every time this topic comes up he's quick to try to spread disinformation on djb's posts, so it's about time he got mentioned
      • timschmidt 2 hours ago
        Every. Single. Time. And vehemently. Like clockwork, or a job.
        • philodeon 2 hours ago
          tptacek once adored djb. This changed around 2015-2016, when one of tptacek’s crypto acquaintances lost a grad school spot (studying under djb) to Jacob Appelbaum. This led her and a couple of her friends to accuse Appelbaum of sexual assault and grape.

          tptacek wants to be seen as a good feminist ally because his feminist wife would castrate him otherwise. So, he #BelievedWomen, and part of that is making sure you shun the unbelievers. Thus, djb is to be criticized by tptacek at every opportunity.

          • tptacek 2 hours ago
            I have no idea what the fuck you're talking about here but nobody "lost a grad school spot" to Jacob Appelbaum.

            It is true that I was once a Bernstein stan. He's generally been nothing but nice to me. But then I met other cryptographers.

            • philodeon 2 hours ago
              Quoting https://archive.fo/3QWJF#selection-801.0-805.168

              “Als Appelbaum im September 2015 an der Technischen Universität Eindhoven ein Doktorandenprogramm beginnt, ist auch sie interessiert. Für Appelbaum ist die Universitätsstelle in Eindhoven auch eine existentielle Stütze, falls er, nach den Vorwürfen im März in Valencia, seine Arbeit beim Tor-Projekt nicht fortsetzen kann. Lovecruft versucht schließlich, bei den selben Professoren wie Appelbaum angenommen zu werden. Am Ende wird ihr das nicht gelingen. Ein anderer Mensch wird jedoch das Büro beziehen, das direkt neben Appelbaums liegt. Es ist der Lebenspartner von Isis Agora Lovecruft oder einer ihrer Lebenspartner, das ist nicht klar. Dieser Mann wird später Arbeiten von Appelbaum bewerten, deren Ergebnisse für dessen Vorankommen in der Universität wichtig sind. Im Januar 2016, kurz nachdem sie an der Universität in Eindhoven abgelehnt wird, beteiligt sich Isis Agora Lovecruft daran, Geschichten zu sammeln über Jacob Appelbaum.”

              • tptacek 2 hours ago
                The person this is about is not an acquaintance of mine. I have no idea if they applied or didn't apply. The person I've spoken to --- am acquainted with (though not personal friends with) is Henry de Valence, who obviously did not lose a spot in Bernstein's lab to Appelbaum.

                These are all incredibly creepy and inappropriate accusations for you to be making. They're also wildly against the site guidelines.

                • philodeon 2 hours ago
                  Henry de Valence is the person mentioned in that quote as having moved in next door to Appelbaum, as documented by djb:

                  https://eindhoven.cr.yp.to/false-statements-by-henry-de-vale...

                • timschmidt 2 hours ago
                  No creepier than the way you're in every one of these threads argument-botting djb. The co-designer of ML-KEM can steelman DJB's point, despite his very personal involvement. Which causes folks to question why your reactions would be so much stronger than those of the directly involved. You blame folks for looking for reasons?

                  If you don't want people to question your motivations, don't behave like someone with questionable motivation. Seems simple.

  • ifh-hn 2 hours ago
    Can someone ELI5 what the issue is here? I feel like I'm missing a lot of nuance here. Are the NSA people attempting to weaken TLS by removing ECC?
    • tptacek 2 hours ago
      No. This whole situation is extremely dumb.

      Bernstein is a co-author on NIST PQC competition submissions that didn't win (Classic McEliece, which just had a huge new research result, and Streamlined NTRU Prime, a lattice cousin to MLKEM).

      When CRYSTALS/Kyber was selected in the NIST competition instead of SNTRUP, Bernstein didn't take it well. He claimed malfeasance by NIST and sued them for allegedly hiding documents.

      Meanwhile, over the subsequent years, the world has continued turning on its axes. CRYSTALS/Kyber is now ML-KEM. Because many cryptography engineers and other security people think there's a lot of urgency to getting PQC deployed (because of harvest-now decrypt-later [HNDL] attacks), the IETF got a move on standardizing hybrid ECDH/MLKEM TLS 1.3, which is what everyone uses.

      Nobody at IETF has ever to my knowledge even hinted that anyone should avoid hybrids. There is a standards-track RFC defining ECDH/ML-KEM hybrids.

      There are environments where hybrids are problematic. You won't likely use any of them ever. Some of them occur within the US Government, and some of them are on highly constrained platforms (people seem to disbelieve this is ever really a thing but I once gameovered a smart meter because its RF protocol only had like 16 bits of counter space for CTR).

      Because of this, there is also a proposed informational RFC --- not a standards track document --- that documents what pure MLKEM looks like in a TLS 1.3 setting. Bernstein's entire argument is that this is an NSA plot.

    • rasengan 48 minutes ago
      RFCs are used by developers as strict guidelines for implementation.

      The mere publishing of an RFC has customarily been treated by developers as a stamp of approval from the IETF.

      The NSA, contractors and their fans argue that simply adding a "RECOMMENDED=N" in an obscure section of this draft will somehow prevent said implementations in deployments.

      However, as an example, Canada's NSA equivalent specifically requested the draft to be published so that they can use it to support their poor choice in deployment of solo ML-KEM nation-wide.

      While ML-KEM may be sound, significant bugs in implementations in the wild continue to be published.

      To be clear, CRQCs do not exist today.

      ECC is battle tested, proven, and is used today.

      It makes no sense to delete working cryptography and replace it with potentially buggy, non-battle tested implementations of new cryptography for a threat that does not yet exist today.

      Instead, you fight HNDL [1] with hybrid which preserves the safety of today, and hopefully also, tomorrow.

      No serious security person should be recommending otherwise which is, perhaps, why some may question the motives of those that are pushing for solo ML-KEM.

      [1] Harvest now decrypt later

  • stackghost 4 hours ago
    It's never been clear to me why NSA's "blue team" directorates haven't been spun off into a separate agency. Sure, NSA strengthened the S-boxes in DES and SHA-1 but from the outside there's no way to know whether they're making DES stronger against differential cryptanalysis or whether they're introducing a DUAL_EC-style vulnerability.

    I'm sure there's a game-theoretic optimum choice when it comes to accepting proposals from the NSA vs rejecting them out of hand, but I'm not sure what that optimal choice is.

    • philodeon 4 hours ago
    • libroot 1 hour ago
      Imo "the optimal choice" is to be extremely skeptical to what comes to NSA proposing anything related to encryption/cryptography. From the first part of this blog series by DJB[1]:

      > Try to put yourself in the mindset of NSA as an attacker. You have a massive budget to "covertly influence and/or overtly leverage" systems to "make the systems in question exploitable"; "to the consumer and other adversaries, however, the systems' security remains intact". One of your action items is to "influence policies, standards and specification for commercial public key technologies". Another is to "shape the worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS".

      And when you read the Snowden docs and you come across to things like this 2010 GCHQ presentation[2], stating "for the past decade, NSA has lead an aggressive, multipronged effort to break widely used Internet encryption technologies" such as "SSL" and "SSH" and "VPNs"; that "cryptanalytic capabilities are now coming on line"; and that "vast amounts of encrypted Internet data which have up till now been discarded are now exploitable."

      So we have these agencies like NSA and GCHQ, with stated, funded programs to make deployed cryptography exploitable (and historical evidence of them successfully doing just that)... It's an unbelievable conflict of interest for them to hold any role where they can shape what gets deployed. Absolutely bonkers.

      And on DES specifically, it was both at once, not a binary. NSA in secret pushed IBM to cut the key size, while strengthening the algo against every attack except brute force. The design criteria were classified and IBM's own research docs were literally locked up under gov classification at NSA's request meanwhile when IBM personnel publicly denied any NSA involvement (and the NSA director publicly denied any algo weakening, again, a lie). So DES came out genuinely hardened against differential cryptanalysis but at the same time breakable by brute force by organizations with budgets like NSA's, by NSA's request/order.

      For the "blue team" thing.. I guess it's actually better for them tactically to not spin off, because being NSA gives you authority in those circles. Standards bodies don't seem to treat the conflict of interest as a problem (as we can see), but rather as a qualification ("people who know cryptography best").

      1: https://blog.cr.yp.to/20251004-weakened.html 2: https://web.archive.org/web/20240420184725if_/https://cdn.pr...

  • alfiedotwtf 2 hours ago
    I thought this was going to be rehashing of the old NULL-cypher IPsec thread, but it’s a different thing.

    Maybe we should treat standards like we do a free market - let anyone implement what they choose then let people chose which to adopt, but the main thing is get government out of the entire process.

    If the government wants to standardise, that’s fine… just don’t make it an industry standard adopted by civilians. Let them have their weakened protocols will the market moves on

  • jauntywundrkind 4 hours ago
    > I'm happy to report that 82 people spoke up on the TLS mailing list in unambiguous opposition to this spec during the voting period

    How many of them spoke before on this mailing list, in any capacity what so ever? I suspect this is 99% people who showed up because you organized a brigadging, because you incited people and told them to show up and be completely outraged.

    There's a >0% chance that DJB could be correct that there is some risk to this spec (which notably is not seeking recommendation status! So WTF?) The people approving and wanting this aren't fools, aren't lackies, aren't some great foe. There's little real opposition? Making up ghosts and enemies lurking in every corner, brigading people to show up in IETF meetings, who have never participated before, just to spread heat and anger you've programmed them for, is ignoble & indecent.

    All too recently: https://news.ycombinator.com/item?id=48760490 https://news.ycombinator.com/item?id=48811887

    • cornstalks 4 hours ago
      > which notably is not seeking recommendation status!

      I don’t have a dog in this fight, but some extremely important RFCs are only on the “informational” track. RFCs 1945 (HTTP 1.0), 4627 (JSON), 2818 (HTTPS), etc.

      • tptacek 3 hours ago
        HTTP, JSON, and HTTPS all have standards-track RFCs.
        • cornstalks 2 hours ago
          As far as I know HTTP 1.0 doesn't have a standards-track RFC (HTTP 1.1 and later do). JSON and HTTPS do indeed have standards-track RFCs, but I stand by my original wording that their first informational RFCs were "extremely important."
    • cassonmars 3 hours ago
      because the NSA has never surreptitiously pushed bad standards they used to exploit before

      /s

      • tptacek 3 hours ago
        Which PQC standard are you suggesting they pushed, and how did they push it? Flesh the argument out.
        • vlovich123 3 hours ago
          That’s a very unfair position to take when dealing with secret agencies who try very hard to obfuscate this stuff - it is hard to provide evidence for in the moment.

          The government has intentionally acted to weaken DES, standardized Dual_EC_DRBG, performed subtle subterfuge through interfering how NIST operates to inject weaknesses and vulnerabilities, trying to weaken SSL and IPSec, 4G smartphone encryption.

          These are all documented examples of the NSA engaging in bad faith. So whether or not it is happening in this particular case, there’s now just zero trust in the institutions acting in good faith. And given it took decades for the actions to come out after they were taken, how do you expect someone to answer your request to present evidence there’s anything nefarious happening now?

          Anyway, that’s what I think a fleshed out argument would look like

          • tptacek 3 hours ago
            It's a simple question. I'm not asking anybody to prove anything. I'm literally asking: propose the PQC standard IETF could have subverted, and give a sketch of how they could have done it. The bar is merely "plausibility". I'm not asking whether NSA has subverted standards before; obviously they have.

            NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since.

            • vlovich123 2 hours ago
              They did both - they strengthened it from differential integrity but weakened it by picking a known-to-be-too-short key length. Meaning they had the compute power to crack it but others couldn’t do the same through pure algorithmic means.

              As for your post below

              > it can't be that NSA simply knows a vulnerability that impacts one very specific lattice scheme and not the others

              Ok. My argument is they know all lattice schemes are weak and the push to use a lattice-only scheme is precisely to have a cryptographic mechanism they can easily bypass without a classical known-secure backstop.

              • tptacek 2 hours ago
                See, here's another argument that doesn't work here, because Bernstein very publicly backs a different lattice cryptography scheme.

                In addition to the previously-stated reason why that argument is inoperative (besides being unfalsifiable, it admits a strategy where NSA "poisons the well" to get people to avoid a particular construction or family of algorithms, so that we all move to weaker ones --- a counterfactual that should be much more vivid after what was released this week!)

            • Vecr 3 hours ago
              > NSA, by the way, rescued DES from differential cryptography, the core mechanism by which block ciphers and hash functions have been attacked ever since

              That's why you use ML-KEM 1024 at all... As part of a hybrid.

              • tptacek 3 hours ago
                I don't know what this is, but it isn't an answer to the question. I'm starting to notice that nobody is able to come up with an answer.
                • Vecr 2 hours ago
                  There is no public reason to think that 1024 is better than 768, or DJB's S-NTRU-P 761. The NSA might know something, but we can't trust them. So, use a hybrid, in case they are really just trying to protect us.
                  • tptacek 2 hours ago
                    That can't be the argument --- it can't be that NSA simply knows a vulnerability that impacts one very specific lattice scheme and not the others. The reason for that is a cryptographic concept known as the Vizzini Conjecture: the argument you just put forward can be applied to literally any cryptographic standard NIST authors. Since NSA knows that, and knows you know it, you can clearly not choose the wine in front of you. It must be that the standard NIST picks is the only secure one, so that NSA can see it tainted by NIST association.

                    But yes, this is the useful conversation to have. There are other scenarios! You can get into more detail on where MLKEM came from, for instance.

                    • Vecr 2 hours ago
                      Yes, they trick me and I pick the poisoned wine... But wait, no, I used a hybrid. Imagine the code can't be backdoored (it's proven not to crash/be slow/be exploitable) so at worst it can make the security no better. At best, the NSA knows a whole new subfield of cryptography (from history: differential cryptanalysis) and it really is more secure.

                      They laugh at us while we try to think of how 1024 is better than 768: "bigger is better, right?" "does 1024 refer to the number of years it takes Nightmare Moon to break the code?"

                      • tptacek 2 hours ago
                        There is nobody at IETF saying you shouldn't use a hybrid! In fact, it's the exact opposite: hybrid ECDH/MLKEM is a standards-track RFC, and the proposed pure-MLKEM RFC is not, nor is it "Recommended" (in IETF parlance).

                        Let's keep the thread coherent: the original claim, by cryptographer 'cassonmars, is that the issue here is NSA pushing bad standards. It's not "hybrid vs. pure", which is a non-issue. All I asked for was a plausible story about how NSA might have pushed a bad PQC standard.

                        • philodeon 2 hours ago
                          No, the original claim was by me. And I gave you a plausible story. You just didn’t want to hear it.

                          https://news.ycombinator.com/item?id=48820336

                          • tptacek 2 hours ago
                            This is a link to a comment from 38 days ago.
                        • Vecr 2 hours ago
                          > Let's keep the thread coherent: the original claim

                          How do you save your poisoned wine? A hybrid with 1024 is made less trustworthy if the NSA pushes 1024 alone, since then we know that they want customers to use 1024 alone, which is what they would want if it was weak. But they know that we would know that, so if they really want to help us they should withdraw the draft. If it was strong but we know why, they shouldn't want to make us doubt ourselves. If it is strong (and 512 and 768 are not) they can't tell us, and can only subtly point to their own double encryption and security level documents. The only move that can cover all the cases is a hybrid with 1024, so this draft is a bad standard.

  • timschmidt 2 hours ago
    Brings to mind this lovely quote from the Snowden documents:

    “The road to developing this standard was smooth once the journey began... However, beginning the journey was a challenge in finesse ... After some behind-the-scenes finessing with the head of the Canadian national delegation and with C.S.E., the stage was set for N.S.A. to submit a rewrite of the draft ... Eventually, N.S.A. became the sole editor.”

    https://macleans.ca/society/technology/nsa-says-it-finessed-...