OpenSSL 3.1
openssl.org> A FIPS 140-3 compliant FIPS Provider
This is actually a pretty big deal. FIPS 140 certifications are required for a lot of US Federal sales. The FIPS 140 standard changed sometime in the past year from major version 2 to major version 3 and lots of changes are required to certify against the v3 standard, even if you had a v2 certification. What's not obvious is that a lot of FIPS 140 certified software libraries are whitelabeled openssl. Because of the openssl teams hard work in getting this released, it really lowers the barrier to entry for companies trying to sell software to the US Federal government.
I wish the certifications were not as onerous as they were, but this is a big step forward for teams that are not staffed to read and implement several hundred pages of ISO standards for how to correctly implement crypto algorithms. Don't even get me started on how the standards you certify against are themselves copyrighted...
Phoronix has published some benchmarks of OpenSSL 3.1 vs 3.0: https://www.phoronix.com/news/OpenSSL-3.1-Released
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
Msys2 is distributing binary openssl (and many other packages):
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.
That's what I've always felt, which is why I build my own.
You can use vcpkg to build it locally from sources
> 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 to see if there are any places it can be improved?
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.
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.
If you look at the output of your compiler many unnecessary loads/stores. Vectorized code in particular still comes out lacking even with intrinsics
In fact, you can benchmark openssl's assembly vs openssl's C: https://github.com/openssl/openssl/blob/master/crypto/aes/ae...
Granted, they aren't using intrinsics in that code, but a sufficiently smart compiler shouldn't need intrinsics
Compilers are capable of very effective optimizations, but they need certain guarantees to be able to apply them and sometimes it's a pain to communicate those guarantees adequately in your source code, or your platform targets don't support all the hints you might need to apply.
Most of the time, a human will do worse than the compiler. But, a human who knows what they're doing and understands the problem well can still improve on the output.
https://www.openssl.org/news/cl31.txt has a more detailed changelog.
No API breakage?