Client-Side Architecture of QUBIP Internet Browsing Pilot
Akif Mehmood (Tampere University)
17/12/2025
Over the past two years, the QUBIP project has steadily advanced its mission to prepare real-world systems for the post-quantum era. The work has spanned multiple pilots, research tracks, and technology stacks, all aimed at understanding precisely how Post-Quantum Cryptography (PQC) can be integrated into practical applications and existing infrastructures. To place this blog post in context:
- Last year, we presented our plan for transitioning Firefox and NSS to support PQC using a shallow loadable module approach.
- This summer we demonstrated in the Quantum-Secure Internet Browsing Pilot how a post-quantum hybrid (PQ/T) TLS 1.3 connection can be established between a client and a server.
We continue our discussion today by focusing on the client-side perspective of the Quantum-secure Internet Browsing (IB) pilot, demonstrating our achievements in providing quantum-secure browsing while maintaining the normal user experience.
General Overview of the System-Level Architecture
Our current implementation adheres to the architectural plan originally outlined in our first blog post, and the fundamental goals remain unchanged. At the center of this client-side effort is Mozilla Firefox, an open-source, multi-platform browser which serves as the user-facing application. To enable post-quantum security, we ship our own modified version of Firefox, the QUBIP’s Firefox, enhanced with the necessary capabilities.
The scope of our changes is intentionally limited. We aim not to modify the whole Firefox codebase itself, but only the necessary TLS-related configurations that allow the browser to correctly leverage its cryptographic core, NSS, which has been, instead, enhanced to support post-quantum and hybrid algorithms. NSS already implements the industry-standard Cryptoki API defined by PKCS#11 and can be configured to use external PKCS#11 modules to delegate any cryptographic operation.
By introducing our Rust-based module, qryptotoken (formerly the generic “QUBIP-NSS-Module”), the user can load it directly into NSS via Firefox. Once loaded, NSS uses it to provide quantum-secure capabilities for handling any cryptographic service related to the TLS protocol, such as key exchange or authentication. Since Firefox delegates the implementation of the TLS protocol to NSS, and NSS, in turn, delegates the core cryptographic functions to our module, we implicitly enable Firefox for quantum-secure browsing.
How qryptotoken Integrates with Firefox’s NSS
qryptotoken is provided to the user as a shared library (libqryptotoken_pkcs11.so) that can be interactively loaded in NSS at runtime via Firefox’s “Security Devices” settings.
Upon load, qryptotoken registers all the available post-quantum/hybrid PKCS#11 mechanisms, including all targeted KEMs and signature algorithms.
NSS maintains a persistent reference to our module for handling all the advertised post-quantum algorithms. When it comes time to use these PQ algorithms, every cryptographic operation, ranging from key encapsulation/decapsulation to digital signing/verification, is executed by invoking our module through the standard Cryptoki API.
On the other hand, the classical cryptographic operations continue to be handled by NSS’s internal module. This clear separation preserves full interoperability within NSS itself.
It’s worth noting that qryptotoken is developed as a “shallow module”, a concept we have already detailed in our initial blog post. The module itself does not contain the algorithm implementations; instead, qryptotoken delegates the computation to third-party libraries that provide the actual algorithm implementation.
This architecture ensures that we maintain full cryptographic agility going forward, allowing us to easily swap cryptographic backends and adapt rapidly as the post-quantum standardization landscape evolves toward full maturity.
All Targeted PQ and Hybrid Algorithms Supported
Below, we report all the currently supported post-quantum/hybrid algorithms exposed by qryptotoken, and actively engaged by Firefox’s NSS in the TLS handshake and certificate chain validation.
Key Exchange
| Algorithm | CKM_* (Hex) |
CKM_*_KEY_PAIR_GEN (Hex) |
CKK_* (Hex) |
CKP_* (Hex) |
Notes |
|---|---|---|---|---|---|
| ML-KEM-768 | 0xCE534381 |
0xCE534380 |
0xCE534356 |
0xCE534352 |
NSS vendor-defined |
Currently, x25519mlkem768 is natively supported in Firefox as the only PQ/T Hybrid key exchange group in the TLS handshake. The hybrid key exchange is handled internally by NSS, with its own application-level combiner implementation to delegate the underlying operations (i.e., traditional X25519 and post-quantum ML-KEM-768) to PKCS#11 tokens. This hybrid setup already protects against Harvest Now Decrypt Later (HNDL) attacks, since the private keys are short-lived, and forward secrecy ensures that stored encrypted traffic cannot be decrypted later.
In terms of PKCS#11 support, ML-KEM-768 is defined in upstream Firefox (and NSS) as a vendor-defined mechanism in the NSS namespace and exposed by qryptotoken under the same namespace to be actively used in the key exchange process.
While upstream Firefox already supports hybrid KEMs, aligning with world-wide efforts to mitigate the HNDL attack strategy, QUBIP is pioneering the transition to post-quantum/hybrid digital signatures in real-world web scenarios. We cover not only a TLS handshake’s quantum-secure authentication but also the establishment of digital trust across an entire post-quantum PKI chain.
By doing so, we directly address the Trust Now, Forge Later (TNFL) threat, which is as significant as HNDL attack. TNFL allows an attacker to forge traditional signatures that we trust today once cryptographically relevant quantum computers become available. This could make tampered documents and malicious software appear authentic, because the systems that do not support PQC signatures will be unable to establish trust. Our effort demonstrates that while HNDL is largely mitigated for key-exchange in TLS 1.3, securing authentication with PQC signatures is now critical for maintaining long-term digital trust.
Digital Signatures
| Algorithm | OID | IANA TLS SignatureScheme ID | CKM_* (Hex) |
CKM_*_KEY_PAIR_GEN (Hex) |
CKK_* (Hex) |
CKP_* (Hex) |
PQ/T Hybrid |
|---|---|---|---|---|---|---|---|
| ⚠️ ML-DSA-44 | 2.16.840.1.101.3.4.3.17 |
0x0904 (2308) |
0xCE534546 |
0xCE534545 |
0xCE534544 |
0x00000001 |
❌ Pure-PQC |
| ⚠️ ML-DSA-65 | 2.16.840.1.101.3.4.3.18 |
0x0905 (2309) |
0xCE534546 |
0xCE534545 |
0xCE534544 |
0x00000002 |
❌ Pure-PQC |
| ⚠️ ML-DSA-87 | 2.16.840.1.101.3.4.3.19 |
0x0906 (2310) |
0xCE534546 |
0xCE534545 |
0xCE534544 |
0x00000003 |
❌ Pure-PQC |
| MLDSA65-Ed25519-SHA512 | 1.3.6.1.5.5.7.6.48 |
0x090B (2315) |
0xCE53454C |
0xCE53454B |
0xCE53454A |
None | ✅ Composite |
| SLH-DSA-SHAKE-128S | 2.16.840.1.101.3.4.3.26 |
0x0917 (2327) (disabled) |
0xCE534549 |
0xCE534548 |
0xCE534547 |
0x00000002 |
❎ Exempt |
| SLH-DSA-SHAKE-128F | 2.16.840.1.101.3.4.3.27 |
0x0918 (2328) (disabled) |
0xCE534549 |
0xCE534548 |
0xCE534547 |
0x00000004 |
❎ Exempt |
| SLH-DSA-SHAKE-192S | 2.16.840.1.101.3.4.3.28 |
0x0919 (2329) (disabled) |
0xCE534549 |
0xCE534548 |
0xCE534547 |
0x00000006 |
❎ Exempt |
| SLH-DSA-SHAKE-192F | 2.16.840.1.101.3.4.3.29 |
0x091A (2330) (disabled) |
0xCE534549 |
0xCE534548 |
0xCE534547 |
0x00000008 |
❎ Exempt |
| SLH-DSA-SHAKE-256S | 2.16.840.1.101.3.4.3.30 |
0x091B (2331) (disabled) |
0xCE534549 |
0xCE534548 |
0xCE534547 |
0x0000000A |
❎ Exempt |
| SLH-DSA-SHAKE-256F | 2.16.840.1.101.3.4.3.31 |
0x091C (2332) (disabled) |
0xCE534549 |
0xCE534548 |
0xCE534547 |
0x0000000C |
❎ Exempt |
ⓘ Note:
The table above lists all DSA algorithms currently supported. While pure ML-DSA algorithms are supported in both NSS and qryptotoken, the NSS version shipped with QUBIP’s Firefox will mark the pure ML-DSA variants as disabled by default. Users can explicitly enable them from QUBIP’s Firefox settings for experimentation purposes only.
This choice follows current transition guidance, particularly from European recommendations, favoring hybrid or composite post-quantum signatures. It also reflects the prevailing view among conservative security practitioners that PQC should, for now, be deployed primarily within hybrid constructs.
Hybrid/composite schemes provide stronger security margins for end-users in case a PQC algorithm or its implementation is later found vulnerable. This is why QUBIP’s Firefox utilizes only composite solutions by default, while keeping pure ML-DSA available only as an opt-in mechanism for testing and evaluation.
The chosen signature algorithms for the client side reflect both EU transition guidance and practical deployment needs. Each algorithm is implemented in qryptotoken and managed through a dedicated interface of what we refer to as adapters, which wrap external third-party cryptographic libraries.
Currently, we support only a single adapter for each algorithm implementation, but we aim to support more in the future. From a PKCS#11 perspective, all signature algorithms are registered under our vendor-defined namespace, which is recognized by Firefox’s NSS.
As part of our commitment to experimenting with composite signature algorithms, we currently support only MLDSA65-Ed25519. This composite algorithm, among others, has been finalized in version 13 of the IETF draft specification. Note that PKCS#11 version 3.x does not currently define any type of composite algorithm. We implemented this algorithm in qryptotoken following a hypothetical implementation use-case derived from algorithms standardized in version 3.2, such as ML-DSA or SLH-DSA.
In the general TLS use-cases, adopting SLH-DSA for signing the handshake transcript is not recommended. Our Firefox’s NSS supports the registered IANA TLS SignatureScheme codepoints for SLH-DSA, but this functionality is currently disabled. Moreover, in QUBIP’s Internet Browsing Pilot we do not use SLH-DSA for End-Entity certificates.
SLH-DSA is implemented only at the PKCS#11 level and is registered and exposed by qryptotoken. Its primary purpose, in the pilot system, is for signature verification during the certificate chain validation process. This is because our own PKI is rooted in SLH-DSA-SHAKE-256s, which is used to sign the intermediate TLS CA certificates. The intermediate CA, which in turn issue End-Entity certificates, utilizes composite ML-DSA signatures.
What Changed From the Last Internet Browsing Pilot
In the first Internet Browsing Pilot presented this summer, we successfully demonstrated a full PQ/T TLS 1.3 connection using ML-DSA-65 as our primary test algorithm for authentication. Moving forward, while we extended support to all other pure ML-DSA parameter sets, we prioritized Composite ML-DSA as the default in our pilot.
Given the current implementation status of qryptotoken and the latest advancements in our aurora OpenSSL provider (used on the server side of the IB pilot), the client side is now fully capable.
Specifically, the client can now test the latest composite signature standardization efforts from the IETF Working Group in a real-world use case that fully incorporates our PKI hierarchy, which is built using these composite algorithms.
As discussed above, we avoid pure ML-DSA deployments in favor of composite solutions and consistently recommend this approach. Pure ML-DSA will remain available but will eventually be disabled by default in NSS and conditionally enabled in QUBIP’s Firefox only by experimental users for specific testing purposes.
Upstream contributions
The last cycle was marked by concrete upstream contributions. NSS, being a standalone library, is taking clear directions for PQC support, and some of our contributions have been successfully integrated: ML-DSA partial support landed in NSS 3.116.
However, Firefox’s roadmap for enabling post-quantum TLS signature algorithms into upcoming releases remains undefined. Our ML-DSA patches for Firefox are currently proceeding through a slow Bugzilla review process.
Beyond our upstream contributions to NSS, we also engage with other open-source projects. Specifically, we enhanced the cryptographic test coverage for post-quantum algorithms in wycheproof-rs, a Rust crate for testing Wycheproof vectors. This work was crucial in assessing the cryptographic strength of our adapters and covering common corner cases in the code.
Next Steps
Building on this foundation, our next steps will introduce the second pilot’s use case: optional TLS 1.3 client authentication using PQ/T hybrid algorithms. Up until now, we have exclusively explored server-only authentication, both with our internal server-side implementation and through interoperability testing with web servers provided by projects like Open Quantum Safe and Cloudflare’s PQ research.
Quantum-secure TLS 1.3 client authentication is almost ready to land in our next pilot and will be made available and fully functional in the next release of the QUBIP’s Firefox.
The goal now is scale and confidence. With a stable PKCS#11 module, a compatible real-world browser, and working PQ/T hybrid TLS support, the client side is ready for wider pilots and integration with external systems. This marks a pivotal stage as the transition to post-quantum security moves toward reaching a large-scale audience and real-world deployment.
