Live data from Hacker News

OpenSSL 3.1

openssl.org

11–20 of 21 posts

Re: OpenSSL 3.1

#11

> Various assembler optimisations to a number of different algorithms (e.g. AES-GCM, ChaCha20, SM3, SM4, SM4-GCM) across multiple processor architectures With modern compilers, how often (or in what circumstances) is it worth "hand-rolling" assembler code versus just letting the compiler do it? Does one make the assembler 'from scratch', or perhaps let the compiler generate the assembler and have a human look at it t…

I think cryptography is one of the few places where it makes sense to do that. Because: * There's not that much code involved. * Many CPUs have instructions specifically made for accelerating cryptographic algorithms. * Security may have specific requirements from the code, such as not giving away any secrets through timing. This may require writing very specific, suboptimal code intentionally.

... and keeping critical pieces of code as much independent as possible from the very few grotesquely and absurdely massive and complex optimizing compilers is always a good idea.

Re: OpenSSL 3.1

#13

> Various assembler optimisations to a number of different algorithms (e.g. AES-GCM, ChaCha20, SM3, SM4, SM4-GCM) across multiple processor architectures With modern compilers, how often (or in what circumstances) is it worth "hand-rolling" assembler code versus just letting the compiler do it? Does one make the assembler 'from scratch', or perhaps let the compiler generate the assembler and have a human look at it t…

It's very worth doing in this context ... almost all of the assembly I've written in the last ten years has been on routines like this. Compilers are very smart, but it's hard for them to optimize concurrent and interleaved cryptographic algorithms to be cache pipeline efficient and operation efficient at the same time.

AES-GCM is "AES" and "GCM" running at the same time on the same data. ChaCha20 is "ChaCha20" and "Poly1305" running at the same time on the same data, usually block by block so that you avoid pulling data into cache more than once. You can interleave their imperative operations in C, or Rust code (or whatever) ... but the compiler isn't going to intuit how some of the math can be re-used across the algorithms without a lot of hints, or how it can be safely vectorized, and at that point you might as well just write the assembly.

Re: OpenSSL 3.1

#14
post #9

This seems like a stupid question, but is anyone releasing binaries of OpenSSL for Windows environments? Is there an expectation that OpenSSL will take reigns in MacOS environments from LibreSSL?

* https://wiki.openssl.org/index.php/Binaries

it feels weird not grabbing this directly from the openssl team. that's a gap in trust...

Re: OpenSSL 3.1

#15
post #9

This seems like a stupid question, but is anyone releasing binaries of OpenSSL for Windows environments? Is there an expectation that OpenSSL will take reigns in MacOS environments from LibreSSL?

You can use the Conan package manager with prebuilt binaries/libraries

https://conan.io/center

Re: OpenSSL 3.1

#17
post #14

Earlier quoted context omitted.

* https://wiki.openssl.org/index.php/Binaries

it feels weird not grabbing this directly from the openssl team. that's a gap in trust...

That's what I've always felt, which is why I build my own.

Re: OpenSSL 3.1

#19
post #9

This seems like a stupid question, but is anyone releasing binaries of OpenSSL for Windows environments? Is there an expectation that OpenSSL will take reigns in MacOS environments from LibreSSL?

You can use vcpkg to build it locally from sources

Re: OpenSSL 3.1

#20
post #14

Earlier quoted context omitted.

* https://wiki.openssl.org/index.php/Binaries

it feels weird not grabbing this directly from the openssl team. that's a gap in trust...

It's the same mistake the Mozilla team did. They completely disregarded the Windows platform. They didn't include Administrative Templates, MSI installers, and didn't integrate with Windows system settings properly such as Root CA trust lists.

OpenSSL feels like the same kind of "Linux fanboy" group that refuses to acknowledge that there is an entire ecosystem out there used by billions of people.

Not having official, digitally signed packages available on their own website is disrespectful to the millions of Windows system administrators that are forced to scrounge around the web looking for official packages.

Instead of one OpenSSL guy spending a few hours setting up a build pipeline in the cloud, scores of administrators have to go find C++ package managers, install C++ toolchains, and "build their own" OpenSSL instead.

This is one of the many reasons I steer clear of OpenSSL. This is a team that infamously wasted time maintaining support for big-endian(!) AMD64 processors, a platform that never existed, but apparently can't find the time to build a couple of DLLs for their second biggest user base.

Post reply on HN