TL;DR

Maintainers of the Python cryptography library say OpenSSL's evolution — especially since OpenSSL 3 — has introduced performance, API and testing regressions that have driven parts of the project to be reimplemented in Rust. They plan to reduce dependence on OpenSSL, citing repeated regressions, increased complexity, and gaps in testing and memory-safety practices.

What happened

Paul Kehrer and Alex Gaynor, who have stewarded pyca/cryptography for 12 years, published a report and presented at the OpenSSL Conference describing deepening concerns with OpenSSL's trajectory. They trace a three-phase history: long-term under-maintenance before Heartbleed, a period of focused improvement afterward, and then the arrival of OpenSSL 3 (2021), which brought major internal refactors and new APIs but also regressions. The maintainers document real-world impacts: elliptic-curve public key loading slowed dramatically between 1.1.1 and early 3.x releases (initially a 5–8x regression, later improved to ~3x), and replacing OpenSSL parsing with Rust code yielded roughly 10x faster X.509 parsing and a 60% faster end-to-end certificate path validation after moving public-key parsing. They criticize OpenSSL 3 features such as OSSL_PARAM and the providers model for adding verbosity, indirection, allocations, locks and layered mitigations (caching, RCU), which together increased complexity and harmed performance. They also highlight persistent CI flakiness, gaps in regression testing, and a serious AVX-512 triggered RSA overflow in OpenSSL 3.0.4 as evidence of systemic issues. The post concludes that pyca/cryptography will pursue multiple ways to reduce reliance on OpenSSL.

Why it matters

  • Performance regressions in a core TLS/crypto library can slow real-world operations (e.g., certificate parsing and key loading), affecting applications and infrastructure.
  • API and internal complexity raise maintenance costs for downstream projects that must interface with OpenSSL.
  • Insufficient tests and flaky CI can allow platform- or CPU-specific security bugs to persist and be merged unnoticed.
  • Movements toward memory-safe implementations (Rust) and alternative libraries could shift the ecosystem and reduce OpenSSL’s dominance.

Key facts

  • Paul Kehrer and Alex Gaynor have maintained pyca/cryptography for 12 years and rely historically on OpenSSL for core algorithms.
  • OpenSSL 3, released in 2021, introduced major API and internal changes that the pyca maintainers say caused regressions in performance and ergonomics.
  • Elliptic-curve public key loading regressed by 5–8x between OpenSSL 1.1.1 and early OpenSSL 3.0.7; later improvements reduced the gap to about 3x slower than 1.1.1.
  • Migrating X.509 parsing from OpenSSL to the project's own Rust implementation produced about a 10x improvement in parsing performance.
  • Moving public-key parsing into Rust code led to a roughly 60% improvement in end-to-end X.509 path validation.
  • OpenSSL 3 added OSSL_PARAM (key/value parameter arrays) and the providers model; pyca/cryptography reports these increased verbosity, indirect calls and allocations.
  • The OpenSSL project had 19 pre-release versions over 16 months during the 3.0 development cycle, and maintainers relied heavily on community reports to find regressions.
  • OpenSSL 3.0.4 contained a critical RSA buffer overflow that only manifested on AVX-512-capable CPUs, illustrating gaps in platform testing coverage.
  • pyca/cryptography began shipping Rust code nearly five years ago and now uses pure-Rust code for parsing and X.509 operations.

What to watch next

  • Whether pyca/cryptography's announced policy changes and specific migration plans (the post says they will pursue several approaches) are published — not confirmed in the source.
  • If and how the OpenSSL project responds to the performance, API and testing criticisms (timelines and concrete fixes) — not confirmed in the source.
  • Adoption and performance impact of pyca/cryptography's Rust components across downstream users (observability and compatibility) — not confirmed in the source.

Quick glossary

  • OpenSSL: A widely used open-source implementation of TLS and common cryptographic algorithms and primitives.
  • pyca/cryptography: A Python cryptography library maintained by the Python Cryptographic Authority, providing high-level cryptographic recipes and low-level bindings.
  • OSSL_PARAM: An OpenSSL 3 API mechanism that passes arrays of key/value parameters to functions instead of traditional function arguments.
  • Provider (OpenSSL): A modular mechanism introduced in OpenSSL 3 for supplying algorithm implementations, intended to replace the older engine model.
  • Continuous integration (CI): Automated build and test systems that run on code changes to detect regressions and integration problems early.

Reader FAQ

Why are pyca/cryptography maintainers critical of OpenSSL?
They cite performance regressions, more verbose and indirect APIs, increased internal complexity, and gaps in testing and platform coverage.

Did the project find concrete performance improvements by leaving OpenSSL for some tasks?
Yes — moving X.509 parsing to Rust improved parsing performance by about 10x, and shifting public-key parsing yielded roughly a 60% faster end-to-end path validation.

Is pyca/cryptography abandoning OpenSSL entirely?
Not confirmed in the source.

Were there security incidents linked to OpenSSL testing gaps?
The maintainers point to a critical RSA buffer overflow in OpenSSL 3.0.4 that only triggered on AVX-512 CPUs as an example of platform-specific testing shortfalls.

The State of OpenSSL for pyca/cryptography Published: January 14, 2026 For the past 12 years, we (Paul Kehrer and Alex Gaynor) have maintained the Python cryptography library (also known as…

Sources

Related posts

By

Leave a Reply

Your email address will not be published. Required fields are marked *