> A FIPS 140-3 compliant FIPS Provider<p>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.<p>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: <a href="https://www.phoronix.com/news/OpenSSL-3.1-Released" rel="nofollow">https://www.phoronix.com/news/OpenSSL-3.1-Released</a>
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?
> <i>Various assembler optimisations to a number of different algorithms (e.g. AES-GCM, ChaCha20, SM3, SM4, SM4-GCM) across multiple processor architectures</i><p>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?
<a href="https://www.openssl.org/news/cl31.txt" rel="nofollow">https://www.openssl.org/news/cl31.txt</a> has a more detailed changelog.