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.
CTRL K
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.
SIGNED · VERIFIABLE
Every engagement ends with a registry-verifiable certificate.
Cryptographic Migration Certificate · signed PDF, embeddable SVG, hash on the QorTrace public registry.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
Cookies & privacy
We use strictly-necessary cookies to run the app. With your consent we also use analytics cookies to understand how QorTrace is used so we can improve it. Cookie Policy · Privacy Policy