11 ms·

NSA and IETF, part 3: Dodging the issues at hand

316 points by upofadown 11mo ago

g-mork 11mo ago
Handforth Parish council Internet edition. You have no authority here, djb! No authority at all
ants_everywhere 11mo ago
D. J. Bernstein is very well respected and for very good reason. And I don't have firsthand knowledge of the background here, but the blog posts about the incident have been written in a kind of weird voice that make me feel like I'm reading about the US Government suppressing evidence of Bigfoot or something. Stuff like this > Wow, look at that: "due process".... Could it possibly be that the people writing the law were thinking through how standardization processes could be abused?" is both accusing the other party of bad faith and also heavily using sarcasm, which is a sort of performative bad faith. Sarcasm can be really effective when used well. But when a post is dripping with sarcasm and accusing others of bad faith it comes off as hiding a weak position behind contempt. I don't know if this is just how DJB writes, or if he's adopting this voice because he thinks it's what the internet wants to see right now. Personally, I would prefer a style where he says only what he means without irony and expresses his feelings directly. If showing contempt is essential to the piece, then the Linus Torvalds style of explicit theatrical contempt is probably preferable, at least to me. I understand others may feel differently. The style just gives me crackpot vibes and that may color reception of the blog posts to people who don't know DJT's reputation.
- jonstewart 11mo ago
  He’s smart and prolific, for sure, but I lost respect for him several years ago.
  - johnisgood 11mo ago
    Why, if I might respectfully ask?
    - jonstewart 11mo ago
      Sure! First, while I’m in no position to judge cryptographic algorithms, the success of cha-cha and 25519 speak for themselves. More prosaically, patriecia/critbit trees and his other tools are the right thing, and foresighted. He’s not just smart, but also prolific. However, he’s left a wake of combative controversy his entire career, of the “crackpot” type the parent comment notes, and at some point it’d be worth his asking, AITA? Second, his unconditional support of Jacob Appelbaum has been bonkers. He’s obviously smart and uncompromising but, despite having been in the right on some issues, his scorched earth approach/lack of judgment seems to have turned his paranoia about everyone being out to get him into a self-fulfilling prophecy.
      - johnisgood 11mo ago
        I do not understand your last paragraph. :/
        mpyne 11mo ago
        https://medium.com/@hdevalence/when-hell-kept-on-payroll-somewhere-is-where-you-are-f419d3022d0 https://medium.com/@hdevalence/when-hell-kept-on-payroll-som...
        cryptonector 11mo ago
        Thank you! I had no idea.
        philodeon 11mo ago
        That article is pure horsecrap: https://eindhoven.cr.yp.to/false-statements-by-henry-de-valence.txt https://eindhoven.cr.yp.to/false-statements-by-henry-de-vale...
        tptacek 11mo ago
        Because Bernstein says so?
- amiga386 11mo ago
  It's very simple. ECC is well understood and has not been broken over many years. ML-KEM is new, and hasn't had the same scrutiny as ECC. It's possible that the NSA already knows how to break this, and has chosen not to tell us, and NIST plays the useful idiot. NIST has played the useful idiot before, when it promoted Dual_EC_DRBG, and the US government paid RSA to make it the default CSPRNG in their crypto libraries for everyone else... but eventually word got out that it's almost certainly an NSA NOBUS special, and everyone started disabling it. Knowing all that, and planning for a future where quantum computers might defeat ECC -- it's not defeated yet, and nobody knows when in the future that might happen... would you choose: Option A): encrypt key exchange with ECC and the new unproven algorithm Option B): throw out ECC and just use the new unproven algorithm NIST tells you option B is for the best. NIST told you to use Dual_EC_DRBG. W3C adopted EME at the behest of Microsoft, Google and Netflix. Microsoft told you OOXML is a valid international standard you should use instead of OpenDocument (and it just so happens that only one piece of software, made by Microsoft, correctly reads and writes OOXML). So it goes on. Standards organisations are very easily corruptable when its members are allowed to have conflicts of interest and politick and rules-lawyer the organisation into adopting their pet standards.
  - glenstein 11mo ago
    Thank you, that seems to be the whole ball game for me right there. I understood the sarcastic tone as kind of exasperation, but it means something in the context of an extremely concerning attempt to ram through a questionable algorithm that is not well understood and risks a version of an NSA backdoor, and the only real protection would be integrity of standards adoptions processes like this one. You've really got to stick with the substance over the tone to be able to follow the ball here. Everyone was losing their minds over GDPR introducing a potential back door to encrypted chat apps that security agencies could access. This goes to the exact same category of concern, and as you note it has precedent! So yeah, NSA potentially sneaking a backdoor into an approved standard is pretty outrageous, and worth objecting to in strongest terms, and when that risk is present it should be subjected to the highest conceiveable standard of scrutiny. In fact, I found this to be the strongest point in the article - there's any number of alternatives that might (1) prove easier to implement, (2) prove more resilient to future attacks (3) turn out to be the most efficient. Just because you want to do something in the future doesn't mean it needs to be ML-KEM specifically, and the idea of throwing out ECC is almost completely inexplicable unless you're the NSA and you can't break it and you're trying to propose a new standard that doesn't include it. How is that not a hair on fire level concern?
- cryptonector 11mo ago
  > I don't know if this is just how DJB writes, He's caustic, but often right.
philipwhiuk 11mo ago
[flagged]
- 6581 11mo ago
  That's not what the message you linked claims at all. Maybe you missed the "in this message" at the end of the sentence?
  - philipwhiuk 11mo ago
    No not really - I don’t think choosing to post from an alternative email removes the association issue that the original intent is trying to capture.
- amszmidt 11mo ago
  ”No association” and “I am not a representative” are quite different things to say.
  - philipwhiuk 11mo ago
    [flagged]
    - amszmidt 11mo ago
      An employee doesn’t act as an official representative of their employer nor do they speak for the employee in any official capacity. That is what the message says. The informal also didn’t cloak their identity (implies some malicious intent), they simple did not use their work email. Nothing wrong with that.
    - conception 11mo ago
      I’m sorry, can you state which organization you are speaking for with this comment? It wasn’t immediately clear.
    - throw0101c 11mo ago
      [flagged]
throw0101a 11mo ago
Perhaps related: from 2022, on his (FOIA?) lawsuit against the government: * https://news.ycombinator.com/item?id=32360533 https://news.ycombinator.com/item?id=32360533 From 2023, "Debunking NIST's calculation of the Kyber-512 security level": * https://news.ycombinator.com/item?id=37756656 https://news.ycombinator.com/item?id=37756656
seethishat 11mo ago
For context, djb has been doing and saying these things since he was a college student: While a graduate student at the University of California at Berkeley, Bernstein completed the development of an encryption equation (an "algorithm") he calls "Snuffle." Bernstein wishes to publish a) the algorithm (b) a mathematical paper describing and explaining the algorithm and (c) the "source code" for a computer program that incorporates the algorithm. Bernstein also wishes to discuss these items at mathematical conferences, college classrooms and other open public meetings. The Arms Export Control Act and the International Traffic in Arms Regulations (the ITAR regulatory scheme) required Bernstein to submit his ideas about cryptography to the government for review, to register as an arms dealer, and to apply for and obtain from the government a license to publish his ideas. Failure to do so would result in severe civil and criminal penalties. Bernstein believes this is a violation of his First Amendment rights and has sued the government. After four years and one regulatory change, the Ninth Circuit Court of Appeals ruled that software source code was speech protected by the First Amendment and that the government's regulations preventing its publication were unconstitutional. Source https://www.eff.org/cases/bernstein-v-us-dept-justice https://www.eff.org/cases/bernstein-v-us-dept-justice
- deleted 11mo ago
  [deleted]
- basilgohar 11mo ago
  djb has earned my massive respect for how consistent he's been in this regard. I love his belligerence towards authoritarian overreach in this regard. Him, Phil Zimmermann, Richard Stallman, and all are owed great respect for their insistence on their principles which have paid massive dividends to all of us through the freedom and software that has been preserved and become possible through them. I appreciate them immensely and I think we all owe them a debt of gratitude for their sacrifices, because they all paid a heavy price for their advocacy over time.
  - tptacek 11mo ago
    That's the right pantheon, I think. Bernstein, Zimmerman, Stallman.
abhv 11mo ago
20+2 (conditional support) versus 7. 22/29 = 76% in some form of "yea" That feels like "rough consensus"
- jcranmer 11mo ago
  The standard used in the C and C++ committees is essentially a 2-to-1 majority in favor. I'm not aware of any committee where a 3-to-1 majority is insufficient to get an item to pass. DJB's argument that this isn't good enough would, by itself, be enough for me to route his objections to /dev/null; it's so tedious and snipey that it sours the quality of his other arguments by mere association. And overall, it gives the impression of someone who is more interested in derailing the entire process than in actually trying to craft a good standard.
  - vorpalhex 11mo ago
    We're talking about a landmine in a crypto spec and you're bikeshedding about consensus ratios. We should talk about the NSA designed landmine.
    - tptacek 11mo ago
      Have you implemented MLKEM? How well do you understand it?
  - pfortuny 11mo ago
    You are turning “consensus” into “majority” and those it not the same.
    - jcranmer 11mo ago
      There was a recent discussion within the C committee over what exactly constituted consensus owing to a borderline vote that was surprisingly ruled "no consensus" (and the gravitas of the discussion was over the difference between a "no" and an "abstain" vote for consensus purposes). The decision was that it had to be a ⅔ favor/(favor + against), and ¾ (favor + neutral) / (favor + against + neutral). These are the actual rules of the committee now for determining consensus. Similar rules exist for the C++ committee. If there is any conflation going on, I am not the one doing it.
John-Tony 11mo ago
[dead]
daedlanth 11mo ago
[dead]
dhx 11mo ago
Amongst the numerous reasons why you _don't_ want to rush into implementing new algorithms is even the _reference implementation_ (and most other early implementations) for Kyber/ML-KEM included multiple timing side channel vulnerabilities that allowed for key recovery.[1][2] djb has been consistent in view for decades that cryptography standards need to consider the foolproofness of implementation so that a minor implementation mistake specific to timing of specific instructions on specific CPU architectures, or specific compiler optimisations, etc doesn't break the implementation. See for example the many problems of NIST P-224/P-256/P-384 ECC curves which djb has been instrumental in fixing through widespread deployment of X25519.[3][4][5] [1] https://cryspen.com/post/ml-kem-implementation/ https://cryspen.com/post/ml-kem-implementation/ [2] https://kyberslash.cr.yp.to/faq.html https://kyberslash.cr.yp.to/faq.html / https://kyberslash.cr.yp.to/libraries.html https://kyberslash.cr.yp.to/libraries.html [3] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Constant_time_Montgomery_ladder https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic... [4] https://safecurves.cr.yp.to/ladder.html https://safecurves.cr.yp.to/ladder.html [5] https://cr.yp.to/newelliptic/nistecc-20160106.pdf https://cr.yp.to/newelliptic/nistecc-20160106.pdf
- Foxboron 11mo ago
  > See for example the many problems of NIST P-224/P-256/P-384 ECC curves What are those problems exactly? The whitepaper from djb only makes vague claims about NSA being a malicious actor, but after ~20 years no known backdoors nor intentional weaknesses has been reliably proven?
  - supernetworks_ 11mo ago
    It would be wise for people to remember that it’s worth doing basic sanity checks before making claims like no backdoors from the NSA. strong encryption has been restricted historically so we had things like DES and 3DES and Crypto AG. In the modern internet age juniper has a bad time with this one https://www.wired.com/2013/09/nsa-backdoor/ https://www.wired.com/2013/09/nsa-backdoor/. Usually it’s really hard to distinguish intent, and so it’s possible to develop plausible deniability with committees. Their track record isn’t perfect. With WPA3 cryptographers warned about the known pitfall of standardizing a timing sensitive PAKE, and Harkin got it through anyway. Since it was a standard, the WiFi committee gladly selected it anyway, and then resulted in dragonbleed among other bugs. The techniques for hash2curve have patched that
zahllos 11mo ago
In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange. Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal Government) does not envisage using hybrid schemes. So there's some sense in having a standard for that purpose. Better developed through the IETF than forced on browser vendors directly by the US, I think. There was rough consensus to do this. Should we have a single-cipher kex standard for HQC too? I'd argue yes, and no the NSA don't propose to use it (unless they updated CNSA). The requirement of the NIST competition is that all standardized algorithms are both classical and PQ-resistant. Some have said in this thread that lattice crypto is relatively new, but it actually has quite some history, going back to Atjai in '97. If you want paranoia, there's always code theory based schemes going back to around '75. We don't know what we don't know, which is why there's HQC (code based) waiting on standardisation and an additional on-ramp for signatures, plus the expensive (size and sometimes statefulness) of hash-based options. So there's some argument that single-cipher is fine, and we have a whole set of alternative options. This particular overreaction appears to be yet another in a long running series of... disagreements with the entire NIST process, including "claims" around the security level of what we then called Kyber, insults to the NIST team's security level estimation in the form of suggesting they can't do basic arithmetic (given we can't factor anything bigger than 15 on a real quantum computer and we simply don't have hardware anywhere near breaking RSA, estimate is exactly what these are) and so on.
- aaomidi 11mo ago
  Except when the government starts then mandating a specific algorithm. And yes. This has happened. There’s a reason there’s only the NIST P Curves in the WebPKI world.
  - zahllos 11mo ago
    "The government" already have. That's what CNSA 2.0 means - this is the commercial crypto NSA recommend for the US Government and what will be in FIPS/CAVP/CMVP. ML-KEM-only for most key exchange. In this context, it is largely irrelevant whether the IETF chooses or not to have a single-standard draft. There's a code point from IANA to do this in TLS already and it will happen for US Government systems. I'd also add that personally I consider NIST P-Curves to be absolutely fine crypto. Complete formula exist, so it's possible to have failure-free ops, although point-on-curve needs to be checked. They don't come with the small-order subgroup problem of any Montgomery curve. ECDSA isn't great alone, the hedged variants from RFC 6979 and later drafts should be used. Since ML-KEM is key exchange, X25519 is very widely used in TLS unless you need to turn it off for FIPS. For the certificate side, the actual WebPKI, I'm going to say RSA wins out (still) (I think).
kiray 11mo ago
[flagged]
- Foxboron 11mo ago
  > This is why djb is in the Cypherpunks Hall of Fame! [1] This is a list made by you 2 weeks ago? EDIT: Okay lol. I actually browsed the list and found multiple dubious entries, along with Trump! Hilarious list. 10/10.
  - jonesjohnson 11mo ago
    what do you expect, when the tagline at the end of the page says "In crypto we trust."? Honestly, it's a bit sad. There are many great people on that list, but some seem a bit random and some are just straight up cryptobros, which makes the whole thing a joke, unfortunately
- anonym29 11mo ago
  Name calling, bullying (forms of systematic harassment) and attempting to instill feelings of social isolation in a target are documented techniques employed by intelligence agencies in both online and offline discourse manipulation / information warfare. You can read up more here if you are curious: https://www.statewatch.org/media/documents/news/2015/jun/behavioural-science-support-for-jtrigs-effects.pdf https://www.statewatch.org/media/documents/news/2015/jun/beh... Many of the attacks against djb line up quite nicely with "discredit" operational objectives.
  - webdoodle 11mo ago
    Bully and systematic harassment of cryptographers too build in backdoors too there encryption systems has been there go to strategy since the 80's.
  - timschmidt 11mo ago
    Don't forget the ever popular CIA Simple Sabotage Field Manual: https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...
0xbadcafebee 11mo ago
tl;dr DJB is trying to stop the NSA railroading bad crypto into TLS standards, the objections deadline is in two days, and they're stonewalling him This /. story fills in the backstory: https://it.slashdot.org/story/25/11/23/226258/cryptologist-djb-criticizes-push-to-finalize-non-hybrid-security-for-post-quantum-cryptography https://it.slashdot.org/story/25/11/23/226258/cryptologist-d... Normal practice in deploying post-quantum cryptography is to deploy ECC+PQ. IETF's TLS working group is standardizing ECC+PQ. But IETF management is also non-consensually ramming a particular NSA-driven document through the IETF process, a "non-hybrid" document that adds just PQ as another TLS option.
jancsika 11mo ago
Dear some seasoned cryptographer, Please ELI5: what is the argument for including the option for the non-hybrid option in this standard? Is it a good argument in your expert opinion? My pea brain: implementers plus options equals bad, newfangled minus entrenched equals bad, alice only trust option 1 but bob only have option 2 = my pea brain hurt!
- dwaite 11mo ago
  More of a person with IETF participation experience than as a cryptographer (I enjoy watching numbers dance but am not a choreographer): This ( https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ ) is a document describing how to use the ML-KEM algorithm with TLS 1.3 in an interoperable manner. It does not preclude other post-quantum algorithms from being described for use with TLS 1.3. It also does not preclude hybrid approaches from being used with TLS 1.3. It is however a document scoped so it cannot be expanded to include either of those things. Work to define interoperable use of other algorithms, including hybrid algorithms, would be in other documents. There is no MTI (mandatory-to-implement) once these are documented from the IETF directly, but there could be market and regulatory pressures. My suspicion is that this is bleed-out from a larger (and uglier) fight in the sister organization, the IRTF. There, the crypto forum research group (CFRG) has been having discussions on KEMs which have gotten significantly more heated. A person with concern that there may be weaknesses in a post quantum technique may want a hybrid option to provide additional security. They may then be concerned that standardization of non-hybrid options would discourage hybrid usage, where hybrid is not yet standardized and would likely be standardized later (or not at all). The pressure now with post quantum is to create key negotiation algorithms are not vulnerable to theoretical post quantum computer attack. This is because of the risk of potentially valuable encrypted traffic being logged now in the hopes that it could later be targeted by a post-quantum computer. Non-negotiated encrypted (e.g. just using a static AES key) is already safe, and signature algorithms can be updated much closer to viable attacks to protect transactional data.
  - ekr____ 11mo ago
    > It is however a document scoped so it cannot be expanded to include either of those things. Work to define interoperable use of other algorithms, including hybrid algorithms, would be in other documents. FYI, the specification for hybrid MLKEM + ECC is ahead of this document in the publication process. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
GauntletWizard 11mo ago
The NSA has railroaded bad crypto before [1]. The correct answer is to just ignore it, to say "okay, this is the NSA's preferred backdoored crypto standard, and none of our actual implementations will support it." It is not acceptable for the government to be forcing bad crypto down our throats, it is not acceptable for the NSA to be poisoning the well this way, but for all I respect DJB, they are "playing the game" and 20 to 7 is consensus. [1] https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG
pverheggen 11mo ago
While it's true that six others unequivocally opposed adoption, we don't know how many of those oppose the chairs claiming they have consensus. This may be a normal ratio to move forward with adoption, you'd have to look at past IETF proceeding to get a sense for that. One other factor which comes in to play, some people can't stand his communication style. When disagreed with, he tends to dig in his heels and write lengthly responses that question people's motives, like in this blog post and others. Accusing the chairs of corruption may have influenced how seriously his complaint was taken.
- dataflow 11mo ago
  > One other factor which comes in to play, some people can't stand his communication style. When disagreed with, he tends to dig in his heels and write lengthly responses that question people's motives, like in this blog post and others. I don't have context on this other than the linked page, but if what he's saying is accurate, it does seem pretty damning and corrupt, no? Why all the lies and distortions otherwise - how does one assume a generous explanation for lies and distortions?
  - cryptonector 11mo ago
    > I don't have context on this other than the linked page, but if what he's saying is accurate, it does seem pretty damning and corrupt, no? It's complicated. You'd have to know the rules and read the list archives, and make up your own mind. DJB might be overselling it, so you really do have to check it yourself. I think the WG chair had enough cover to make the call they made. What _I_ would have done is do a WG consensus call on the underlying controversial question once the controversy started, separate from the consensus call on adopting the work item. But I'm not the chair.
    - tptacek 11mo ago
      To which "underlying controversial question" are you referring?
- ImPostingOnHN 11mo ago
blintz 11mo ago
Standardizing a codepoint for a pure ML-KEM version of TLS is fine. TLS clients always get to choose what ciphersuites they support, and nothing forces you to use it. He has essentially accused anyone who shares this view of secretly working for the NSA. This is ridiculous. You can see him do this on the mailing list: https://mailarchive.ietf.org/arch/browse/tls/?q=djb https://mailarchive.ietf.org/arch/browse/tls/?q=djb
- dataflow 11mo ago
  > standardizing a code point (literally a number) for a pure ML-KEM version of TLS is fine. TLS clients always get to choose what ciphersuites they support, and nothing forces you to use it. I think the whole point is that some people would be forced to use it due to other standards picking previously-standardized ciphers. He explains and cites examples of this in the past. > He has essentially accused anyone who shares this view of secretly working for the NSA. This is ridiculous. He comes with historical and procedural evidence of bad faith. Why is this ridiculous? If you see half the submitted ciphers being broken, and lies and distortions being used to shove the others through, and historical evidence of the NSA using standards as a means to weaken ciphers, why wouldn't you equate that to working for the NSA (or something equally bad)?
  - gnfargbl 11mo ago
    Let's invert that thinking. Imagine you're the "security area director" referenced. You know that DJB's starting point is assumed bad faith on your part, and that because of that starting point DJB appears bound in all cases to assume that you're a malicious liar. Given that starting point, you believe that anything other than complete capitulation to DJB is going to be rejected. How are you supposed to negotiate with DJB? Should you try?
    - ImPostingOnHN 11mo ago
      Your response focuses entirely on the people involved, rather than the substance of the concerns raised by one party and upheld by 6 others. I don't care if 1 of the 7 parties regularly drives busloads of orphans off a cliff, if the concerns have merit, they must be addressed. The job of the director is to capitulate to truth, no matter who voices it. Any personal insults one of the parties lobs at others can be addressed separately from the concerns. An official must perform their duties without bias, even concerning somebody who thinks them the worst person in the world, and makes it known. tl;dr: sometimes the rude, loud, angry constituent at the town hall meeting is right
qi_reaper 11mo ago
I understand you are smart and are talking about things above my paygrade, but dang can you format the text on your site so it is easier to read please
- pjz 11mo ago
  uhhh... that's mostly on your browser. The css is at the top and pretty skimpy. If it really bothers you, find a styler extension that will override the CSS to render it more pleasingly.
thomasdeleeuw 11mo ago
France and Germany propose hybrid schemes as well: The german position: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat... "The quantum-safe mechanisms recommended in this Technical Guideline are generally not yet trusted to the same extent as the established classical mechanisms, since they have not been as well studied with regard to side-channel resistance and implementation security. To ensure the long-term security of a key agreement, this Technical Guideline therefore recommends the use of a hybrid key agreement mechanism that combines a quantum-safe and a classical mechanism." The french position, also quoting the German position: https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf https://cyber.gouv.fr/sites/default/files/document/follow_up... "As outlined in the previous position paper [1], ANSSI still strongly emphasizes the necessity of hybridation1 wherever post-quantum mitigation is needed both in the short and medium term. Indeed, even if the post-quantum algorithms have gained a lot of attention, they are still not mature enough to solely ensure the security"

316 points by upofadown 11mo ago

g-mork 11mo ago

Handforth Parish council Internet edition. You have no authority here, djb! No authority at all

D. J. Bernstein is very well respected and for very good reason. And I don't have firsthand knowledge of the background here, but the blog posts about the incident have been written in a kind of weird voice that make me feel like I'm reading about the US Government suppressing evidence of Bigfoot or something. Stuff like this > Wow, look at that: "due process".... Could it possibly be that the people writing the law were thinking through how standardization processes could be abused?" is both accusing the other party of bad faith and also heavily using sarcasm, which is a sort of performative bad faith. Sarcasm can be really effective when used well. But when a post is dripping with sarcasm and accusing others of bad faith it comes off as hiding a weak position behind contempt. I don't know if this is just how DJB writes, or if he's adopting this voice because he thinks it's what the internet wants to see right now. Personally, I would prefer a style where he says only what he means without irony and expresses his feelings directly. If showing contempt is essential to the piece, then the Linus Torvalds style of explicit theatrical contempt is probably preferable, at least to me. I understand others may feel differently. The style just gives me crackpot vibes and that may color reception of the blog posts to people who don't know DJT's reputation.

jonstewart 11mo ago
He’s smart and prolific, for sure, but I lost respect for him several years ago.
- johnisgood 11mo ago
  Why, if I might respectfully ask?
  - jonstewart 11mo ago
    Sure! First, while I’m in no position to judge cryptographic algorithms, the success of cha-cha and 25519 speak for themselves. More prosaically, patriecia/critbit trees and his other tools are the right thing, and foresighted. He’s not just smart, but also prolific. However, he’s left a wake of combative controversy his entire career, of the “crackpot” type the parent comment notes, and at some point it’d be worth his asking, AITA? Second, his unconditional support of Jacob Appelbaum has been bonkers. He’s obviously smart and uncompromising but, despite having been in the right on some issues, his scorched earth approach/lack of judgment seems to have turned his paranoia about everyone being out to get him into a self-fulfilling prophecy.
    - johnisgood 11mo ago
      I do not understand your last paragraph. :/
      - mpyne 11mo ago
        https://medium.com/@hdevalence/when-hell-kept-on-payroll-somewhere-is-where-you-are-f419d3022d0 https://medium.com/@hdevalence/when-hell-kept-on-payroll-som...
        cryptonector 11mo ago
        Thank you! I had no idea.
        philodeon 11mo ago
        That article is pure horsecrap: https://eindhoven.cr.yp.to/false-statements-by-henry-de-valence.txt https://eindhoven.cr.yp.to/false-statements-by-henry-de-vale...
        tptacek 11mo ago
        Because Bernstein says so?
amiga386 11mo ago
It's very simple. ECC is well understood and has not been broken over many years. ML-KEM is new, and hasn't had the same scrutiny as ECC. It's possible that the NSA already knows how to break this, and has chosen not to tell us, and NIST plays the useful idiot. NIST has played the useful idiot before, when it promoted Dual_EC_DRBG, and the US government paid RSA to make it the default CSPRNG in their crypto libraries for everyone else... but eventually word got out that it's almost certainly an NSA NOBUS special, and everyone started disabling it. Knowing all that, and planning for a future where quantum computers might defeat ECC -- it's not defeated yet, and nobody knows when in the future that might happen... would you choose: Option A): encrypt key exchange with ECC and the new unproven algorithm Option B): throw out ECC and just use the new unproven algorithm NIST tells you option B is for the best. NIST told you to use Dual_EC_DRBG. W3C adopted EME at the behest of Microsoft, Google and Netflix. Microsoft told you OOXML is a valid international standard you should use instead of OpenDocument (and it just so happens that only one piece of software, made by Microsoft, correctly reads and writes OOXML). So it goes on. Standards organisations are very easily corruptable when its members are allowed to have conflicts of interest and politick and rules-lawyer the organisation into adopting their pet standards.
- glenstein 11mo ago
  Thank you, that seems to be the whole ball game for me right there. I understood the sarcastic tone as kind of exasperation, but it means something in the context of an extremely concerning attempt to ram through a questionable algorithm that is not well understood and risks a version of an NSA backdoor, and the only real protection would be integrity of standards adoptions processes like this one. You've really got to stick with the substance over the tone to be able to follow the ball here. Everyone was losing their minds over GDPR introducing a potential back door to encrypted chat apps that security agencies could access. This goes to the exact same category of concern, and as you note it has precedent! So yeah, NSA potentially sneaking a backdoor into an approved standard is pretty outrageous, and worth objecting to in strongest terms, and when that risk is present it should be subjected to the highest conceiveable standard of scrutiny. In fact, I found this to be the strongest point in the article - there's any number of alternatives that might (1) prove easier to implement, (2) prove more resilient to future attacks (3) turn out to be the most efficient. Just because you want to do something in the future doesn't mean it needs to be ML-KEM specifically, and the idea of throwing out ECC is almost completely inexplicable unless you're the NSA and you can't break it and you're trying to propose a new standard that doesn't include it. How is that not a hair on fire level concern?
cryptonector 11mo ago
> I don't know if this is just how DJB writes, He's caustic, but often right.

philipwhiuk 11mo ago

[flagged]

6581 11mo ago
That's not what the message you linked claims at all. Maybe you missed the "in this message" at the end of the sentence?
- philipwhiuk 11mo ago
  No not really - I don’t think choosing to post from an alternative email removes the association issue that the original intent is trying to capture.
amszmidt 11mo ago
”No association” and “I am not a representative” are quite different things to say.
- philipwhiuk 11mo ago
  [flagged]
  - amszmidt 11mo ago
    An employee doesn’t act as an official representative of their employer nor do they speak for the employee in any official capacity. That is what the message says. The informal also didn’t cloak their identity (implies some malicious intent), they simple did not use their work email. Nothing wrong with that.
  - conception 11mo ago
    I’m sorry, can you state which organization you are speaking for with this comment? It wasn’t immediately clear.
  - throw0101c 11mo ago
    [flagged]

throw0101a 11mo ago

Perhaps related: from 2022, on his (FOIA?) lawsuit against the government: * https://news.ycombinator.com/item?id=32360533 https://news.ycombinator.com/item?id=32360533 From 2023, "Debunking NIST's calculation of the Kyber-512 security level": * https://news.ycombinator.com/item?id=37756656 https://news.ycombinator.com/item?id=37756656

seethishat 11mo ago

For context, djb has been doing and saying these things since he was a college student: While a graduate student at the University of California at Berkeley, Bernstein completed the development of an encryption equation (an "algorithm") he calls "Snuffle." Bernstein wishes to publish a) the algorithm (b) a mathematical paper describing and explaining the algorithm and (c) the "source code" for a computer program that incorporates the algorithm. Bernstein also wishes to discuss these items at mathematical conferences, college classrooms and other open public meetings. The Arms Export Control Act and the International Traffic in Arms Regulations (the ITAR regulatory scheme) required Bernstein to submit his ideas about cryptography to the government for review, to register as an arms dealer, and to apply for and obtain from the government a license to publish his ideas. Failure to do so would result in severe civil and criminal penalties. Bernstein believes this is a violation of his First Amendment rights and has sued the government. After four years and one regulatory change, the Ninth Circuit Court of Appeals ruled that software source code was speech protected by the First Amendment and that the government's regulations preventing its publication were unconstitutional. Source https://www.eff.org/cases/bernstein-v-us-dept-justice https://www.eff.org/cases/bernstein-v-us-dept-justice

deleted 11mo ago
[deleted]
basilgohar 11mo ago
djb has earned my massive respect for how consistent he's been in this regard. I love his belligerence towards authoritarian overreach in this regard. Him, Phil Zimmermann, Richard Stallman, and all are owed great respect for their insistence on their principles which have paid massive dividends to all of us through the freedom and software that has been preserved and become possible through them. I appreciate them immensely and I think we all owe them a debt of gratitude for their sacrifices, because they all paid a heavy price for their advocacy over time.
- tptacek 11mo ago
  That's the right pantheon, I think. Bernstein, Zimmerman, Stallman.

abhv 11mo ago

20+2 (conditional support) versus 7. 22/29 = 76% in some form of "yea" That feels like "rough consensus"

jcranmer 11mo ago
The standard used in the C and C++ committees is essentially a 2-to-1 majority in favor. I'm not aware of any committee where a 3-to-1 majority is insufficient to get an item to pass. DJB's argument that this isn't good enough would, by itself, be enough for me to route his objections to /dev/null; it's so tedious and snipey that it sours the quality of his other arguments by mere association. And overall, it gives the impression of someone who is more interested in derailing the entire process than in actually trying to craft a good standard.
- vorpalhex 11mo ago
  We're talking about a landmine in a crypto spec and you're bikeshedding about consensus ratios. We should talk about the NSA designed landmine.
  - tptacek 11mo ago
    Have you implemented MLKEM? How well do you understand it?
- pfortuny 11mo ago
  You are turning “consensus” into “majority” and those it not the same.
  - jcranmer 11mo ago
    There was a recent discussion within the C committee over what exactly constituted consensus owing to a borderline vote that was surprisingly ruled "no consensus" (and the gravitas of the discussion was over the difference between a "no" and an "abstain" vote for consensus purposes). The decision was that it had to be a ⅔ favor/(favor + against), and ¾ (favor + neutral) / (favor + against + neutral). These are the actual rules of the committee now for determining consensus. Similar rules exist for the C++ committee. If there is any conflation going on, I am not the one doing it.

John-Tony 11mo ago

[dead]

daedlanth 11mo ago

[dead]

dhx 11mo ago

Amongst the numerous reasons why you _don't_ want to rush into implementing new algorithms is even the _reference implementation_ (and most other early implementations) for Kyber/ML-KEM included multiple timing side channel vulnerabilities that allowed for key recovery.[1][2] djb has been consistent in view for decades that cryptography standards need to consider the foolproofness of implementation so that a minor implementation mistake specific to timing of specific instructions on specific CPU architectures, or specific compiler optimisations, etc doesn't break the implementation. See for example the many problems of NIST P-224/P-256/P-384 ECC curves which djb has been instrumental in fixing through widespread deployment of X25519.[3][4][5] [1] https://cryspen.com/post/ml-kem-implementation/ https://cryspen.com/post/ml-kem-implementation/ [2] https://kyberslash.cr.yp.to/faq.html https://kyberslash.cr.yp.to/faq.html / https://kyberslash.cr.yp.to/libraries.html https://kyberslash.cr.yp.to/libraries.html [3] https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Constant_time_Montgomery_ladder https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplic... [4] https://safecurves.cr.yp.to/ladder.html https://safecurves.cr.yp.to/ladder.html [5] https://cr.yp.to/newelliptic/nistecc-20160106.pdf https://cr.yp.to/newelliptic/nistecc-20160106.pdf

Foxboron 11mo ago
> See for example the many problems of NIST P-224/P-256/P-384 ECC curves What are those problems exactly? The whitepaper from djb only makes vague claims about NSA being a malicious actor, but after ~20 years no known backdoors nor intentional weaknesses has been reliably proven?
- supernetworks_ 11mo ago
  It would be wise for people to remember that it’s worth doing basic sanity checks before making claims like no backdoors from the NSA. strong encryption has been restricted historically so we had things like DES and 3DES and Crypto AG. In the modern internet age juniper has a bad time with this one https://www.wired.com/2013/09/nsa-backdoor/ https://www.wired.com/2013/09/nsa-backdoor/. Usually it’s really hard to distinguish intent, and so it’s possible to develop plausible deniability with committees. Their track record isn’t perfect. With WPA3 cryptographers warned about the known pitfall of standardizing a timing sensitive PAKE, and Harkin got it through anyway. Since it was a standard, the WiFi committee gladly selected it anyway, and then resulted in dragonbleed among other bugs. The techniques for hash2curve have patched that

zahllos 11mo ago

In context, this particular issue is that DJB disagrees with the IETF publishing an ML-KEM only standard for key exchange. Here's the thing. The existence of a standard does not mean we need to use it for most of the internet. There will also be hybrid standards, and most of the rest of us can simply ignore the existence of ML-KEM -only. However, NSA's CNSA 2.0 (commercial cryptography you can sell to the US Federal Government) does not envisage using hybrid schemes. So there's some sense in having a standard for that purpose. Better developed through the IETF than forced on browser vendors directly by the US, I think. There was rough consensus to do this. Should we have a single-cipher kex standard for HQC too? I'd argue yes, and no the NSA don't propose to use it (unless they updated CNSA). The requirement of the NIST competition is that all standardized algorithms are both classical and PQ-resistant. Some have said in this thread that lattice crypto is relatively new, but it actually has quite some history, going back to Atjai in '97. If you want paranoia, there's always code theory based schemes going back to around '75. We don't know what we don't know, which is why there's HQC (code based) waiting on standardisation and an additional on-ramp for signatures, plus the expensive (size and sometimes statefulness) of hash-based options. So there's some argument that single-cipher is fine, and we have a whole set of alternative options. This particular overreaction appears to be yet another in a long running series of... disagreements with the entire NIST process, including "claims" around the security level of what we then called Kyber, insults to the NIST team's security level estimation in the form of suggesting they can't do basic arithmetic (given we can't factor anything bigger than 15 on a real quantum computer and we simply don't have hardware anywhere near breaking RSA, estimate is exactly what these are) and so on.

aaomidi 11mo ago
Except when the government starts then mandating a specific algorithm. And yes. This has happened. There’s a reason there’s only the NIST P Curves in the WebPKI world.
- zahllos 11mo ago
  "The government" already have. That's what CNSA 2.0 means - this is the commercial crypto NSA recommend for the US Government and what will be in FIPS/CAVP/CMVP. ML-KEM-only for most key exchange. In this context, it is largely irrelevant whether the IETF chooses or not to have a single-standard draft. There's a code point from IANA to do this in TLS already and it will happen for US Government systems. I'd also add that personally I consider NIST P-Curves to be absolutely fine crypto. Complete formula exist, so it's possible to have failure-free ops, although point-on-curve needs to be checked. They don't come with the small-order subgroup problem of any Montgomery curve. ECDSA isn't great alone, the hedged variants from RFC 6979 and later drafts should be used. Since ML-KEM is key exchange, X25519 is very widely used in TLS unless you need to turn it off for FIPS. For the certificate side, the actual WebPKI, I'm going to say RSA wins out (still) (I think).

kiray 11mo ago

[flagged]

Foxboron 11mo ago
> This is why djb is in the Cypherpunks Hall of Fame! [1] This is a list made by you 2 weeks ago? EDIT: Okay lol. I actually browsed the list and found multiple dubious entries, along with Trump! Hilarious list. 10/10.
- jonesjohnson 11mo ago
  what do you expect, when the tagline at the end of the page says "In crypto we trust."? Honestly, it's a bit sad. There are many great people on that list, but some seem a bit random and some are just straight up cryptobros, which makes the whole thing a joke, unfortunately
anonym29 11mo ago
Name calling, bullying (forms of systematic harassment) and attempting to instill feelings of social isolation in a target are documented techniques employed by intelligence agencies in both online and offline discourse manipulation / information warfare. You can read up more here if you are curious: https://www.statewatch.org/media/documents/news/2015/jun/behavioural-science-support-for-jtrigs-effects.pdf https://www.statewatch.org/media/documents/news/2015/jun/beh... Many of the attacks against djb line up quite nicely with "discredit" operational objectives.
- webdoodle 11mo ago
  Bully and systematic harassment of cryptographers too build in backdoors too there encryption systems has been there go to strategy since the 80's.
- timschmidt 11mo ago
  Don't forget the ever popular CIA Simple Sabotage Field Manual: https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/SimpleSabotage.pdf https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...

0xbadcafebee 11mo ago

tl;dr DJB is trying to stop the NSA railroading bad crypto into TLS standards, the objections deadline is in two days, and they're stonewalling him This /. story fills in the backstory: https://it.slashdot.org/story/25/11/23/226258/cryptologist-djb-criticizes-push-to-finalize-non-hybrid-security-for-post-quantum-cryptography https://it.slashdot.org/story/25/11/23/226258/cryptologist-d... Normal practice in deploying post-quantum cryptography is to deploy ECC+PQ. IETF's TLS working group is standardizing ECC+PQ. But IETF management is also non-consensually ramming a particular NSA-driven document through the IETF process, a "non-hybrid" document that adds just PQ as another TLS option.

jancsika 11mo ago

Dear some seasoned cryptographer, Please ELI5: what is the argument for including the option for the non-hybrid option in this standard? Is it a good argument in your expert opinion? My pea brain: implementers plus options equals bad, newfangled minus entrenched equals bad, alice only trust option 1 but bob only have option 2 = my pea brain hurt!

dwaite 11mo ago
More of a person with IETF participation experience than as a cryptographer (I enjoy watching numbers dance but am not a choreographer): This ( https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ ) is a document describing how to use the ML-KEM algorithm with TLS 1.3 in an interoperable manner. It does not preclude other post-quantum algorithms from being described for use with TLS 1.3. It also does not preclude hybrid approaches from being used with TLS 1.3. It is however a document scoped so it cannot be expanded to include either of those things. Work to define interoperable use of other algorithms, including hybrid algorithms, would be in other documents. There is no MTI (mandatory-to-implement) once these are documented from the IETF directly, but there could be market and regulatory pressures. My suspicion is that this is bleed-out from a larger (and uglier) fight in the sister organization, the IRTF. There, the crypto forum research group (CFRG) has been having discussions on KEMs which have gotten significantly more heated. A person with concern that there may be weaknesses in a post quantum technique may want a hybrid option to provide additional security. They may then be concerned that standardization of non-hybrid options would discourage hybrid usage, where hybrid is not yet standardized and would likely be standardized later (or not at all). The pressure now with post quantum is to create key negotiation algorithms are not vulnerable to theoretical post quantum computer attack. This is because of the risk of potentially valuable encrypted traffic being logged now in the hopes that it could later be targeted by a post-quantum computer. Non-negotiated encrypted (e.g. just using a static AES key) is already safe, and signature algorithms can be updated much closer to viable attacks to protect transactional data.
- ekr____ 11mo ago
  > It is however a document scoped so it cannot be expanded to include either of those things. Work to define interoperable use of other algorithms, including hybrid algorithms, would be in other documents. FYI, the specification for hybrid MLKEM + ECC is ahead of this document in the publication process. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/

GauntletWizard 11mo ago

The NSA has railroaded bad crypto before [1]. The correct answer is to just ignore it, to say "okay, this is the NSA's preferred backdoored crypto standard, and none of our actual implementations will support it." It is not acceptable for the government to be forcing bad crypto down our throats, it is not acceptable for the NSA to be poisoning the well this way, but for all I respect DJB, they are "playing the game" and 20 to 7 is consensus. [1] https://en.wikipedia.org/wiki/Dual_EC_DRBG https://en.wikipedia.org/wiki/Dual_EC_DRBG

pverheggen 11mo ago

While it's true that six others unequivocally opposed adoption, we don't know how many of those oppose the chairs claiming they have consensus. This may be a normal ratio to move forward with adoption, you'd have to look at past IETF proceeding to get a sense for that. One other factor which comes in to play, some people can't stand his communication style. When disagreed with, he tends to dig in his heels and write lengthly responses that question people's motives, like in this blog post and others. Accusing the chairs of corruption may have influenced how seriously his complaint was taken.

dataflow 11mo ago
> One other factor which comes in to play, some people can't stand his communication style. When disagreed with, he tends to dig in his heels and write lengthly responses that question people's motives, like in this blog post and others. I don't have context on this other than the linked page, but if what he's saying is accurate, it does seem pretty damning and corrupt, no? Why all the lies and distortions otherwise - how does one assume a generous explanation for lies and distortions?
- cryptonector 11mo ago
  > I don't have context on this other than the linked page, but if what he's saying is accurate, it does seem pretty damning and corrupt, no? It's complicated. You'd have to know the rules and read the list archives, and make up your own mind. DJB might be overselling it, so you really do have to check it yourself. I think the WG chair had enough cover to make the call they made. What _I_ would have done is do a WG consensus call on the underlying controversial question once the controversy started, separate from the consensus call on adopting the work item. But I'm not the chair.
  - tptacek 11mo ago
    To which "underlying controversial question" are you referring?
ImPostingOnHN 11mo ago

blintz 11mo ago

Standardizing a codepoint for a pure ML-KEM version of TLS is fine. TLS clients always get to choose what ciphersuites they support, and nothing forces you to use it. He has essentially accused anyone who shares this view of secretly working for the NSA. This is ridiculous. You can see him do this on the mailing list: https://mailarchive.ietf.org/arch/browse/tls/?q=djb https://mailarchive.ietf.org/arch/browse/tls/?q=djb

dataflow 11mo ago
> standardizing a code point (literally a number) for a pure ML-KEM version of TLS is fine. TLS clients always get to choose what ciphersuites they support, and nothing forces you to use it. I think the whole point is that some people would be forced to use it due to other standards picking previously-standardized ciphers. He explains and cites examples of this in the past. > He has essentially accused anyone who shares this view of secretly working for the NSA. This is ridiculous. He comes with historical and procedural evidence of bad faith. Why is this ridiculous? If you see half the submitted ciphers being broken, and lies and distortions being used to shove the others through, and historical evidence of the NSA using standards as a means to weaken ciphers, why wouldn't you equate that to working for the NSA (or something equally bad)?
- gnfargbl 11mo ago
  Let's invert that thinking. Imagine you're the "security area director" referenced. You know that DJB's starting point is assumed bad faith on your part, and that because of that starting point DJB appears bound in all cases to assume that you're a malicious liar. Given that starting point, you believe that anything other than complete capitulation to DJB is going to be rejected. How are you supposed to negotiate with DJB? Should you try?
  - ImPostingOnHN 11mo ago
    Your response focuses entirely on the people involved, rather than the substance of the concerns raised by one party and upheld by 6 others. I don't care if 1 of the 7 parties regularly drives busloads of orphans off a cliff, if the concerns have merit, they must be addressed. The job of the director is to capitulate to truth, no matter who voices it. Any personal insults one of the parties lobs at others can be addressed separately from the concerns. An official must perform their duties without bias, even concerning somebody who thinks them the worst person in the world, and makes it known. tl;dr: sometimes the rude, loud, angry constituent at the town hall meeting is right

qi_reaper 11mo ago

I understand you are smart and are talking about things above my paygrade, but dang can you format the text on your site so it is easier to read please

pjz 11mo ago
uhhh... that's mostly on your browser. The css is at the top and pretty skimpy. If it really bothers you, find a styler extension that will override the CSS to render it more pleasingly.

thomasdeleeuw 11mo ago

France and Germany propose hybrid schemes as well: The german position: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publicat... "The quantum-safe mechanisms recommended in this Technical Guideline are generally not yet trusted to the same extent as the established classical mechanisms, since they have not been as well studied with regard to side-channel resistance and implementation security. To ensure the long-term security of a key agreement, this Technical Guideline therefore recommends the use of a hybrid key agreement mechanism that combines a quantum-safe and a classical mechanism." The french position, also quoting the German position: https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf https://cyber.gouv.fr/sites/default/files/document/follow_up... "As outlined in the previous position paper [1], ANSSI still strongly emphasizes the necessity of hybridation1 wherever post-quantum mitigation is needed both in the short and medium term. Indeed, even if the post-quantum algorithms have gained a lot of attention, they are still not mature enough to solely ensure the security"