Live data from Hacker News

Better-performing “25519” elliptic-curve cryptography

amazon.science

61–70 of 92 posts

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

#61
I was aware of s2n-bignum which is a very cool project, but apparently there is a larger sister project, aws-lc, that aims for broader set of APIs including OpenSSL compatibility, while retaining the general approach and vibe (lots of formal verification + performance work): https://github.com/aws/aws-lc

That's pretty sweet. I'm currently using BoringSSL in a project as a supplement to OpenSSL (mostly because it is much easier to build for Windows users than requiring them to fiddle with msys2/vcpkg etc; the alternative is to rely on the Windows CNG API, but it lacks features like ed25519 support.) I wonder how much effort it would take to use aws-lc instead... Not that I'm that interested, BSSL is pretty good, but free performance and heavy automated verification is always nice :)

Related: one of the authors of this post, John Harrison, wrote a really good book about automated theorm proving about 15 years ago while working on floating point verification at Intel -- there's still no other book quite like this one, I think https://www.cl.cam.ac.uk/~jrh13/

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

#62
post #49

Earlier quoted context omitted.

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.

What makes the “b-word” dirty?

It's hard to separate from the sea of grifters, con men, cranks, and scammers that infest the domain. Just using the word is a yellow flag that you might be some kind of whacko, even if all you really want to talk about is the math.

People have to forever be on guard that you might at any point pivot to all taxation is theft or how you have formed your own micro nation that consists entirely of yourself and thus have diplomatic immunity from all prosecution. Because it happens. Or maybe you have a once in a lifetime deal to buy this receipt like object for some hideous art that is guaranteed to appreciate in value millions of percent. It's just the crowd that has aggregated around crypto currencies includes a lot of untrustworthy people.

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

#63
post #52
post #41

Earlier quoted context omitted.

These are table stakes for core cryptographic code, and SOT crypto code --- like the Amazon implementation this story is about --- tend at this point all to be derived from formal methods.

As an example, the Amazon implementation doesn't refer to gcc's[1] and clang's[2] "zero_call_used_regs" to zeroise CPU registers upon return or exception of functions working on crypto secrets. OpenSSL doesn't either.[3] firedancer _does_ use "zero_call_used_regs" to allow gcc/clang to zeroise used CPU registers.[9] As another example, the Amazon implementation also doesn't refer to gcc's "strub" attribute which zero…

Zeroizing a register seems pretty straightforward. Zeroizing any cache that it may have touched seems a lot more complex. I guess that's why they work so hard to keep everything in registers. Lucky for them we aren't in the x86 era anymore and there are a useful number of registers. I'll need to read up on how they avoid context switches while their registers are loaded.

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

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

wow amazing, nobody is gonna edit that code ever again...

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

#65
post #59
post #30

Earlier quoted context omitted.

It’s a new from scratch implementation of a validator for Solana the fastest blockchain by several orders of magnitude. The slowest part is signature verification so they sped up hashing to improve performance of the entire system. They follow a first principles approach (the lead has a few physics degrees) and opted to speed up the cryptography. The beauty of this, despite the bad views on blockchain, is that they f…

> The beauty of this, despite the bad views on blockchain, is that they freaking sped up the cryptography of commonly used algorithms more than anything open or closed source that I personally am aware of. For users that have AVX-512, which isn't widely available (AMD Zen 4 / Zen 5, Sapphire Rapids)...

Sure, and cpus supporting it will proliferate. Shockingly to no one reading hacker news... Both software and hardware continue to improve with time generally speaking. This was a huge software improvement on hardware that supports that functionality. It is a huge win for anyone wanting to use these algorithms where they can afford hardware that supports it.

We should celebrate Amazon's improvements and we should celebrate these improvements. Both are great for the future of technology, regardless of why they were initially developed. Improving tech and keeping it open source is good for all.

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

#66
post #61

I was aware of s2n-bignum which is a very cool project, but apparently there is a larger sister project, aws-lc, that aims for broader set of APIs including OpenSSL compatibility, while retaining the general approach and vibe (lots of formal verification + performance work): https://github.com/aws/aws-lc That's pretty sweet. I'm currently using BoringSSL in a project as a supplement to OpenSSL (mostly because it is m…

Upon hearing about AWS-LC, I immediately thought about tying it to nginx to see if it will work.

Turns out someone else has already tried: https://github.com/aws/aws-lc/issues/1827

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

#67
post #61

I was aware of s2n-bignum which is a very cool project, but apparently there is a larger sister project, aws-lc, that aims for broader set of APIs including OpenSSL compatibility, while retaining the general approach and vibe (lots of formal verification + performance work): https://github.com/aws/aws-lc That's pretty sweet. I'm currently using BoringSSL in a project as a supplement to OpenSSL (mostly because it is m…

Upon hearing about AWS-LC, I immediately thought about tying it to nginx to see if it will work. Turns out someone else has already tried: https://github.com/aws/aws-lc/issues/1827

[dead]

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

#68

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.

I'll never be able to figure out what people get from repeating the same thing over and over. I've seen this same exact comment 1000 times on hn and I'm 100% sure you have too (indeed I believe the reason you repeat is because you've seen it and agree with it).

It's virtue signalling.

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

#69
post #57
post #48

Earlier quoted context omitted.

I pretty quickly realized in college when learning about this stuff that the math was well over my head, and I shifted my focus more to understanding how to properly use cryptography rather than implement it (which turned out to be more important as a software engineer anyhow). In retrospect, I really appreciate how the professor I had in a security-focused course explicitly told us it was okay if we didn't understan…

Counterpoint: it's not OK to skip the math with cryptography. You may not need to power through all of Silverman's curve book (though: I don't know for sure that's true, which is why I don't call myself a cryptography engineer), but you have to get as deep into the math as you can in order to safely use cryptographic algorithms. If you're math-avoidant, stick with high-level abstractions like NaCL and TLS. There's no…

I'm not sure if you're reading more into what I said than I intended, but I'm not convinced by this argument. You might have missed that this course was on security in general, not cryptography; not everything in the course was cryptographic related.

That said, I'd argue that for the vast majority of software engineers the type of stuff they're dealing with can be dealt with without needing to know the math. For example, you don't need to understand the math to behind the algorithms to know that bcrypt is a reasonable password hashing algorithm and that sha1 and md5 are not, or that salts are used to mitigate issues when users reuse passwords. These are principles that you can understand at a high level without fully understanding the underlying details. If anything, I think that overemphasis on requiring people to learn and understand the math has the effect of over-focusing on simpler algorithms that aren't actually what people want to be using in practice due to the fact that they're easier to teach and often foundational in conveying concepts that would need to be learned to understand the more complicated algorithms.

If using cryptographic algorithms directly requires knowing the math, then I'd agree that most people shouldn't be using them directly, but I'd go further and say that a lack of libraries that are safe for people to use for software engineering without understanding the implementation is a failing of the ecosystem; as much as "regular" software engineering people (like myself!) can struggle with the math behind cryptography, I think that a lot of people developing cryptographic libraries struggle with building reasonable abstractions and making user-friendly APIs (which is a skill I think in general is not emphasized enough for most software engineers, to the detriment of everyone).

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

#70
post #69
post #57

Earlier quoted context omitted.

Counterpoint: it's not OK to skip the math with cryptography. You may not need to power through all of Silverman's curve book (though: I don't know for sure that's true, which is why I don't call myself a cryptography engineer), but you have to get as deep into the math as you can in order to safely use cryptographic algorithms. If you're math-avoidant, stick with high-level abstractions like NaCL and TLS. There's no…

I'm not sure if you're reading more into what I said than I intended, but I'm not convinced by this argument. You might have missed that this course was on security in general, not cryptography; not everything in the course was cryptographic related. That said, I'd argue that for the vast majority of software engineers the type of stuff they're dealing with can be dealt with without needing to know the math. For exam…

Sure. It's a failing of the ecosystem. That observation, a cup of coffee, and 1-3 years will get you a Kenny Paterson paper stunt-breaking your system. I feel where you're coming from, but, respectfully: it does not matter.

My thing here is just: learn the math! Or do something else. I did! There is so much to do in our industry.

Post reply on HN