2

Some loose reports have indicated that NSA implemented backdoors to some NIST elliptic curves. As far as I understand these do not include P-256, P-384, etc.

From a security standpoint, would it be considered bad practice to use e.g. the curve secp256r1 in our TLS1.2 settings. For example: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA)

And what would be alternatives to this?

2
  • 2
    wrt, And what would be alternatives to this? - Consider secp256k1. You can think of bitcoin as a massive bug bounty for secp256k1. If a bad actor were to find a weakness in secp256k1 and exploit it, they could use it to steal other peoples' bitcoin. At $57,000 USD / bitcoin, these would be very lucrative. But, to date, nobody has found a bug and 'claimed the bounty'.
    – mti2935
    Oct 14, 2021 at 13:42

2 Answers 2

4

From a security standpoint, would it be considered bad practice to use e.g. the curve secp256r1 in our TLS1.2 settings

As of October 2021, NIST P-256 (secp256r1) is considered to be more than secure enough for use in TLS in any environment. Complaints about NSA backdoors relating to elliptic curves are mostly due to Dual_EC_DRBG, which is a technically separate matter, although from a security policy perspective it remains relevant.

Some loose reports have indicated that NSA implemented backdoors to some NIST elliptic curves. As far as I understand these do not include P-256, P-384, etc.

This is sort of correct. The secp256r1 curve in TLS 1.2 is being used for the Elliptic Curve Diffie-Hellman (ECDH) exchange. This is the part of the handshake that allows the two clients to agree upon a key. There is no strong evidence that the NIST P-256 and P-521 curves were backdoored.

The link you posted is talking about Dual_EC_DRBG. This is a random number generator (CSPRNG) that was backdoored by the NSA. It uses elliptic curves, but has nothing to do with the P-256 or P-521 curves. The use of Dual_EC_DRBG is not specified as part of a TLS cipher suite. It was promoted for use in some TLS implementations, but it is not used today. Elliptic curve cryptography is an entire branch of study based on an entire field of mathematics - the use of EC in a backdoored cipher has no real impact on the security of EC curves or EC cryptography in general.

The reason that people are somewhat suspicious of the NIST curves is because the NSA used NIST to promote Dual_EC_DRBG. Whether or not they were willing participants remains to be seen, and it is worth keeping in mind that the NSA's project to promote this backdoored CSPRNG largely took place between 1997 and 2005. Given general changes in attitudes and policy regarding cryptography and security infrastructure since then, it is certainly not unfathomable that the NSA may have learned their lesson with regard to damaging trust in NIST. It's also entirely possible that they didn't, of course.

Since the NIST curves were derived from random numbers, there's no way to tell if those numbers were picked in order to insert a backdoor. There's absolutely no evidence or cryptanalysis to concretely support allegations of a backdoor, but it does make some people uneasy. Most cryptographers prefer the use of nothing-up-my-sleeve numbers to alleviate this problem.

secp256k1 is a somewhat popular alternative to secp256r1 precisely because its selection process was fairly transparent. Another curve that some people prefer is Curve25519, which is called X25519 when used in Diffie-Hellman, although it's worth being aware that the most referenced resource for evaluating curve security was written by DJB, who developed Curve25519, so it's hardly surprising that he gives it a glowing review. Still, it's well-trusted, and support for this curve is mandatory in TLS 1.3.

Ultimately, this isn't really a question of cryptographic strength. It's a question of perception and gut feelings around who is or is not trustworthy. There's also the question of whether it really matters in practice. If your threat model doesn't include the NSA (which it almost certainly shouldn't - see Mickens' This World Of Ours for an excellent and highly amusing discussion on this topic) then it doesn't make any material difference whether you use secp256r1, secp256k1, or X25519 for your ECDH key exchange in TLS. If the NSA isn't trying to steal your traffic, the secret presence of an NSA backdoor in NIST P-256 is ultimately irrelevant to your threat model. If the NSA is trying to steal your network traffic, in particular, for whatever unfathomable reason, your use of one particular elliptic curve over the other is not going to be an impediment to them.

In fact, the use of TLS 1.2 instead of TLS 1.3 is far more likely to be the source of a practically exploitable vulnerability than a possible backdoor that might allow the NSA to decrypt TLS traffic to your website. Time spent worrying about which EC curve to use is time you could be spending on security controls to mitigate far more likely and impactful security issues.

1
  • FWIW for TLS1.2 and below: 4492 in 2006 allowed 25 X9/SECG curves (as well as nonstandard 'explicit' ones, which I think noone ever used) and 5639 in 2010 added 3 brainpool, but 8422 in 2018 reduced to only the three NIST primes 'Suite B or better' (P-256,P-384,P-521) plus two djbs (25519,448) added by 7748 in 2016. Similarly TLS1.3 8446 in 2018 has only those five. May 26 at 23:53
3

Your link (DRBG) is a Deterministic Random Bit Generator based on ECC (Dual_EC_DRBG). Dual_EC_DRBG has a trapdoor for the NSA. The trapdoor is not related to a possible backdoor of the NIST curves 1. NIST revealed the s where b = SHA1(s) of the curve P224 or P256 curves;

y2 = x3 - 3x + b

We don't know secp256r1 has a backdoor or not.

You can use NIST's Koblitz Curves; NIST K-409 (sect409k1), NIST K-571 (sect571r1) as stated in the appendix A of

Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier


1 The NIST curve has synonyms; like P256 has other names secp256r1 and prime256v1. The NIST P curves are designed by NSA and the seed is revealed by NIST.
Thomas made a test against Koblitz curves. Similarly, the nothing-in-my-sleeve-number is psychological. It is the seed here. The NSA can search for seed and corresponding curve that they have a backdoor and you still consider that the first number from PI are a nothing-in-my-sleeve-number

8
  • Do I understand correctly if I say that P256 (that you mention) consists of multiple curves, specifically secp256r1 and secp256k1 and maybe others? I read in this answer that P-256 = secp256r1 but you say the SHA1 input has been revealed for P256 which seems to be only the case for secp256k1.
    – Luc
    May 25 at 15:34
  • No, P stands for a family of curves named by NIST and they are listed in Secp, too. The seed is chosen by NSA, later revelaed.
    – kelalaka
    May 25 at 19:23
  • Ah my confusion comes from mixing up r and k. I thought the answer linked in my previous comment referred to -k1 as P256 while you say P256 has a revealed seed and the -r1 version might be backdoored. Instead, what you're saying (hoping I'm correct now) is that P256 aka -r1 might be backdoored despite the known seed. Regardless of my mistake, two names for the same curve in the same answer seems confusing, might it be good to add a clarification like "secp256r1 (also known as P256 or prime256v1)"? I also saw the name prime256v1 earlier but only now learned that that is also the same curve!
    – Luc
    May 25 at 20:30
  • 1
    Note NIST Koblitz curves are characteristic-2 i.e. GF(2^m) and AIUI attacks against these have progressed much better than against GF(p). Plus officially since rfc8422 in 2018 TLS1.2 and below shouldn't use any GF(2^m) curves (Koblitz or random) and only 3 of the GF(p), and TLS1.3 from its inception requires only those 5. May 27 at 0:04
  • 1
    Thanks for the links, interesting reading material! 2 million NUMS numbers from JP/veorq is a lot more than I expected for example
    – Luc
    May 27 at 10:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.