According to Azure support case #116120515025419, the public datacenter only supports the following


Since my goal is to use ECC with Perfect Forward Secrecy, I think these are my best options.


The cheapest EV cert I can locate is at Namecheap/Comodo, and they support the following curves:

 prime256r1, secp256t1, secp384r1, secp521r1.

I am using this guide to generate my certificate, but I'm not sure of which of the following to choose from

ECDSA_P256 Microsoft Software Key Storage Provider
ECDSA_secP256r1 Microsoft Key Storage provider
ECDSA_secP256k1 Microsoft Key Storage provider
ECDSA_nistP256, Microsoft Key Storage provider

Rationale for wanting ECDSA 256

My choice to use the P256 cert will allow developers to use CBC in addition to GCM. I could choose a higher bit length, but the more secure ECDSA CSPs don't support CBC. Is it wise of me to support CBC?

In case it matters, my target clients are mobile apps, browsers, and IoT devices.


  • What is the difference between the curves available in Windows, and which is most appropriate for my use case? (why?)

  • If I do have a choice, which of the curves are least error prone in 3rd party implementations?

    enter image description here enter image description here

2 Answers 2


In a cipher suite like TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, there are two involved curves:

  • One is used for the ECDHE part: a Diffie-Hellman key exchanged is used between client and server, over a given curve.
  • The other is for the ECDSA signature computed by the server: the server signs its ServerKeyExchange message. ECDSA is a signature algorithm that uses computations on an elliptic curve.

There is no requirement that both curves be the same; they are mostly unrelated and live in different worlds. On a conceptual level, the one used for ECDHE is more important, because it must ensure security for the lifetime of the data which will be exchanged over the wire (i.e. if the data is still important ten years from now, then the curve must still be robust ten years from now); the one used in the signature is only for now, and it does not really matter if it gets broken tomorrow.

Note that forward secrecy is all about the key exchange, i.e. the ECDHE part. This is the same idea: security of the signature system matters only for now. Thus, you could perfectly have ECC-powered forward secrecy with a TLS_ECDHE_RSA_* cipher suite, i.e. with an RSA key in the certificate.

Normally, the CSP choice (technically, "CNG key storage provider") is about the type of the private key that will indeed be stored, i.e. corresponding to the certificate and the ECDSA (or RSA) signature. The curve for ECDHE is chosen independently(*), between the client and server, with secrets which are kept in RAM only (and therefore never stored, which is the point of forward secrecy).

That being said, the one curve that is supported everywhere is NIST's curve P-256, also known as "secp256r1" or "prime256r1" (not to be confused with "secp256k1", which is a distinct curve). The NIST curve P-384 also has a fair share of widespread support, although maybe not as much as P-256. Also, P-384 implies a bit more computational work (about three times as much), which does not matter in practice except if some constrained embedded systems are involved (not smartphones; really small systems). An additional point is that P-256 already ensures more than adequate security, even with regards to technological improvements: as far as we know it, if a P-256 ECDHE key exchange ever gets broken, then it will be through use of an as yet mythical quantum computer, and if such a beast is ever built, then it will mince through P-384 with almost as much ease. In that sense, there is no security advantage of using P-384 instead of P-256.

Summary: for maximum interoperability, use P-256. Client and server SSL implementations may still decide to use another curve for the ECDHE part; unless specific guidance is applied, that other curve will usually be P-256 as well, or (depending on involved implementations) Curve25519, which is also a nice choice for security.

(*) Mostly. Some OpenSSL versions will try to match the ECDHE curve size with the curve used in ECDSA, which may or may not make sense since they relate to different operations with different security characteristics, especially with regards to future technological improvements.

  • 1
    So, based on name alone, there is likely no difference between ECDSA_P256 , ECDSA_secP256r1 , ECDSA_nistP256? Ideally there is no implementation difference. I opened a ticket with MSFT to verify. Tangent: I'm reminded of when I was stumped by MSFT's AES acting different from RijndaelManaged... where there was an unexpected difference in operation. (hope that's not the case here) May 3, 2017 at 19:20
  • 1
    If you get these names, then I suspect they relate to the same curve, but with several distinct implementations. In the Microsoft API, the "CSP" (or their CNG equivalent) are responsible for storing and using the private key, so maybe they store keys in different places. For instance, on a Windows 10 machine I use, there is a "Microsoft Software Key Storage Provider" that stores keys in the user profile or registry, and a "Microsoft Platform Crypto Provider" that stores and uses keys in the TPM. May 3, 2017 at 19:47

If possible, none of them. See the last table on this page, choosing Safe Curves: https://safecurves.cr.yp.to/index.html SSL Labs, Best advice: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

Unsafe Curves:

  • P224 P256, P384, -> (unsafe) P521? -> probably unsafe but not listed above.

The only perfectly secure curves are:

  • Curve1174
  • Curve25519 (the only secure curve in windows that I am aware of, RFC draft-ietf-tls-curve25519, added support in Windows 10, version 1607 and Windows Server 2016)
  • Curve41417 formerly named Curve3617
  • Curve383187 authors subsequently recommended switching to M-383
  • M-221 formerly named Curve2213
  • M-383
  • M-511 formerly named Curve511187
  • E-222
  • E-382
  • E-521
  • Ed448-Goldilocks

My Recommendations:

  • ECC curve order "curve25519" ONLY [to prevent 0day downplay attacks], or "curve25519" ALWAYS over "NIST" for compatibility only.
  • SHA 256 over 384, drop P521 (Unless for top secret. For speed as recommended by SSL Labs.)
  • GCM over CBC GCM128 over GCM256 (Unless for top secret. For speed, as recommended by ssl labs.)
  • 128-bit CBC over 256-bit CBC (Unless for top secret. For speed, as recommended by ssl labs.)
  • SHA-2 over SHA-1 (disable sha on schannel, use only sha256,384,512)

Copy and paste into group policy "Ecc Curve Order"


With this config, No P curve ciphers necessary P=Nist; ECDHE/ECDSA=ECC! Let ECC curve order group policy determine "curve25519"

Perfect forward secrecy only:


Copy/Paste into Group Policy SSL Cipher Suite Order:



With nist P curves enabled & prioritized: sls.update.microsoft.com.nsatc.net offered: TLS_ECDHE_RSA_WITH_AES128_GCM_SHA256 named curve: secp256r1 (0x0017) (unsafe NIST/NSA curve, insecure)

fe2.update.microsoft.com.nsatc.net offered TLS_ECDHE_RSA_WITH_AES128_GCM_SHA384 secp256r1, (unsafe NIST/NSA curve, insecure)

With x25519 curve ONLY, enabled: fe2.update.microsoft.com.nsatc.net offered TLS_ECDHE_RSA_WITH_AES128_GCM_SHA384 named curve: x25519 (SAFE)

Schannel = Windows Update, CryptoAPI, IIS (possibly others)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .