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?
> 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?
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.
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.
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.
"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."
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."
> 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.
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.
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.
> 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.
> From the above post. I realize that "sexualized" is subjective but that's how it looks from my pov.
What, exactly, about this image seems "sexualized" to you?
This is a con badge from a Fairy Tales themed convention. The artist drew my fursona in the style of Little Red Riding Hood--a fairy tale deemed appropriate by most parents for young children.
There are no genitals depicted in this drawing. There's no secondary sex characteristics being emphasized.
No reasonable person would look at this cartoon image and think, "Oh, this is sexualized" UNLESS they had a pre-existing cognitive distortion to assume "furry = sexual". But that's a false equivalence.
but... you had to go looking for that one, skipping over the part where you saw a bunch of waist-up pictures of a cartoon canine and got too hot and bothered to continue reading? it's not linked from the original article
I'm not saying your POV is wrong. I'm asking you to explain it.
EDIT: Since you edited your comment, I'll edit mine.
> I wouldn't open this blog at work. I certainly wouldn't buy a children's book with this type of art in it.
Why not? I don't see anything wrong with this blog post. I'd happily share it with colleagues and coworkers alike because it's useful information.
The only crowd that might take offense to the content here are cryptocurrency enthusiasts, because of the shade thrown at secp256k1. But, personally speaking, I'm okay with them being upset with me for sharing a link to such a thing.
> You must have to admit that little red riding hood is usually depicted a lot more modestly.
I'm not sure the same rules of clothing apply to cartoon animal characters as to real-life humans.
I certainly don't shriek if a coworker posts a picture of their pet cat at work without the critter being fully clothed.
What are the standards you're applying to this situation?
Also, the image you linked isn't included in the blog post about elliptic curves, so it's a bit weird to cling to it in defense of your initial reaction.
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.
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?