← return to blogposts

aurora: QUBIP’s Post-Quantum OpenSSL Provider

Nicola Tuveri (Tampere University)

19/11/2025

OpenSSL architecture and QUBIP.

In our recent posts, we have explored different aspects of preparing real systems for the post-quantum era:

Today’s post is the natural continuation of that story. Back when aurora was still generically called “QUBIP Provider”, we described the initial design and transitional concepts needed to bring post-quantum cryptography (PQC) into OpenSSL. Now, that work has reached maturity: aurora is a complete, fully functional OpenSSL provider, implementing, with system-level integration and real-world applicability, all the algorithms we selected in QUBIP to demonstrate the pilot.

This post summarizes what aurora is, how it integrates into OpenSSL, what we achieved, and how it fits into the broader roadmap of PQC deployment.

What aurora Is

aurora is an OpenSSL provider module:

  • It implements the OpenSSL 3.x provider interface.
  • It exposes post-quantum and PQ/T hybrid algorithms to OpenSSL.
  • It wraps external implementations of those algorithms using our shallow provider design.
  • It allows applications to use PQC through the standard OpenSSL EVP APIs, without modification.

The shallow provider model means aurora does not implement cryptography itself. Instead, it translates OpenSSL EVP operations into calls to external libraries, handling:

  • dispatch table registration
  • parameter passing
  • memory management
  • error mapping
  • OID and metadata integration
  • encoding and decoding keys, signatures, and cryptographic objects to/from various standard (and drafts) formats

This keeps aurora small, maintainable, and future-proof as PQC continues to evolve.

System-Level Architecture: How aurora Integrates with OpenSSL

aurora integrates entirely through OpenSSL’s provider mechanism. At the system level, the path looks like this:

  1. aurora (libaurora.so) is installed into the system’s OpenSSL provider directory, e.g.: 
    /usr/lib64/ossl-modules/
  2. OpenSSL loads aurora via the system configuration file (openssl.cnf).
  3. Upon load, aurora registers algorithm implementations, including all targeted KEMs and signature schemes. It also registers identifiers to negotiate these algorithms in TLS handshakes, the OIDs identifying associated cryptographic objects, and the decoders/encoders required to interoperate with external implementations when exchanging keys and certificates.
  4. OpenSSL routes EVP operations—key generation, encapsulation/decapsulation, sign/verify—to aurora when the selected algorithm is one that aurora provides.
  5. aurora delegates the computation to the external library providing the actual algorithm implementation.
  6. Applications do not change. Tools like openssl pkey, TLS servers like nginx, PKI pipelines, or applications using OpenSSL automatically gain access to PQ/T hybrid algorithms once aurora is active.

By operating purely at the provider layer, aurora becomes part of the system’s cryptographic fabric—on equal footing with OpenSSL’s default and FIPS providers.

Achievements: aurora as a Feature-Complete PQC Provider

aurora has now reached full functional completeness. Here is what has been achieved.

Complete provider implementation

aurora implements all required provider entrypoints:

  • Provider initialization and teardown
  • Algorithm discovery tables
  • KEM operations (keygen, encaps, decaps)
  • Signature operations (sign, verify)
  • Capabilities to advertise provided algorithms in TLS handshakes
  • Encoders and Decoders to serialize and deserialize associated cryptographic objects

This places aurora on par with built-in providers architecturally.

All targeted PQ and hybrid algorithms supported

aurora exposes:

 

ⓘ Note:

  • The ML-DSA-{44,65}_ED25519 algorithms also use ed25519-dalek for the traditional part of the signature.
  • Relevant EU transition recommendations mandate hybrids for the PQC transition: in QUBIP we provide pure ML-DSA options for experimentation only. In QUBIP’s Internet Browsing Pilot we avoid pure ML-DSA deployments in favor of “Composite ML-DSA“ and consistently recommend this approach.
  • Transition recommendations that mandate hybrids for the PQC transition usually mark SLH-DSA as explicitly exempt from the PQ/T Hybrid requirement.
  • In the general TLS use-cases, adopting SLH-DSA for signing the handshake is not recommended. aurora supports the registered IANA TLS SignatureScheme codepoints for experimentation only, and in QUBIP’s Internet Browsing Pilot we do not use SLH-DSA for End-Entity certificates. More details about related discussion are available on the IETF mailing list.

All of these algorithms are available through the OpenSSL EVP layer (and libssl) and are ready for integration in TLS and PKI.

Fully functional hybrid TLS handshakes

We have validated TLS 1.3 handshakes using aurora-provided hybrid KEM groups and “Composite ML-DSA” signatures. This provides Quantum-Secure TLS 1.3 connections, protecting both confidentiality and authentication.

This includes:

  • successful negotiation between client and server
  • correct hybrid encapsulation/decapsulation
  • real-world testing in browser-based scenarios Quantum-Secure Internet Browsing Pilot

PQ and hybrid certificate chain verification

Authentication in the previous step would be meaningless without anchoring it into a Quantum-Secure chain of trust. aurora integrates into OpenSSL’s X.509 layer, enabling:

  • PQC and Composite signature verification
  • handling of all relevant OIDs and algorithm identifiers
  • generation of X.509 certificates, certificate requests (CSRs), and keys for all the supported algorithms
  • parsing and validation of certificates and signatures for all the supported algorithms
  • use of composite certificate chains in TLS

This allowed us to deploy our own Enterprise PKI, rooted in SLH-DSA-SHAKE-256s, and propagated to Intermediate and End-Entity certificates using “Composite ML-DSA” signatures.

This confirms that aurora enables PQ-ready PKI workflows that can operate through a standard OpenSSL deployment and interoperate with other stack implementations.

Confirmed system-level deployment

We validated aurora in realistic configurations:

  • distribution-style system OpenSSL builds
  • TLS termination environments
  • automated certificate management
  • OS crypto-policy interactions
  • integration with higher-level services and applications

aurora behaves like any other system provider—and can therefore be deployed broadly.

Lessons Learned

1. Providers are the correct hook for PQC in OpenSSL

The provider model offers the flexibility and modularity needed for PQC migration without forking OpenSSL or modifying applications.

2. Shallow provider design is extremely effective

Separating provider logic from algorithm code allows easy updates as PQC implementations evolve, greatly improving maintainability.

3. Composite signatures require careful integration

As anticipated in our earlier blogpost, composite signatures introduce nuances in OID handling, parameter structures, and X.509 processing. aurora now demonstrates a complete and functional integration path.

4. System-level concerns matter as much as algorithm design

Provider loading rules, TLS group naming, PKI workflows, and crypto-policy interactions are all essential for real-world deployment.

5. Hybrids are essential—not merely transitional

A key insight from aurora is that hybrid post-quantum and traditional mechanisms must be considered a long-term part of a resilient cryptographic infrastructure.

Hybrid KEMs and composite signatures combine two independent security assumptions and offer strong guarantees even if one assumption weakens over time. A further concern—one that has repeatedly proven critical for the security of real-world systems—is that even when the underlying mathematical assumptions remain solid, the implementation details of cryptographic algorithms can introduce substantial risk. Traditional cryptography benefits from decades of hardening: its mainstream implementations have been scrutinized, optimized, and independently reviewed countless times. In contrast, the ecosystem of PQC implementations is still young, with less operational maturity and fewer years of exposure to rigorous security analysis. Hybrid solutions mitigate this gap by combining well-vetted, time-tested implementations with new, cutting-edge post-quantum counterparts, providing stronger security assurances during this transition period.

This makes them not only the right tool for the PQ transition, but a strategic safeguard for future cryptographic transitions as well.

Given the extensive design and standardization effort invested in hybrid constructions, we argue that they should remain essential beyond the PQC migration and continue to serve in future cryptographic transitions.

We recently presented the current state of aurora at the OpenSSL Conference Prague 2025, slides are already published, and soon recordings will also be made available, if you want to dig deeper:

We also recently presented a short paper, titled “Integrating PQC in OpenSSL via Shallow Providers for Cryptographic Agility”, at NordSec 2025. While the proceedings are not available yet, we uploaded an open-access pre-print version on the IACR Cryptology ePrint Archive: https://eprint.iacr.org/2025/2082.

How This Fits Into the Broader Roadmap

With aurora now fully functional and system-integrated, we have connected all the pieces discussed across the last months:

  • Hybrid TLS demonstrated with real browsers
  • Composite signatures moving toward standardization
  • A complete OpenSSL provider enabling system-wide PQC and hybrid cryptography

This forms a coherent, end-to-end path for PQC deployment—from TLS handshakes, to certificates, to system cryptography.

Our next steps include:

  • expanding interoperability testing across more platforms and TLS implementations;
  • wider pilots in relevant environments, involving more and more end-users;
  • running the extensive evaluation and validation plan we designed in the earlier stages of the QUBIP project, including, among other things, the mTLS (“mutual TLS authentication”) use case;
  • continued participation in the standardization of hybrid and composite schemes.

aurora is now a stable foundation for these next phases of real-world post-quantum deployment.

Share on