Guidance for Choosing an Elliptic Curve Signature Algorithm | Hacker News Reader

Guidance for Choosing an Elliptic Curve Signature Algorithm

soatok.blog

71 pointszdw34 comments

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?

Isn't libsodium the library to use?

If you're writing an application, you'd better off with a library even higher on the abstraction layer. The one the abstracts away the choice of specific cryptographic primitives. Without being a domain expert your choices might end up subpar, your use of primitives might end up subpar, your attention to detail might end up subpar, etc.

Also, it would be nice to talk to experts in security, since choosing a library and choosing a curve is a very small part of it. You'd have way more ways to fuck up, say, key management, or miss a glaring hole in some other place of your system.

This is precisely what I recommend in my "how to learn cryptography as a programmer" post.

https://soatok.blog/2020/06/10/how-to-learn-cryptography-as-...

Start with the highest-level, hard-to-get-wrong abstraction. If you stop learning there, you're safe!

Then drill down as you be come more of an expert. Libsodium is step 2 from something fit-for-purpose.

That would be my intuitive recommendation, but canvassing experts I haven't found a clear recommendation across all languages. Some have recommended Tink, others have recommended (ugh) OpenSSL. Javascript is particularly fraught: is it better to use libsodium compiled via emscripten, or something native? It's depressing that we don't have agreement here.

Maybe I'll write about that next ;)

For JavaScript: emscripten/wasm/etc. don't currently provide constant-time guarantees, so you're better off using the native crypto module.

> 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.

Good to see the callout on SafeCurves needing some maintenance.

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.

> 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.)

Maybe it'll happen, but one thing to keep in mind is that canonical EdDSA signatures (i.e. PureEdDSA) require feeding the entire input stream, not simply a hash of the input. That can be problematic or even impossible for hardware tokens, as well as other scenarios--e.g. BearSSL's API has to be substantially refactored to support X.509 EdDSA signatures, a refactor which may never happen. So when devising and/or implementing a protocol one must consciously choose the supplemental HashEdDSA variant, if one even has the choice. But as long as people indulge make-perfect-the-enemy-of-good urges, that's yet one more hurdle many won't overcome. (And hesitancy is actually somewhat understandable in this case as DJB and others explicitly discounted the value or need for secure hardware scenarios; they were explicitly optimizing for the most common scenario in typical FOSS environments where the private key is local in software.)

Perhaps Ed448 might gather more momentum as it wouldn't be a direct replacement for P-256. And usage isn't quite as common so selection of the prehashed variant may be more practical. But it's entirely possible we won't see a shift in hardware support as widespread as RSA -> P-256 until quantum-resistant schemes are settled.

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.

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".

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

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

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

"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

It was a design / marketing critique of the blog. I had no idea it was such a controversial topic.

> I had no idea it was such a controversial topic.

I find this statement hard to believe, for reasons that might become more clear as I explain the history that makes your remarks controversial. For the time being, I'm going to assume good faith, and I'll revisit this [suspended] disbelief at the end.

In another comment, you said:

> On a personal note, it's not my cup of tea, but that's cool, there's a million tech blogs without sexualized mascot drawings.

There's a long history of people on technical forums (HN, Reddit, Lobsters, Slashdot, etc.) assuming that furry art is inherently sexual. I blogged about this topic before. https://soatok.blog/2021/04/02/the-furry-sexuality-blog-post...

The history of the "furry is sexual" premise can be traced back to imageboard culture (i.e. 4chan), which got its start from Something Awful, which was the origin of a lot of anti-furry sentiment. This hatred of furries was rooted in queerphobia. See: https://archive.ph/fX8Jo

> A huge, huge motivation for early furry hate was homophobia. That remained the one axis on which we (non-furry dweebs) could punch down, no matter the stated justification. Furries helped mainstream majority-queer online spaces. That made them easy to mock, because they were unashamed enough to be public with their weird art and their dragon wings and their rejection of all the suffocating norms that still make mainstream geek culture an unrelenting hell.

> That invited scorn. It hurt to see others free of the shames that wracked us so. Disgust was the immediate response, a kind of unbodying rejection which would seek to purge any otherness from ourselves. Some of us knew it to be queerphobia, and I'm sure that was the motivation for a lot of the early trolling. Others just wanted to be part of the in-group, and there was no easier way to do that than take a swing at a designated punching bag.

> Something Awful had a particular response to furries. After creating a subforum specifically for furries to post in, everyone who used it was marked with a custom yellow star avatar, then banned.

This meme of hating furries has far-reaching echoes today, with dumb rumors being whipped up all over the country in order to fan the flames against LGBTQIA+ people: https://dogpatch.press/2022/05/23/furries-schools-hoax-map/

You might be wondering, "What's the link between furry and LGBTQIA+ people?"

Well, the best statistical estimates I can find for queer people in America put us at about 5% to 10% of the population. Conversely, about 80% of the furry fandom is LGBTQIA+. https://furscience.com/research-findings/sex-relationships-p...

The "most furries are gay" thing was the premise of how SomethingAwful treated us in the early 2000's: https://twitter.com/spacetwinks/status/728349066178998274

There is also a common sentiment that LGBT people merely existing is "going too far". e.g. https://twitter.com/XydexxUnicorn/status/1528420587001065474

------

So, given that historical context, when someone comments on a technical blog post that they couldn't get past the art (followed by "Maybe separate interests." as a standalone sentence, which comes across as snarky and condescending), and offer up a defense that boils down to "your fursona is too sexualized", it's certainly a red flag.

With multiple data points and doubling down, it becomes very challenging to not read that as an unstated "teehee I'm going to dog-whistle my way around overtly breaking the rules while still signaling anti-furry hate and there's nothing you can do about it, because I'll just play stupid if you call me on it". I deal with this a lot from tech people. To wit: https://soatok.blog/2021/03/04/no-gates-no-keepers/

I'm not saying that's what you're doing or how you feel. This is simply how it comes across to my peers and myself. Only you know what you feel in your heart and believe in your mind.

But that's why dismissing technical articles because of cartoon animal characters and calling them "too sexualized" is likely to be controversial on Hacker News comments.

I hope you find this information helpful for future interactions with furries on Hacker News, because we're not going away.

I think you're getting a bit too worked up over this, possibly due to past interactions with others.

It was my professional suggestion to separate the content to avoid that misinterpretation.

You can't control how you are perceived by others. You have to grow thicker skin. You can simply say "No I don't care about that, it's my passion and I will stand behind it.", instead of getting offended. As some on the right I have to constantly be interpreted as a racist or sexist, or any other ist. That's fine as I know those claims are false and I believe in my views.

More power to whatever you want to do, I'm a libertarian and I think people should be able to do whatever they want as long as they aren't infringing on other people's rights. But you don't get to control other's speech or how they think. You can certainly try to convince them though, which you've certainly made an effort to, I applaud that. I don't think the victim mentality or linking it to "phobias" is helpful though.

> It was my professional suggestion to separate the content to avoid that misinterpretation.

The problem is the misinterpretations, not the juxtaposition. Correct yourself, not me.

I'm never going to stop being gay, or a furry, or a cryptography nerd.

I'm not going to respond to the rest of your comment, because doing so would likely violate the HN guidelines. So that's how far free speech goes.

I never asked you to stop being gay, I truly don't care.

I just advised that you should learn to not get so offended because it's pointless, people will think what they think.

Of course do what you want though, as will I.

Good day.

> I just advised that you should learn to not get so offended because it's pointless, people will think what they think.

Here's the thing: I'm not offended.

If I believe you're acting in good faith, I'm absolutely going to explain to you why you're getting a negative reaction. That's what I did above, which you seemed to have parsed as "taking offense".

If you're not acting in good faith, just tell me what you really are so I can file your opinions where they belong and move on with my day.

One day you're going to be confronted with your "I don't care about the consequences of my actions" attitude in a very personal way, and you're going to think, "Of course I'm not ___ist/______phobic!"

When that finally happens, remember our conversation today, where you took a minority describing how you come across to their peers as them taking offense, and introspect. Maybe you'll learn the lesson I was trying to impart today.

If not, all of this is moot. I don't need your advice, and it's not welcome.

That kind of thing is actually covered by a related guideline:

"Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting."

Furries run the entire internet, just a disclaimer :)

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.

Reply on news.ycombinator.com