You're talking about the first CVE. The second one affects 1.1 too.

Thankfully I can't imagine anyone using AES-OCB.

Mosh uses AES-OCB (and has since 2011), and we found this bug when we tried to switch over to the OpenSSL implementation (away from our own ocb.cc taken from the original authors) and Launchpad ran it through our CI testsuite as part of the Mosh dev PPA build for i686 Ubuntu. (It wasn't caught by GitHub Actions because it only happens on 32-bit x86.) https://github.com/mobile-shell/mosh/issues/1174 for more.

So I would say (a) OCB is widely used, at least by the ~million Mosh users on various platforms, and (b) this episode somewhat reinforces my (perhaps overweight already) paranoia about depending on other people's code or the blast radius of even well-meaning pull requests. (We really wanted to switch over to the OpenSSL implementation rather than shipping our own, in part because ours was depending on some OpenSSL AES primitives that OpenSSL recently deprecated for external users.)

Maybe one lesson here is that many people believe in the benefits of unit tests for their own code, but we're not as thorough or experienced in writing acceptance tests for our dependencies.

Mosh got lucky this time that we had pretty good tests that exercised the library enough to find this bug, and we run them as part of the package build, but it's not that farfetched to imagine that we might have users on a platform that we don't build a package for (and therefore don't run our testsuite on).

As a non-crypto-nerd: How viable is it to make a “safe” OpenSSL, which just doesn’t support all the cipher modes (?) that the HN crowd would mock me for accidentally using?

The modes of operation aren't the main reason people use OpenSSL; it's the support for all the gnarly (and less gnarly) protocols and wire formats that show up when doing applied cryptography.

Progress is being made on replacing OpenSSL in a lot of contexts (specifically, the RustCrypto[1] folks are doing excellent work and so is cryptography[2]), but there are still plenty of areas where OpenSSL is needed to compose the mostly algebraic cryptography with the right wire format.

Edit: I forgot to mention rustls[3], which uses ring[4] under the hood.

[1]: https://github.com/RustCrypto

[2]: https://github.com/pyca/cryptography

[3]: https://github.com/rustls/rustls

[4]: https://github.com/briansmith/ring

OpenSSL > Forks: https://en.wikipedia.org/wiki/OpenSSL#Forks

TLS 1.3 specifies which curves and ciphers: https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1...

(IDK what the TLS (and FIPS) PQ Algo versioning plans are: 1.4, 2.0?)

Mozilla [Open]SSL Config generator: https://ssl-config.mozilla.org/

Tell that to Mumble! OCB is still one of the fastest / ‘best’ encryption from algorithm perspective, if you can ignore the patents

It's not patented any more.

The patents has recently been expired.

From that link:

"BoringSSL, LibreSSL and the OpenSSL 1.1.1 branch are not affected. Furthermore, only x64 systems with AVX512 support are affected."

Also from that link:

> the vulnerability has only existed for a week (HB existed for years) and an AVX512-capable CPU is required.

So I'm guessing the real world impact here is near zero?

What systems or distros are shipping this week old version already?