Post-quantum cryptography: SkyeConnex already ships both halves

Why "post-quantum" is two problems, not one

The phrase "post-quantum cryptography" hides a structural detail that matters when you're planning a migration: it refers to two largely separate classes of algorithm. Procurement teams that ask "are you post-quantum?" without specifying which half often end up disappointed by the answer.

The first half is key encapsulation: replacing the RSA and ECC algorithms used to wrap symmetric keys with quantum-resistant alternatives. NIST standardised this as ML-KEM (FIPS 203) in August 2024.

The second half is digital signatures: replacing RSA and ECDSA signatures with quantum-resistant alternatives. NIST standardised this as ML-DSA (FIPS 204), also in August 2024.

Both Canada's Cyber Centre PQC migration guidance and the NSA's CNSA 2.0 profile call out both halves separately. Migrating one without the other leaves a quantum adversary with viable attack paths.

What SkyeConnex ships

ML-KEM-1024 — Sovereign tier, in production

On the Sovereign tier, every data-encryption key (DEK) is wrapped with a composition of AES Key Wrap (SP 800-38F) and ML-KEM-1024 (FIPS 203). This is a hybrid construction: even a complete quantum break against ML-KEM still leaves AES standing. A quantum adversary with full visibility of every wrapped DEK we've ever produced still cannot read your data without also defeating AES-256.

ML-DSA-87 — every signed report, in production

As of platform v1.2, every signed report block and integrity certificate is dual-signed: HMAC-SHA-256 for the legacy online-verify round-trip (which preserves compatibility with existing customer integrations), and ML-DSA-87 for offline, quantum-resistant non-repudiation.

The dual-signature envelope carries six fields: algorithm (legacy single-algorithm field), algorithms (array enumerating both), signature (HMAC bytes), pq_signature (ML-DSA-87 signature bytes), pq_public_key (the issuer's ML-DSA-87 public key, embedded in-band), and pq_algorithm ("ML-DSA-87"). Migration story: HMAC stays for back-compat; the PQ signature is enforced when present.

The procurement question that's now answerable

"Can our security team verify your attestations without giving you a phone number?" — that question now answers itself. The platform publishes its full cryptographic posture at a public, no-auth URL: /security. The page is server-rendered, lists every algorithm in active use with its NIST/FIPS reference, and embeds the issuer's ML-DSA-87 verification public key both as a SHA-256 fingerprint (for pinning) and as the raw base64 key (for direct use with any FIPS 204 verifier).

A recipient of a SkyeConnex-signed integrity certificate can pin the platform's public-key fingerprint from the posture page, then verify any future signed report entirely offline: canonicalise the envelope as sorted-keys JSON and run verify(public_key, envelope_bytes, pq_signature). No call to the platform. Ever.

This is the difference between attestation and non-repudiation

HMAC signatures require the verifier to call back to the platform, because only the platform knows the secret. That is "trust us, the secret matches." With ML-DSA-87 and a published verification key, the platform genuinely cannot deny having issued a report, and the verifier never depends on the platform's availability or honesty to check.

This is the legal-evidentiary standard regulators and auditors actually look for — and increasingly, what procurement asks for too.

---

Published April 14, 2026 · Written by SkyeConnex Inc. · More from the SkyeConnex blog