Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.cr.yp.to

Post reply on HN
Print view View original

51–60 of 249 posts

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

#51

Post by webdoodle »

anonym29 wrote: post #34
kiray wrote: post #29

[flagged]

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/beh... Many of the attacks against djb line up quite nicely w…

Bully and systematic harassment of cryptographers too build in backdoors too there encryption systems has been there go to strategy since the 80's.

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

#52

Post by jancsika »

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!

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

#53

Post by GauntletWizard »

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

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

#54

Post by MYEUHD »

HelloNurse wrote: post #36
zahllos wrote: post #24

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…

The metaphor near the beginning of the article is a good summary: standardizing cars with seatbelts, but also cars without seatbelts. Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible: IETF standardization is a great opportunity for a long term social engineering operation, much like DES, Clipper, the more recent funny elliptic curve,…

> the more recent funny elliptic curve

Can you elaborate please?

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

#55

Post by chc4 »

Foxboron wrote: post #32
dhx wrote: post #21

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 im…

> 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?

They're vulnerable to "High-S" malleable signatures, while ed25519 isn't. No one is claiming they're backdoored (well, some people somewhere probably are), but they do have failure modes that ed25519 doesn't which is the GP's point.

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

#56

Post by UltraSane »

supernetworks_ wrote: post #39
Foxboron wrote: post #32

Earlier quoted context omitted.

> 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?

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/ . Usually it’s really hard to distinguish intent, and so it’s possible to de…

The NSA changed the S-boxes in DES and this made people suspicious they had planted a back door but then when differential cryptanalysis was discovered people realized that the NSA changes to S-boxes made them more secure against it.

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

#57

Post by jcranmer »

pfortuny wrote: post #49
jcranmer wrote: post #20

Earlier quoted context omitted.

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 t…

You are turning “consensus” into “majority” and those it not the same.

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.

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

#58

Post by zahllos »

vorpalhex wrote: post #45
zahllos wrote: post #24

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…

The standard will be used, as it was the previous time the IETF allowed the NSA to standardize a known weak algorithm. Sorry that someone calling out a math error makes the NIST team feel stupid. Instead of dogpiling the person for not stroking their ego, maybe they should correct the error. Last I checked, a quantum computer wasn't needed to handle exponents, a whiteboard will do.

ML-KEM and ML-DSA are not "known weak". The justification for hybrid crypto is that they might have classical cryptanalytical results we aren't aware of, although there's a hardness reduction for lattice problems showing they're NP-hard, while we only suspect RSA+DLog are somewhere in NP. That's reasonable as a maximal-safety measure, but comes with additional cost.

Obviously the standard will be used. As I said in a sibling comment, the US Government fully intends to do this whether the IETF makes a standard or not.

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

#59

Post by rdtsc »

MYEUHD wrote: post #54
HelloNurse wrote: post #36

Earlier quoted context omitted.

The metaphor near the beginning of the article is a good summary: standardizing cars with seatbelts, but also cars without seatbelts. Since ML-KEM is supported by the NSA, it should be assumed to have a NSA-known backdoor that they want to be used as much as possible: IETF standardization is a great opportunity for a long term social engineering operation, much like DES, Clipper, the more recent funny elliptic curve,…

> the more recent funny elliptic curve Can you elaborate please?

Not op, but they probably meant https://en.wikipedia.org/wiki/Dual_EC_DRBG

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

#60

Post by timschmidt »

UltraSane wrote: post #56
supernetworks_ wrote: post #39

Earlier quoted context omitted.

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/ . Usually it’s really hard to distinguish intent, and so it’s possible to de…

The NSA changed the S-boxes in DES and this made people suspicious they had planted a back door but then when differential cryptanalysis was discovered people realized that the NSA changes to S-boxes made them more secure against it.

That was 50 years ago. And since then we have an NSA employee co-authoring the paper which led to Heartbleed, the backdoor in Dual EC DRBG which has been successfully exploited by adversaries, and documentation from Snowden which confirms NSA compromise of standards setting committees.
Post reply on HN