Better-performing “25519” elliptic-curve cryptography
amazon.science
Better-performing “25519” elliptic-curve cryptography
1–10 of 92 posts
Re: Better-performing “25519” elliptic-curve cryptography
#2The formal methods nerd in me is happy to see HOL Light being used to formally verify this implementation. I'm curious to see how closely their abstract machine models follow specific machine implementations. OOO, speculation, and deep pipelining have non-trivial impacts on potential side channels, and these vary quite a bit by stepping and architecture.
Re: Better-performing “25519” elliptic-curve cryptography
#3My (probably naive) understanding is that 25519 already provided better performance than other algorithms used for similar purposes (e.g. RSA) when tuned for a roughly similar level of security; anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519. At times I've run into places that require me to use RSA keys though (ironically, I seem to remember first experiencing this with AWS years back, although I honestly can't recall if this is still the case or not).
If this further improvement becomes widely used, it would be interesting to see if it's enough to tip the scales towards ed25519 being more of the de facto "default" ssh key algorithm. My experience is that a decent number of people still use RSA keys most of the time, but I don't feel like I have nearly enough of a sample size to conclude anything significant from that.
Re: Better-performing “25519” elliptic-curve cryptography
#4My (probably naive) understanding is that 25519 already provided better performance than other algorithms used for similar purposes (e.g. RSA) when tuned for a roughly similar level of security; anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519. At times I've run into places that require me to use RSA keys though (ironically, I seem to remember first experiencing this wi…
> anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519
That’s not really anecdotal. Generating an ed25519 key is barely more than generating a random 256-bit value. Generating an RSA key is significantly more work.
Re: Better-performing “25519” elliptic-curve cryptography
#5The firedancer team at one of the better HFT firms wrote an AVX512 optimized implementation of ed25519 and X25519 that’s significantly faster than OpenSSL.
https://github.com/firedancer-io/firedancer/pull/716
Ditto for sha256: https://github.com/firedancer-io/firedancer/pull/778
And sha512: https://github.com/firedancer-io/firedancer/pull/760
If you’re an optimization nerd, this codebase is wild.
Re: Better-performing “25519” elliptic-curve cryptography
#6My (probably naive) understanding is that 25519 already provided better performance than other algorithms used for similar purposes (e.g. RSA) when tuned for a roughly similar level of security; anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519. At times I've run into places that require me to use RSA keys though (ironically, I seem to remember first experiencing this wi…
> anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519 That’s not really anecdotal. Generating an ed25519 key is barely more than generating a random 256-bit value. Generating an RSA key is significantly more work.
I did say my understanding was probably naive; I didn't know the details to be able to assert anything beyond my own observation!
Re: Better-performing “25519” elliptic-curve cryptography
#7My (probably naive) understanding is that 25519 already provided better performance than other algorithms used for similar purposes (e.g. RSA) when tuned for a roughly similar level of security; anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519. At times I've run into places that require me to use RSA keys though (ironically, I seem to remember first experiencing this wi…
> My (probably naive) understanding is that 25519 already provided better performance than other algorithms used for similar purposes (e.g. RSA) when tuned for a roughly similar level of security; anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519.
My also naive (an possibly out of date) understanding is key generation is much faster in with ecc, and that signing is faster too, but verifying is faster for rsa. So switching from a RSA to an ECC server certificate saves bytes on the wire, because keys are smaller, and saves server cpu because signing is faster, but may increase client cpu because verification is slower. The byte savings may make up for the increase in cpu though.
Re: Better-performing “25519” elliptic-curve cryptography
#8Earlier quoted context omitted.
> anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519 That’s not really anecdotal. Generating an ed25519 key is barely more than generating a random 256-bit value. Generating an RSA key is significantly more work.
I did say my understanding was probably naive; I didn't know the details to be able to assert anything beyond my own observation!
Yep, not faulting you at all! I too was surprised when I found out that it’s a straight 256-bit random value with a few bits masked.
Re: Better-performing “25519” elliptic-curve cryptography
#9My (probably naive) understanding is that 25519 already provided better performance than other algorithms used for similar purposes (e.g. RSA) when tuned for a roughly similar level of security; anecdotally, generating 2048-bit or larger RSA keys for me tends to be a lot slower than ed25519. At times I've run into places that require me to use RSA keys though (ironically, I seem to remember first experiencing this wi…
> My experience is that a decent number of people still use RSA keys most of the time, but I don't feel like I have nearly enough of a sample size to conclude anything significant from that.
I wouldn't be surprised if a lot of people still use RSA for SSH keys for one or more of the following reasons:
1. A lot of tutorials about generating SSH Keys were written before ed25519, so if they follow an old tutorial they'll probably be generating an RSA key.
2. Older versions of OpenSSH, that you'd find on CentOS 7 and below, would default to RSA if you didn't specify a key type when running ssh-keygen.
3. There are some systems out there that don't support ed25519, though they are becoming rarer. If you have to deal with those systems then you're forced to use RSA (at least for that system).
4. Some of us have been using SSH keys from way before OpenSSH add support for ed25519 keys in 2014, so any long lived SSH keys won't be ed25519 keys (wow, ed25519 has now been about in OpenSSH for over 10 years).
Re: Better-performing “25519” elliptic-curve cryptography
#10The firedancer team at one of the better HFT firms wrote an AVX512 optimized implementation of ed25519 and X25519 that’s significantly faster than OpenSSL. https://github.com/firedancer-io/firedancer/pull/716 Ditto for sha256: https://github.com/firedancer-io/firedancer/pull/778 And sha512: https://github.com/firedancer-io/firedancer/pull/760 If you’re an optimization nerd, this codebase is wild.
Completely agree re: firedancer codebase. There is a level of thought and discipline wrt performance that I have never seen anywhere else.