QorTrace
AUDIT  ·  QORTRACE LABS

Hybrid Signature Transition Audit

The world's first audit for protocols mid-migration to a hybrid PQ+classical signature scheme.

Specialised audit for teams shipping a hybrid signature scheme (classical + PQ) — the migration pattern every serious chain and protocol will adopt before Q-Day. We score your combiner construction, domain separation, downgrade resistance, and witness ordering against NIST SP 800-208, ETSI TS 103 744, and the draft-ietf-pquip-hybrid-signature-spec. Deliverable: a signed Hybrid Posture Certificate verifiable on the public QorTrace registry.

See all services
Engagement
2–4weeks
Day-one staffing
Seniorled
Final artefact
Signedcert
SIGNED · VERIFIABLE

Every engagement ends with a registry-verifiable certificate.

Cryptographic Migration Certificate · signed PDF, embeddable SVG, hash on the QorTrace public registry.

See a sample
THE PROBLEM

Hybrid signatures break in ways your security audit can't see.

You're shipping a hybrid scheme — classical + post-quantum — and you're already doing the hardest thing in cryptography this decade. The bug class isn't reentrancy or overflow; it's a malformed combiner, a forgotten domain separator, or a downgrade path nobody noticed. A general security audit will sign off on your contract and never look at the combiner. We do nothing else.

WHAT YOU’LL RECEIVE

Signed deliverables. No handwave.

Every engagement ships against this fixed manifest. No scope-creep invoices, no surprise “phase 2” line-items. If we change the scope, we re-sign first.

01

Combiner soundness review

We classify your combiner (concatenation / strong-nest / AND-gate / OR-gate / nested-binding) and benchmark it against the patterns in NIST SP 800-208, ETSI TS 103 744 §6.1, and draft-ietf-pquip-hybrid-signature-spec.

02

Domain-separation audit

Every signature scheme should sign over a domain-tagged message. We find every place you forgot one, and write the fix.

03

Downgrade-resistance threat model

We walk every code path that could fall back to classical-only — version negotiation, legacy compat, error handling, feature flags. Each one is a Critical finding until you close it.

04

Witness-ordering + malleability analysis

Canonical witness order, encoded scheme tags, signature malleability under (classical_sig, pq_sig) tuple permutation — analysed and patched.

05

Hybrid Posture Score (0–100) + signed certificate

Deterministic, methodology-citable score. SVG + PDF certificate verifiable on qortrace.com/verify/<id>. Embeddable badge for your docs site.

06

NIST / ETSI / IETF compliance mapping

Every finding linked to the specific standard clause. Hand to your regulator unchanged.

THE STACK WE WORK IN

What we’re actually shipping into your stack.

The post-quantum migration is not a slide — it’s a specific set of standards, libraries, and key-management primitives. Below is what we touch on every engagement, why it exists, and what it protects you against.

NIST FIPS 203

ML-KEM (Kyber) · key encapsulation

The lattice-based key-exchange standard NIST finalised in August 2024. Replaces ECDH on every TLS 1.3 handshake, every IPsec tunnel, every messaging-app key wrap. We integrate the FIPS-203 module ML-KEM-768 by default (Level 3 security · ~256-bit classical · quantum-resistant).

REQUIRES
OpenSSL 3.x or BoringSSL with oqs-provider · TLS endpoint owner-of-record · 90-day rotation runbook
PROTECTS
Harvest-Now-Decrypt-Later: every byte your customers send today, recorded by an adversary today, decrypted in 2034 once Shor's-capable hardware exists
NIST FIPS 204

ML-DSA (Dilithium) · digital signature

The lattice-based signature standard. Replaces RSA-PSS and ECDSA on code-signing, document-signing, and TLS server authentication. We deploy ML-DSA-65 (Level 3) for transitional dual-signing alongside the classical algorithm during the migration window — never replace, always co-sign first.

REQUIRES
Sigstore / Cosign or in-house signer · code-signing CI/CD · 365-day key rotation
PROTECTS
Forged software updates, forged firmware, forged TLS server certs — every place a quantum-attacker would impersonate your build pipeline
POLICY · CNSA 2.0

NSA Commercial National Security Algorithm Suite v2

The U.S. federal mandate: PQC primitives operational across National Security Systems by 2030, exclusive by 2035. Defines the exact KEM (ML-KEM-1024) and signature (ML-DSA-87) profile used at NSS-grade and the migration-pace expected from contractors. Every Cryptographic Migration Certificate we issue carries an explicit CNSA 2.0 attestation block.

REQUIRES
FIPS-140-3 validated module (or FIPS-203/204 module-pending) · auditable inventory · documented sunset plan
PROTECTS
Federal contract eligibility post-2030 · DoD / IC supplier status · DORA + EO 14028 alignment
BRIDGE · HYBRID

X25519 + ML-KEM · hybrid key exchange

The transitional posture every serious PQC rollout uses: combine a battle-tested classical primitive (X25519, the Curve25519 ECDH variant — or X448 at higher security level) with the post-quantum KEM in a single key-derivation step. If either side breaks, the other still holds. Browsers shipped this in 2024 (Chrome “X25519MLKEM768” group); we operationalise it for your endpoints.

REQUIRES
TLS 1.3 stack · OpenSSL 3.2+ or BoringSSL · negotiation telemetry to confirm hybrid-group adoption
PROTECTS
Day-1 deployment risk: a flaw in either ML-KEM or X25519 alone does not break your traffic — only a flaw in BOTH simultaneously could
TOOLING

oqs-provider · OpenSSL provider

The Open Quantum Safe project’s OpenSSL 3.x provider that exposes ML-KEM, ML-DSA, SLH-DSA, and the hybrid groups as first-class crypto algorithms inside any application that already speaks OpenSSL. We do not maintain a private fork — we ship upstream patches and point your CI at a reproducible build with a pinned commit.

REQUIRES
OpenSSL 3.2+ · CMake 3.18+ · liboqs build chain · application-side config update
PROTECTS
Vendor-lock-in to a single PQC library · drift between staging and production crypto behaviour
TOOLING · CORE

liboqs · post-quantum primitive library

The C library underneath everything else — implementations of every PQC candidate that ever entered NIST’s evaluation, including the four standardised winners (ML-KEM, ML-DSA, SLH-DSA, FN-DSA). Audited, side-channel-aware, and the de-facto reference for open-source PQC. We pin the version, we record the commit hash, and the hash makes it onto your migration certificate.

REQUIRES
C99 toolchain · OpenSSL or mbedTLS for symmetric primitives
PROTECTS
Implementation-bug exposure: a verified-pinned build is the difference between ‘we ran ML-KEM’ and ‘we ran a known-bad ML-KEM’
RUNTIME

OpenSSL 3.x · with PQC providers loaded

The version line that gives us providers (modular crypto), proper FIPS module isolation, and the runtime negotiation hooks needed to ship hybrid TLS without a fork. We standardise every engagement on OpenSSL 3.2+ and surface the version on the certificate so auditors don't need to grep your container builds.

REQUIRES
Operating system upgrade if pinned to OpenSSL 1.x (RHEL 7, Ubuntu 18.04 etc.) · runtime config rebuild
PROTECTS
PQC drift across services — one binary on 3.2 negotiating hybrid, another on 1.1 silently falling back to classical-only
KMS

AWS KMS · GCP KMS · Azure Key Vault · Thales / Entrust HSM

Where your most sensitive keys actually live. Every cloud KMS now exposes ML-KEM and ML-DSA key types (AWS “ML_KEM_768”, GCP “PQ_SIGN_ML_DSA_65”, Azure “ML-KEM”), and on-premise HSMs from Thales and Entrust ship FIPS-203/204 firmware lines. We map your existing key inventory, design the wrap-and-rotate path, and ship the runbook your SRE team executes — without you ever exposing key material outside the boundary.

REQUIRES
Cloud account audit access · HSM administrator credential · IAM separation between operator and rotator
PROTECTS
Cross-region replication, backup/restore, and disaster-recovery flows breaking silently when a primary key migrates and a secondary doesn’t
FREQUENTLY ASKED

Before you book the call.

Why is this its own audit type?
Because hybrid signature constructions are a new bug class with new failure modes that did not exist before NIST FIPS 204 landed. A general smart-contract audit firm will tell you they don't scope cryptographic-construction review — and they shouldn't, because doing it well requires a different skill set. We're the firm built specifically for this.
What languages do you cover?
Solidity, Vyper, Move (Aptos, Sui), Rust (Solana / Anchor / Substrate), Go, TypeScript (for off-chain verifiers), and the FFI bridge code that calls into liboqs / OpenSSL OQS / BoringSSL-PQ. If you've wired ML-DSA into something, we can audit it.
What if I haven't picked a PQ algorithm yet?
Then Deep Dive is the right tier. We work with you to pick ML-DSA-65 vs SLH-DSA-128s vs Falcon-512 based on your gas budget, signature-size constraints, and stateful-key feasibility — then we audit the integration after you ship it.
How does the certificate verify on-chain?
The certificate carries a methodology-signed JWT plus a hash of the source manifest. A simple ERC-1271-style verifier can attest to it from your contract; we provide reference code. We deliberately do NOT replace your general security audit — our cert is meant to stack alongside it.
What's the turnaround?
Standard: 2 weeks. Deep Dive: 4 weeks. Both include a 30-minute walkthrough call with the auditor and one round of remediation review at no charge.

Ready to scope hybrid signature transition audit?

One business day to a senior engineer. Fixed-fee scoping memo within five business days. NDAs available on request.

Back to QorTrace Labs