Safe curves for Elliptic Curve Cryptography [pdf]
eprint.iacr.org
Safe curves for Elliptic Curve Cryptography [pdf]
1–10 of 76 posts
Re: Safe curves for Elliptic Curve Cryptography [pdf]
#2Seems to be overloaded, see also the earlier site on this topic from the authors: https://safecurves.cr.yp.to
Re: Safe curves for Elliptic Curve Cryptography [pdf]
#3It begs the question: what's wrong with RSA??? I've always heard it's because implementation is hard and ECC magically solves most of these problems, but clearly that's not the case...
Re: Safe curves for Elliptic Curve Cryptography [pdf]
#4It begs the question: what's wrong with RSA??? I've always heard it's because implementation is hard and ECC magically solves most of these problems, but clearly that's not the case...
Even if many older RSA implementations had serious security bugs, that is not the reason why it is not preferred any more.
For equivalent security with ECC (or with AES) at their typical parameters (i.e. 256 to 512 bit elliptic curves or 128-bit to 256-bit AES keys), RSA must use very long keys, even longer than any RSA keys that are used in practice (which are normally no longer than 4096 bits), which makes the RSA operations slow and adds a large overhead to the communication protocols that must send and receive such long keys.
Re: Safe curves for Elliptic Curve Cryptography [pdf]
#5It begs the question: what's wrong with RSA??? I've always heard it's because implementation is hard and ECC magically solves most of these problems, but clearly that's not the case...
"Seriously, stop using RSA"
Re: Safe curves for Elliptic Curve Cryptography [pdf]
#6It begs the question: what's wrong with RSA??? I've always heard it's because implementation is hard and ECC magically solves most of these problems, but clearly that's not the case...
According to the 2020 NIST recommendations, if I'm reading correctly, to get the equivalent of 256 bits of symmetric security, ECC needs 512 bit keys (the factor 2 seems unavoidable for any public key system, because math), but for both RSA and finite-field crypto, you need 15k bit keys to get the same security level.
This is due to the multiplication group modulo a prime (or a pair of primes in RSA) being vulnerable to "index calculus", a faster-than-brute-force way of attacking things.
As the paper says, the main point of ECC is being impervious to index calculus by design, based on an argument by Victor Miller in 1986 about the structure of "point heights" on elliptic curves.
RSA implementations have also led to vulnerabilities in the past, and one of the big claims of djb (as the paper's first author is called in the crypto scene) is that Curve25519 and friends are designed specifically to select, among many secure choices, one that is particularly easy to implement without falling into any of the usual traps.
Re: Safe curves for Elliptic Curve Cryptography [pdf]
#7The naming is unfortunate. Some people (Ubuntu...) have concluded that because some curves are branded "safe" that must mean all the other curves are therefore "unsafe" and must be aggressively phased out as if they were MD5. They're changing apt to refuse to download from repositories signed using NIST curves, for instance.
This doesn't make a whole lot of sense unless you think the NSA have an unknown backdoor that nobody was able to find. But that isn't their stated justification. Instead they cite djb's website. It's apparently not clear enough that the "SafeCurves" are safe in the sense of being easier for cryptographers to implement without bugs, not in the sense that if you have two correct implementations of a "safe" and "unsafe" curve both are equally cryptographically strong.
Therefore if people want to migrate to the "safe" curves over time, that's fine, but it's more like migrating stuff from C++ to Rust. It doesn't automatically imply the prior codebase was buggy, and if you do know of a specific bug then you need to fix it anyway so such migrations are always about reducing the risk of future problems through better engineering practices. That doesn't justify creating a lot of disruption across a distributed ecosystem.
Re: Safe curves for Elliptic Curve Cryptography [pdf]
#8The naming is unfortunate. Some people (Ubuntu...) have concluded that because some curves are branded "safe" that must mean all the other curves are therefore "unsafe" and must be aggressively phased out as if they were MD5. They're changing apt to refuse to download from repositories signed using NIST curves, for instance. This doesn't make a whole lot of sense unless you think the NSA have an unknown backdoor that…
People migrating to djb's curves, or at least allowing them as a first-class citizen, include
- SSH (which includes git over SSH - github suggests djb's Curve 25519 as default: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent)
- TLS (recommended in n1.3)
- NIST (allows Curve25519, but isn't the default choice)
- various cryptocurrency crap
It's only like migrating from C to rust for the person implementing the crypto package and singature verifier. For the average package maintainer, they just have to generate a new key and pass a new command line flag to their sign command.
Re: Safe curves for Elliptic Curve Cryptography [pdf]
#9It begs the question: what's wrong with RSA??? I've always heard it's because implementation is hard and ECC magically solves most of these problems, but clearly that's not the case...
"Seriously, stop using RSA" https://news.ycombinator.com/item?id=30879442
It's hilarious foil-hat level shit here:
https://blog.trailofbits.com/2019/07/08/fuck-rsa/#comment-91...
Re: Safe curves for Elliptic Curve Cryptography [pdf]
#10The naming is unfortunate. Some people (Ubuntu...) have concluded that because some curves are branded "safe" that must mean all the other curves are therefore "unsafe" and must be aggressively phased out as if they were MD5. They're changing apt to refuse to download from repositories signed using NIST curves, for instance. This doesn't make a whole lot of sense unless you think the NSA have an unknown backdoor that…
People migrating to djb's curves, or at least allowing them as a first-class citizen, include - SSH (which includes git over SSH - github suggests djb's Curve 25519 as default: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) - TLS (recommended in n1.3) - NIST (allows Curve25519, but isn't the default choice) - various cryptocurrency crap…
GPG is using ed25519 keys as default since 2.3
https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/0004...