Developers of cryptographic libraries point out that 'OpenSSL problems are getting worse'
The State of OpenSSL for pyca/cryptography — Cryptography 47.0.0.dev1 documentation
https://cryptography.io/en/latest/statements/state-of-openssl/
Koehler and his colleagues have maintained pyca/cryptography for 12 years since 2014, and have relied on OpenSSL for its core cryptographic algorithms throughout that time. However, they are reconsidering their reliance on OpenSSL because they believe OpenSSL development has been misguided in recent years.
OpenSSL had been in a slump for a long time due to a lack of maintainers, but the discovery of a serious bug known as ' Heartbleed ' in 2014 revitalized the community, leading to significant progress and improvements, such as the establishment of a full-fledged code review process, testing using continuous integration (CI) , and the maturation of the release process.
Then in 2021, OpenSSL 3 was released. Although OpenSSL 3 introduced new APIs and underwent major internal refactoring, it regressed in terms of performance and complexity compared to previous versions, and did not make necessary improvements in areas such as verification processes and memory safety.
◆ Performance degradation
First of all, OpenSSL 3 has significantly reduced performance in areas such as analysis and key loading compared to the previous OpenSSL 1.1.1. Several years ago, Koehler et al. reported a bug that caused OpenSSL 3 to load elliptic curve public keys 5 to 8 times slower than OpenSSL 1.1.1. Although subsequent improvements have slightly improved performance, OpenSSL responded to this issue by stating, 'Performance degradation is expected in OpenSSL 3, and even with some optimization, it is not expected to return to the level of OpenSSL 1.1.1.' Koehler et al. point out that while performance degradation may be acceptable if other parts of the library are improved, this is not the case with OpenSSL 3.
In response to this, Koehler et al. reported that by moving certificate analysis from OpenSSL to their own Rust code in pyca/cryptography, they achieved a 10x performance improvement. Furthermore, by moving public key analysis to their own Rust code, they claimed that end-to-end path validation became 60% faster, which clearly shows how large the overhead of OpenSSL was.
◆ API changes and complexity
OpenSSL 3 began a process of significant API changes, which not only reduced performance but also reduced compile-time verification, increased redundancy, and reduced code readability. Furthermore, OpenSSL 3 also introduced the concept of 'providers,' but Koehler and others point out that poor API design caused numerous performance degradations. To mitigate this issue, OpenSSL added caches and eventually introduced a complex memory management strategy called
'From our perspective, this is a vicious cycle of cumulative mistakes. Poorly designed provider APIs led to poor performance. This resulted in increased complexity to mitigate these drawbacks, such as caches and RCU, which ultimately led to more bugs. And yet, despite all of this, performance is worse than it was initially,' Koehler and his colleagues wrote. They also noted that the OpenSSL 3 source code contains a surprising number of obstacles to human comprehension, making it painful to even read.
◆Test environment issues
Koehler and his colleagues point out that while OpenSSL's testing environment has improved significantly since the Heartbleed attack in 2014, significant flaws still exist, particularly in the OpenSSL 3 development cycle, where test coverage deficiencies were evident and the project was still merging code containing failing tests as of 2025.
◆Memory Safety Initiatives
At the time OpenSSL was created, there were no programming languages that meaningfully offered performance, embeddability, and memory safety , but at the time of writing, adopting Rust enabled memory safety. In fact, pyca/cryptography uses Rust for most of its functionality and OpenSSL for its cryptographic algorithms, which Kohler and his colleagues claim has improved performance and avoided several bugs.
◆Is it due to a lack of funds or personnel?
When problems with open source projects are raised, many people assume that the cause is a lack of funding or personnel due to open source. However, OpenSSL received significant funding following the Heartbleed incident in 2014, and the number of software engineers employed by the OpenSSL Corporation and the OpenSSL Foundation exceeds the number of full-time developers of any other OpenSSL fork. Therefore, Koehler and his colleagues believe that OpenSSL's problems are not due to funding or personnel.
Future Direction
'Our experience with OpenSSL has gotten worse over the past few years,' Kohler said, adding that future features will include new APIs that are only available in LibreSSL, BoringSSL, and AWS-LC, rather than OpenSSL. In the long term, they plan to consider potential alternatives, with a view to switching to cryptographic libraries other than OpenSSL.
Finally, Koehler and his colleagues stated, 'We recognize that changes to the libraries we use to provide our cryptographic implementations will have significant impacts on our users. We are not considering these steps lightly, nor do we intend to rush into implementing them. However, the severity of the concerns compels us to act.'
Related Posts:
in Software, Posted by log1h_ik