Closing the last classical link in the quantum-safe chain

On 15 April we announced a proof-of-concept hybrid post-quantum FIDO2 authentication token. Here is what we actually built, why it matters for anyone running a key manager, and the unglamorous engineering that made ML-DSA fit on a dongle with 256 KB of RAM.

§1 — the gapPost-quantum has been a server story. Until now.

For two years, post-quantum cryptography has been a library-and-server conversation. Vendors — Cryptsoft included — have been steadily adding ML-KEM and ML-DSA to SDKs, certificate stacks, and KMIP servers. That work matters. It also ducks the uncomfortable question at the other end of the wire: how does the administrator log in?

FIDO2 and WebAuthn — the standards that quietly made password-less authentication mainstream — still sign with ECDSA P-256 or Ed25519. Both fall to a cryptographically relevant quantum computer. A patient adversary with "Harvest-Now, Decrypt-Later" storage can record today's authentication traffic and forge credentials against it a decade from now. For the operator of a key manager whose job is to protect everything else, that is the thread no one had pulled.

A quantum-safe key manager is only as strong as the signature on the token used to administer it. If the passkey that unlocks the HSM is classical, the PQC everywhere underneath it is doing half a job. Closing that gap is not optional for a KMIP vendor whose customers run critical infrastructure.

§2 — what we builtA commodity dongle, re-flashed, registered against a real KMIP server.

The proof of concept is deliberately concrete. A stock FEITIAN nRF52840 USB dongle — with Z711_G9_KE0B_V1.1 markings — runs a Cryptsoft-modified build of Google's OpenSK firmware. The classical signature path has been replaced with a memory-efficient Rust port of Bouncy Castle's bc-rust ML-DSA implementation, tuned for embedded targets.

Plug it into a Windows host. Open the Cryptsoft KMIP C Server's simpleui front-end in Firefox. Register a passkey against the administrator account. Tap the key to sign. Log out. Sign back in with the same tap. Every WebAuthn attestation and assertion on that wire is now carrying an ML-DSA signature computed on-device.

That single unremarkable click is the moment the loop closes: a quantum-safe key manager, operated by a human whose credentials are themselves quantum-safe.

Algorithm coverage

§3 — the hard partMaking ML-DSA fit on a dongle.

Bouncy Castle's bc-rust ML-DSA implementation was written for correctness and readability. On a server that is fine. On a dongle with roughly 256 KB of RAM — most of which OpenSK is already spending on its CTAP state machine, credential store, and USB stack — you cannot even hold the expanded signing state in one shot.

Our low_ram_2018 branch reworks the three hot paths — key generation, signing, verification — with a discipline more like a streaming encoder than a cryptographic library.

• {{ h }}

This approach has a pedigree: the original OpenSK hybrid-PQC research branch applied the same streaming trick to an older, pre-standardisation variant of Dilithium. What we have done is carry it across the NIST standardisation boundary — onto standardised bc-rust ML-DSA code, at all three FIPS 204 security levels.

// Streaming ML-DSA signer for a RAM-constrained target. No expanded
// private-key state is held; rows of A are regenerated on demand, and
// the signature is packed directly into the output buffer.
pub fn sign_stream(
    sk_seed: &[u8; 32],
    tr:      &[u8; 64],
    msg:     &[u8],
    params:  &MlDsaParams,
    out:     &mut [u8],
) -> Result<usize, Error> {
    let mu = Shake256::init_absorb(tr, msg).finalize_64();
    let (rho, rho_prime, k_seed) = expand_sk_seed_incremental(sk_seed);
    'rejection: loop {
        let y = sample_y_streaming(&rho_prime, params);
        let mut w_hash = Shake256::init();
        // Row-by-row NTT(A) * NTT(y); each A-row regenerated from (rho,i,j).
        for i in 0..params.k {
            let mut w_i = Poly::zero();
            for j in 0..params.l {
                let a_ij = sample_a_row(&rho, i, j);   // never stored
                w_i.add_mul_ntt(&a_ij, y.poly(j));
            }
            w_i.inv_ntt_in_place();
            w_hash.absorb_poly(&high_bits(&w_i, params.gamma2));
        }
        let c_tilde = w_hash.finalize(params.c_tilde_bytes);
        // z and the hint bitmap are packed straight into `out`.
        let (z_len, ok) = pack_z_or_reject(&c_tilde, &rho_prime, params, out);
        if !ok { continue 'rejection; }
        return Ok(params.c_tilde_bytes + z_len);
    }
}

The payoff: ML-DSA-44 and ML-DSA-65 sign and verify comfortably inside the OpenSK runtime budget. ML-DSA-87 builds, links, and flashes — but is currently non-functioning on Windows.

§4 — the demo, click by clickA FEITIAN dongle, a browser, and a quantum-safe login.

The end-to-end flow is the same three steps any FIDO2 enrolment takes, with ML-DSA silently doing the signing underneath.

{{ st.num }}

{{ st.head }}

{{ st.body }}

§5 — why hybrid, not pure PQCHybrid is a product; pure is a research artefact.

"Hybrid" is deliberate. Cryptographic transitions are long, lossy, and full of unknowns. A pure ML-DSA-only token would be a fine research artefact but a poor product. ML-DSA is new; any post-standardisation weakness discovered in the next few years would brick every token registered with it. Classical FIDO2 ecosystems still assume ECDSA or Ed25519 is available. And regulators are signalling hybrid as the expected migration path, not a direct cut-over.

In a hybrid credential, the token carries both a classical and a post-quantum signature. The server checks both. An attacker who breaks one still has to break the other. If either algorithm is ever deemed insufficient, the other keeps the credential valid while the population re-enrols.

§6 — why customers should careThe compliance question, getting louder.

For a KMIP server customer — financial services, government, telco, cloud-adjacent enterprise — the shift is already visible in audits. "We use ML-KEM for our data at rest" is no longer a complete answer. Auditors want to know how administrators log in, too. Regulators — NIST SP 800-131A, BSI TR-02102, CNSA 2.0, ANSSI — are naming specific PQC algorithms and decommissioning dates for classical asymmetric crypto.

What this POC gives a customer today:

• {{ g }}

§7 — what is publicPublic repos, and where the rest lives.

The firmware and the memory-efficient Rust crypto port are both on public GitHub. The KMIP server, client library, and admin UI forks live on Cryptsoft's internal GitHub Enterprise; talk to us for access under NDA.

§8 — what's nextFrom POC to product.

The POC proves the stack tolerates ML-DSA end-to-end — the hardware exists, the firmware fits, the server accepts the credential, and the administrator experience is a single tap. If you administer a Cryptsoft KMIP C Server today and want to pilot a hybrid-PQC passkey against your own environment, that conversation is already open.