Guidance for Choosing an Elliptic Curve Signature Algorithm

[matthewdgreen]

This article can be summed up as "Probably Ed25519 is better, on the assumption you're using a good library, but it's ok to use a strong P-256 library if you plan FIPS compliance in the future." With the related (personal) addendum that NIST needs to get its ass in gear and certify Ed25519.

Unfortunately I think it's a little low-level for most implementers, who just want to know which library to use and are scared of things like cofactors and prime-order groups.

Also: it's 2022 and has an ECC side-channel attack ever been used in the wild?

[some_furry]

> Unfortunately I think it's a little low-level for most implementers, who just want to know which library to use and are scared of things like cofactors and prime-order groups.

Ah, yeah, totally fair. I have other blog posts that tackle high-level things. ;)

> Also: it's 2022 and has an ECC side-channel attack ever been used in the wild?

Do you mean by criminal hacking groups?

If not, the best example I know of is: https://auth0.com/blog/critical-vulnerability-in-json-web-en...

If you do mean by criminals, I'm not in the malware/cybercrime part of the security industry, so I have no idea.

[djbusby]

Isn't libsodium the library to use?

[InfoSecErik]

Good to see the callout on SafeCurves needing some maintenance.

[wahern]

For the time being P-256 is really only your only choice if hardware token and enclave support matter. FIDO2 tokens support Ed25519, but only using a custom signature format, and anyhow many of the most popular FIDO2 tokens also support P-256 via PIV smartcard interface. TPMs, Apple T2, etc, only support P-256, and they're becoming ubiquitous on laptops.

You may not think hardware support matters, but which is more likely: somebody breaking your private key remotely using a side-channel attack, or a trojan exfiltrating a key? The latter should be more of concern in many if not most scenarios, especially where an app or protocol is only signing upon interactive user requests. Historically developers tended to give this hardware token support short shrift because the ecosystem was too difficult to work with, so they could just write it off as not feasible. But API support on macOS/iOS and Windows has become much simpler over the years, while hardware more common, and so it's increasingly difficult to take that stance.

[some_furry]

> You may not think hardware support matters, but which is more likely: somebody breaking your private key remotely using a side-channel attack, or a trojan exfiltrating a key?

As a cryptography engineer, this is a good reason to urge Apple, et al. to support Ed25519, not to prioritize P-256.

(Of course, by all means, prioritize P-256 until we can succeed at getting these companies to correct their course on Ed25519 support. But long term? We want Ed25519 to become ubiquitous.)

[jart]

My favorite executive summary of the crypto elliptic curves is this:

     CURVE      SECURITY  RECOMMENDED BY
     ---------- --------- --------------------------------
     SECP256R1  128       IANA, NIST, FRANCE, GERMANY
     SECP384R1  192       IANA, NIST, FRANCE, GERMANY, NSA
     X25519     128       IANA
     X448       224       IANA
     SECP256K1  128       BITCOIN
     BP384R1              GERMANY
     SECP521R1            FRANCE
     GC512A               RUSSIA
     SM2                  CHINA

> Most cryptography libraries offer optimized assembly implementations of NIST P-256, which makes it less likely that your signing operations will leak timing information or become a significant performance bottleneck.

Having implemented the nist curves in assembly myself before, I must say it always amused me, how a language even more memory unsafe than C, can actually make crypto implementations stronger.

[seanhunter]

As a non-expert I've always thought the guidance for making any given crypto choice is "Use the one Dan Bernstein says you should use".

[Const-me]

I typically choose the largest NIST curve supported in the libraries I'm using, like P521.

[hunterb123]

Couldn't get past the furry art. Maybe separate interests.

[dang]

"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."

https://news.ycombinator.com/newsguidelines.html

[some_furry]

https://soatok.blog/2020/07/09/a-word-on-anti-furry-sentimen...

[IntelMiner]

Furries run the entire internet, just a disclaimer :)

[adastra22]

This seems horribly biased against secp256k1. Basically all the disadvantages listed don’t apply to the standard implementation, libsecp256k1. The libsecp code is constant-time, deterministic, sidechannel resistant, is comparable in speed to ed25519, etc. it’s a solid piece of cryptographic engineering. But the author instead insists on comparing as if you’d be using the dumpster fire that is OpenSSL?

A non unity cofactor is a huge pill to swallow. Deployed production systems have been broken over this. Cutting off that entire attack surface from the start with just the cost of being a bit more obscure in your selection of implementation library is a reasonable tradeoff to make.