Should ecdh-sha2-nistp256,384,521 be categorized as a failure?

[BareqAZ]

Currently, the algorithms ecdh-sha2-nistp256, 384, and 521 are categorized as "fail" due to concerns that they may have been compromised by the NSA. This suspicion arises from the fact that the NSA has not disclosed how they determined the constants used in these elliptical curves. However, it's important to note that this is merely a suspicion and hasn't been proven.

These algorithms are widely used in large enterprises because the plain Diffie-Hellman algorithms are vulnerable to denial-of-service (DoS) attacks (CVE-2002-20001, CVE-2022-40735). This limits the choice of Key Exchange (KEX) algorithms.

Given that this is only a suspicion and not a confirmed fact, it might be more appropriate to classify these algorithms as a "warning" rather than categorizing them as outright failures. What are your thoughts on this?

[jtesta]

@BareqAZ: I actually did an in-depth research project on this topic a few years back. I really should publish it in a more legible format (currently you can find some presentation slides around on talks I gave, but they're not so easy to follow). The short version is that some people (myself included) see a lot of suspicious things around the NIST P-curves. Furthermore, there are other good community-made alternatives such as X25519 and X448, which also benefit from more rigorous testing (as academic knowledge has grown significantly since the late 1990's as to what properties good curves should have).

Disabling the P-curves does not impact compatibility whatsoever, as all modern SSH clients support X25519. In fact, OpenSSH's default key exchange has been X25519 since 2014.

Given the strong suspicions, as well as the fact that more modern alternatives are already well-supported says (to me, anyway) that its time for the world to move on from the NIST P-curves.

[BareqAZ]

@jtesta digging into this now, I believe I found one of the talks you mentioned. It had a lot of valuable information, so I'm sharing the link here in case anyone else is interested: https://youtu.be/wcwILMlZDpE

I agree with the points discussed. Initially, I thought that if we label it as a "warning," it would mean we're simply alerting the user about the possibility of a backdoor, without automatically causing the test to fail. This approach would allow the user to make their own decision on how to proceed with this information. This is important because many regulated industries need to adhere to FIPS and NIST standards thus a lot of them are still using these algorithms by default so this failure will come as a surprise without much context.

[ecki]

i would suggest a --haha-i-trust-nsa option, because in some context NIST curves are required and it is easier to skim results if they are clean of politics. you can still add a note "You explicitely trust the NIST curves, I will therefore not fail the audit for..." at the end.

[bbaassssiiee]

@jtesta digging into this now, I believe I found one of the talks you mentioned. It had a lot of valuable information, so I'm sharing the link here in case anyone else is interested: https://youtu.be/wcwILMlZDpE

Here is the talk How to manipulate standards by Daniel J. Bernstein: https://www.youtube.com/watch?v=Cj3PN5-n108
"Random numbers don't start with BADA55EC" (Bad Ass E.C.)

[sudo-nano]

Seconding @ecki, I think there should be a --trust-nsa option or similar for situations where NIST curves are required.