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

131–140 of 249 posts

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

#131

Post by blintz »

HelloNurse wrote: post #80
blintz wrote: post #70

Earlier quoted context omitted.

> 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 AES and RSA are also supported by the NSA, but that doesn’t mean they were backdoored.

AES and RSA had enough public scrutiny to make backdooring backdoors imprudent. The standardization of an obviously weaker option than more established ones is difficult to explain with security reasons, so the default assumption should be that there are insecurity reasons.

There was lots of public scrutiny of Kyber (ML-KEM); DJB made his own submission to the NIST PQC standardization process. A purposely introduced backdoor in Kyber makes absolutely no sense; it was submitted by 11 respected cryptographers, and analyzed by hundreds of people over the course of standardization.

I disagree that ML-KEM is "obviously weaker". In some ways, lattice-based cryptography has stronger hardness foundations than RSA and EC (specifically, average -> worst case reductions).

ML-KEM and EC are definitely complementary, and I would probably only deploy hybrids in the near future, but I don't begrudge others who wish to do pure ML-KEM.

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

#132

Post by bigbadfeline »

crote wrote: post #82
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?

As I understand it, a big issue is that they are really hard to implement correctly. This means that backdoors and weaknesses might not exist in the theoretical algorithm, but still be common in real-world implementations. On the other hand, Curve25519 is designed from the ground up to be hard to implement incorrectly : there are very few footguns, gotchas, and edge cases. This means that real-world implementations a…

> As I understand it, a big issue is that they are really hard to implement correctly.

Any reference for the "really hard" part? That is a very interesting subject and I can't imagine it's independent of the environment and development stack being used.

I'd welcome any standard that's "really hard to implement correctly" as a testbed for improving our compilers and other tools.

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

#133

Post by dataflow »

blintz wrote: post #127
dataflow wrote: post #75

Earlier quoted context omitted.

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

> 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. If an organization wants to force its clients or servers to use pure ML-KEM, they can already do this using any means they like. The standardization of a TLS ciphersuite is besides the point. > He comes with historical and procedura…

> The standard of proof for an accusation like that cannot be "you disagree with me".

How is that the standard he's applying, though? Just reading his post, it's clearly "you're blatantly and repeatedly lying, and distorting the facts, and not even addressing my arguments". Surely "you disagree with me" is not an accurate characterization of this?

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

#134

Post by vessenes »

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?

in the NIST Curve arena, I think DJB's main concern is engineering implementation - from an online slide deck he published:

  We’re writing a document “Security dangers of the NIST curves”
  Focus on the prime-field NIST curves
  DLP news relevant to these curves? No
  DLP on these curves seems really hard
  So what’s the problem?
  Answer: If you implement the NIST curves, chances are you’re doing it wrong
  Your code produces incorrect results for some rare curve points
  Your code leaks secret data when the input isn’t a curve point
  Your code leaks secret data through branch timing
  Your code leaks secret data through cache timing
  Even more trouble in smart cards: power, EM, etc.
  Theoretically possible to do it right, but very hard
  Can anyone show us software for the NIST curves done right?
As to whether or not the NSA is a strategic adversary to some people using ECC curves, I think that's right in the mandate of the org, no? If a current standard is super hard to implement, and theoretically strong at the same time, that has to make someone happy on a red team. At least, it would make me happy, if I were on such a red team.

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

#135

Post by vessenes »

bigbadfeline wrote: post #132
crote wrote: post #82

Earlier quoted context omitted.

As I understand it, a big issue is that they are really hard to implement correctly. This means that backdoors and weaknesses might not exist in the theoretical algorithm, but still be common in real-world implementations. On the other hand, Curve25519 is designed from the ground up to be hard to implement incorrectly : there are very few footguns, gotchas, and edge cases. This means that real-world implementations a…

> As I understand it, a big issue is that they are really hard to implement correctly. Any reference for the "really hard" part? That is a very interesting subject and I can't imagine it's independent of the environment and development stack being used. I'd welcome any standard that's "really hard to implement correctly" as a testbed for improving our compilers and other tools.

I posted above, but most of the 'really hard' bits come from the unreasonable complexity of actual computing vs the more manageable complexity of computing-with-idealized-software.

That is, an algorithm and compiler and tool safety smoke test and improvement thereby is good. But you also need to think hard about what happens when someone induces an RF pulse at specific timings targeted at a certain part of a circuit board, say, when you're trying to harden these algorithmic implementations. Lots of things that compiler architects typically say is "not my problem".

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

#136

Post by dwaite »

ImPostingOnHN wrote: post #84
abhv wrote: post #14

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

consensus is not a synonym for majority , supermajority , or for any fraction of the whole, unless the fraction is 100%

You may misunderstand how the IETF works. Participation is open. This means that it is possible that people who want the work to fail for their own reasons rather than technical merit can join and attempt to sabotage work.

So consensus by your definition is rarely possible given the structure of the organization itself.

This is why there are rough consensus rules, and why there are processes to proceed with dissent. That is also why you have the ability to temporarily ban people, as you would have with pretty much any well-run open forum.

It is also important to note that the goal of IETF is also to create interoperable protocol standards. That means the work in question is a document describing how to apply ML-KEM to TLS in an interoperable way. It is not a discussion of whether ML-KEM is a potentially risky algorithm.

DJB regularly acts like someone who is attempting to sabotage work. It is clear here that they _are_ attempting to prevent a description of how to use ML-KEM with TLS 1.3 from being published. They regularly resort to personal attacks when they don't get their way, and make arguments that are non-technical in nature (e.g. it is NSA sabotage, and chairs are corrupt agents). And this behavior is self-documented in their blog series.

DJB's behavior is why there are rules for how to address dissent. Unfortunately, after decades DJB still does not seem to realize how self-sabotaging this behavior is.

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

#137

Post by vessenes »

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…

My professors at Brown were walking on QR lattice cryptography well before 1997, although they may not have been publishing much - NTRU was in active development throughout the mid 1990s when I was there. Heating up by 1997 though, for sure.

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

#138

Post by [deleted] »

ImPostingOnHN wrote: post #95
gnfargbl wrote: post #90

Earlier quoted context omitted.

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

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

[deleted]

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

#139

Post by woodruffw »

HelloNurse wrote: post #80
blintz wrote: post #70

Earlier quoted context omitted.

> 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 AES and RSA are also supported by the NSA, but that doesn’t mean they were backdoored.

AES and RSA had enough public scrutiny to make backdooring backdoors imprudent. The standardization of an obviously weaker option than more established ones is difficult to explain with security reasons, so the default assumption should be that there are insecurity reasons.

> AES and RSA had enough public scrutiny to make backdooring backdoors imprudent.

Can you elaborate on the standard of scrutiny that you believe AES and RSA (which were standardized at two very different maturation points in applied cryptography) met that hasn't been applied to the NIST PQ process?

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

#140

Post by adgjlsfhk1 »

blintz wrote: post #131
HelloNurse wrote: post #80

Earlier quoted context omitted.

AES and RSA had enough public scrutiny to make backdooring backdoors imprudent. The standardization of an obviously weaker option than more established ones is difficult to explain with security reasons, so the default assumption should be that there are insecurity reasons.

There was lots of public scrutiny of Kyber (ML-KEM); DJB made his own submission to the NIST PQC standardization process. A purposely introduced backdoor in Kyber makes absolutely no sense; it was submitted by 11 respected cryptographers, and analyzed by hundreds of people over the course of standardization. I disagree that ML-KEM is "obviously weaker". In some ways, lattice-based cryptography has stronger hardness f…

I don't think anyone is arguing that Kyber is purposefully backdoored. They are arguing that it (and basically every other lattice based method) has lost a minimum of ~50-100 bits of security in the past decade (and half of the stage 1 algorithms were broken entirely). The reason I can only give ~50-100 bits as the amount Kyber has lost is because attacks are progressing fast enough, and analysis of attacks is complicated enough that no one has actually published a reliable estimate of how strong Kyber is putting together all known attacks.

I have no knowledge of whether Kyber at this point is vulnerable given whatever private cryptanalysis the NSA definitely has done on it, but if Kyber is adopted now, it will definitely be in use 2 decades from now, and it's hard to believe that it won't be vulnerable/broken then (even with only publicly available information).

Post reply on HN