Our great sponsors
-
cryptography
cryptography is a package designed to expose cryptographic primitives and recipes to Python developers.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
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.
[1]: https://github.com/RustCrypto
[2]: https://github.com/pyca/cryptography
Really? Are we really going to turn this into a Rust vs. C flamewar when the code in question is most likely Assembly generated by Perl? https://github.com/openssl/openssl/blob/2e3e9b4887b5077b949c... In the recent release they changed a `jb` to `jbe` in that file which could be related. It's hard to tell what code is actually the culprit. They had a similar file in Perl which appeared to be for fused-multiply add avx512 that got removed at some point, possibly with a C rewrite, so you could be somewhat right. Either way there really should be more transparency about how what's written in release notes matches up with the code that actually changes between tags.
It takes time and resources, but Rust is being used, e.g., https://www.memorysafety.org/initiative/rustls/ which has been being worked on at least 6 years https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... ... I'd hope and guess that resources are increasing, especially as governments realize that software security is their problem too.
Beyond the simple matter of Rust being much newer than OpenSSL, one concern for some cryptographic primitives is the timing side-channel.
https://en.wikipedia.org/wiki/Timing_attack
In high level languages like Rust, the compiler does not prioritise trying to emit machine code which executes in constant time for all inputs. OpenSSL has implementations for some primitives which are known to be constant time, which can be important.
One option if you're working with Rust anyway would be use something like Ring:
https://github.com/briansmith/ring
Ring's primitives are just taken from BoringSSL which is Google's fork of OpenSSL, they're a mix of C and assembly language, it's possible (though fraught) to write some constant time algorithms in C if you know which compiler will be used, and of course it's possible (if you read the performance manuals carefully) to write constant time assembly in many cases.
In the C / assembly language code of course you do not have any safety benefits.
It can certainly make sense to do this very tricky primitive stuff in dangerous C or assembly, but then write all the higher level stuff in Rust, and that's the sort of thing Ring is intended for. BoringSSL for example includes code to do X.509 parsing and signature validation in C, but those things aren't sensitive, a timing attack on my X.509 parsing tells you nothing of value, and it's complicated to do correctly so Rust could make sense.
Mosh uses AES-OCB (and has since 2012), 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.