Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better-performing “25519” elliptic-curve cryptography

amazon.science

Post reply on HN
Print view View original

11–20 of 92 posts

Re: Better-performing “25519” elliptic-curve cryptography

#11

Post by syzygyhack »

SEJeff wrote: post #5

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

I laughed a little at calling Firedancer contributors "a team at a HFT firm".

Not that you are technically wrong, not at all, that's where Jump came from. It's just that this is all completely blockchain-driven optimization, but the b-word is so dirty now that we've gotta go back to using TradFi for the rep.

Re: Better-performing “25519” elliptic-curve cryptography

#12

Post by 4gotunameagain »

SEJeff wrote: post #5

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

So many manhours spent on finding better ways to shovel around money and pocket what falls from the cracks.

What a wasteful and unproductive enterprise, considering the vast majority of the devised improvements never see the public eye.

Still, impressive work. Imagine if those brilliant minds behind this were focused somewhere else.

Re: Better-performing “25519” elliptic-curve cryptography

#13

Post by posnet »

4gotunameagain wrote: post #12
SEJeff wrote: post #5

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

So many manhours spent on finding better ways to shovel around money and pocket what falls from the cracks. What a wasteful and unproductive enterprise, considering the vast majority of the devised improvements never see the public eye. Still, impressive work. Imagine if those brilliant minds behind this were focused somewhere else.

The greatest minds of our generation spend their time thinking about how to:

- make people click on ads

- make trading algos faster

- replace human artists

- build more efficient killing machines

- destroy any remaining concept of privacy

Re: Better-performing “25519” elliptic-curve cryptography

#14

Post by 4gotunameagain »

posnet wrote: post #13
4gotunameagain wrote: post #12

Earlier quoted context omitted.

So many manhours spent on finding better ways to shovel around money and pocket what falls from the cracks. What a wasteful and unproductive enterprise, considering the vast majority of the devised improvements never see the public eye. Still, impressive work. Imagine if those brilliant minds behind this were focused somewhere else.

The greatest minds of our generation spend their time thinking about how to: - make people click on ads - make trading algos faster - replace human artists - build more efficient killing machines - destroy any remaining concept of privacy

Hey, at least we had one of them working on TempleOS.

Re: Better-performing “25519” elliptic-curve cryptography

#15

Post by miki123211 »

scrapheap wrote: post #9
saghm wrote: post #3

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. 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'l…

5. a lot of people (especially older people I suspect) think "RSA" when they hear "public key cryptography".

I'm in my twenties and still have that reaction. I know elliptic curves exist, I even sort-of-kind-of have an awareness of how they work, but if I was asked to name one cryptosystem that used public and private keys, I'd definitely say RSA first and not elliptic curves.

Re: Better-performing “25519” elliptic-curve cryptography

#16

Post by holowoodman »

nanolith wrote: post #2

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

Even worse: Each new CPU generation will need a new machine model and a reevaluation. Because OOO, speculation and all the timing behaviour are non-functional properties that frequently change due to new optimizations, different internal structuring, etc.

Re: Better-performing “25519” elliptic-curve cryptography

#18

Post by Spooky23 »

scrapheap wrote: post #9
saghm wrote: post #3

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. 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'l…

If you interact with government or some large entities that do business with government, they have to comply with FIPS 140-2, and cannot use ed25519.

Re: Better-performing “25519” elliptic-curve cryptography

#19

Post by vitus »

miki123211 wrote: post #15
scrapheap wrote: post #9

Earlier quoted context omitted.

> 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'l…

5. a lot of people (especially older people I suspect) think "RSA" when they hear "public key cryptography". I'm in my twenties and still have that reaction. I know elliptic curves exist, I even sort-of-kind-of have an awareness of how they work, but if I was asked to name one cryptosystem that used public and private keys, I'd definitely say RSA first and not elliptic curves.

This is likely in no small part due to CS education only really teaching the mechanics of RSA (modular arithmetic, Fermat's little theorem, etc), or at least, that still seems to be the case at Berkeley. I'd guess because elliptic curve crypto requires more advanced math to reason about (more advanced group theory, at least) and doesn't map as cleanly to existing concepts that non-math-major undergrads have.

cryptopals.com also doesn't cover any elliptive curve crypto until you get into the last set.

Re: Better-performing “25519” elliptic-curve cryptography

#20

Post by vitus »

Spooky23 wrote: post #18
scrapheap wrote: post #9

Earlier quoted context omitted.

> 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'l…

If you interact with government or some large entities that do business with government, they have to comply with FIPS 140-2, and cannot use ed25519.

> If you interact with government or some large entities that do business with government, they have to comply with FIPS 140-2, and cannot use ed25519.

Not even when FIPS 140-3 was (finally) finalized in 2019, and testing began in 2020?

https://csrc.nist.gov/projects/cryptographic-module-validati... includes mentions of EdDSA, and Curve25519 is listed among the "Recommended Curves for U.S. Federal Government Use" on page 15 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S....

(I guess the problem is that various crypto implementations need to get recertified under the new standard...)

edit: it looks like AWS-LC [0] and boringcrypto [1] have both been validated under FIPS 140-3. Azure's OpenSSL crypto [2] has only been validated under FIPS 140-2 as far as I can tell.

[0] https://csrc.nist.gov/projects/cryptographic-module-validati...

[1] https://csrc.nist.gov/projects/cryptographic-module-validati...

[2] https://csrc.nist.gov/projects/cryptographic-module-validati...

Post reply on HN