Marcus: A Python cryptography library swapped out part of OpenSSL for Rust and got a tenfold speedup. Then a change to public-key parsing made certificate checks 60 percent faster. That’s not some tiny benchmark win. These are the people who maintain the library saying, wait, why is this basic work taking so long?
Tessa: And OpenSSL is underneath a lot of software. So this isn’t just a developer saying, ‘I don’t like this codebase.’ It’s: we depend on this security foundation, and we’re starting to think about depending on it less.
Marcus: Right. The library is called pyca slash cryptography. Its maintainers have relied on OpenSSL for cryptographic algorithms for about twelve years. Their story is kind of in three parts. Before the Heartbleed bug, OpenSSL was under-maintained. After Heartbleed, it got more serious about code review, automated tests, fuzzing—basically trying weird inputs to find crashes—and releases.
Tessa: So they’re not saying OpenSSL never improved.
Marcus: No, they give it credit. Their frustration is that OpenSSL 3, released in 2021, brought major changes, and in their view some of those made the library slower and much more complicated without delivering enough in return.
Tessa: What got slower? Like, what’s the thing I’d notice?
Marcus: Loading a public key, for one. The maintainers reported that elliptic-curve key loading had gotten five to eight times slower compared with OpenSSL 1.1.1. It improved later, but they say it was still about three times slower. And when they replaced OpenSSL’s certificate parsing with their own Rust code, it ran ten times faster than OpenSSL 3.
Tessa: That’s huge. And they say it wasn’t because they had some wild, fancy optimization.
Marcus: Yeah, that’s the part that jumped out at me. They describe avoiding extra copies, memory allocations, hash tables, locks—overhead they say you don’t need just to parse the certificate’s data. No magic trick. Just less machinery.
Tessa: Which makes the slowdown feel less like, ‘Well, security is expensive,’ and more like, ‘Maybe the design made this task expensive.’
Marcus: That’s their argument. OpenSSL 3 introduced these things called providers, which let you swap in different implementations of algorithms. But, in their account, OpenSSL allowed algorithms to be replaced at basically any point while a program was running. That meant adding allocations and locks all over the place. Then they added caches to make that faster, and eventually a more complicated memory-management system called RCU.
Tessa: Wait, so flexibility created a performance problem, and then fixing the performance problem created more complexity?
Marcus: Exactly—
Tessa: Not exactly.
Marcus: You’re right, sorry. Their point is that the fixes didn’t get performance back to where it started, and brought their own bugs. They ask, do you really need to be able to redefine something like SHA-256 in the middle of a program’s run?
Tessa: That’s the real tradeoff, then. A very general system can handle more situations, but it can make the common situation harder and slower.
Marcus: And harder to use. OpenSSL’s newer API passes around arrays of key-value pairs instead of ordinary function arguments. The maintainers give one example: doing an ML-KEM encryption step takes 37 lines and six calls that can fail in OpenSSL. In BoringSSL, it takes 19 lines and three calls that can fail.
Tessa: And that matters beyond the annoyance of typing more?
Marcus: Definitely. More places for mistakes, less help from the compiler checking that you passed the right thing. And they say understanding what OpenSSL does inside has gotten harder, too. They describe following a public function through the source code and running into layers of indirect calls and special cases.
Tessa: In security work, being able to check how something actually works seems pretty important. You don’t want to have to take the black box on faith.
Marcus: Right. And then there’s testing. The maintainers say OpenSSL improved its testing after Heartbleed, but still has big gaps and flaky CI—tests that fail inconsistently, so people get used to ignoring the failures.
Tessa: Which is a problem because sometimes the flaky-looking failure is the bug.
Marcus: There’s a pretty chilling example. OpenSSL 3.0.4 had a buffer overflow in part of its RSA code on computers with AVX-512, a particular set of processor features. CI actually caught the crash—but not every test machine had AVX-512, so the failure was apparently written off as flakiness.
Tessa: So the test system raised its hand, and the team couldn’t tell whether it was noise or a real warning.
Marcus: That’s it. The maintainers also argue that memory safety has to be part of the long-term plan. OpenSSL was built in C at a time when there weren’t practical alternatives that gave you speed without sacrificing memory safety. They say that’s changed—and their own project has already moved much of its parsing and certificate work to Rust.
Tessa: Is this a funding problem, though? Open source projects can be stretched thin.
Marcus: They specifically say they don’t think that explains it. OpenSSL has received considerable funding, and they say its organizations employ more full-time engineers than some of its forks. Their complaint is about choices in design, testing, and priorities—not simply a shortage of people.
Tessa: So what are they actually doing? They’re not just walking away tomorrow.
Marcus: No. They’re going to stop requiring OpenSSL for every new feature. They expect to offer some newer cryptography features through forks like LibreSSL, BoringSSL, or AWS-LC. They’re also looking into changing the OpenSSL copy bundled with their Python packages to one of those forks. Dropping OpenSSL entirely is something they might consider later, not a decision they’ve made now.
Tessa: That feels like the responsible version of losing trust: don’t flip the switch overnight, but don’t pretend the dependency is fine, either.
Marcus: Yeah. A security library isn’t safer just because everybody already depends on it. It stays trustworthy when the code is testable, understandable, and willing to change—and when its users have somewhere else to go if it isn’t.