Reports, whitepapers, datasheets, guides - every entry is a real artifact.

ML-KEM · Kyber · CRYSTALS-Kyber

Module-Lattice-based Key Encapsulation Mechanism. NIST's primary post-quantum KEM standard, finalised as FIPS 203 in August 2024. Three parameter sets (512, 768, 1024) at NIST security levels 1, 3, and 5. QNSI default KEM in every tier.

ML-DSA · Dilithium · CRYSTALS-Dilithium

Module-Lattice-based Digital Signature Algorithm. NIST's primary post-quantum signature standard, finalised as FIPS 204 in August 2024. Three parameter sets (44, 65, 87). Used by QNSI for JWT signing, audit-chain Merkle-root sealing, and CBOM attestation.

SLH-DSA · SPHINCS+

Stateless Hash-Based Digital Signature Algorithm. NIST's hash-based signature standard, finalised as FIPS 205 in August 2024. Twelve parameter sets across SHA2 / SHAKE hash families. Conservative security based solely on hash-function strength - used by QNSI on Government tier when lattice assumptions are not acceptable.

FN-DSA · Falcon

FFT-over-NTRU-Lattices Digital Signature Algorithm. NIST signature standard scheduled as FIPS 206 (draft). Two parameter sets (512, 1024). Smaller signatures than ML-DSA, used by QNSI for code-signing and TLS certificates where on-wire size matters.

HQC

Hamming Quasi-Cyclic. NIST-selected code-based KEM (March 2025). Three parameter sets (128, 192, 256). Not currently offered by QNSI: liboqs disables HQC by default pending its corrected 2025-spec implementation (an unresolved design flaw, CVE-2025-48946), so QNSI ships code-based backups via Classic McEliece and BIKE instead.

Classic McEliece

Code-based KEM from a 1978 cryptosystem with the longest cryptanalytic track record of any NIST candidate. Very large public keys (~261 KB at level 5) but very small ciphertexts (~96 bytes). NIST Round 4 finalist; QNSI supports it for HNDL-conservative deployments.

BIKE

Bit Flipping Key Encapsulation. NIST Round 4 KEM finalist, code-based, balanced key-size vs ciphertext-size. Three parameter sets (L1, L3, L5).

FrodoKEM

Plain Learning-with-Errors KEM without the algebraic structure of ML-KEM. Larger but conservative - selected by BSI (German government) for high-assurance applications.

MAYO

Multivariate signature scheme from NIST's onramp signature competition. Smaller signatures than ML-DSA, larger public keys.

PQC · Post-Quantum Cryptography

Cryptography designed to resist attack by both classical and quantum computers. Distinct from quantum cryptography (which uses quantum mechanics to transmit keys, e.g. QKD). All four NIST standards (FIPS 203/204/205/206) are PQC - they run on classical hardware and resist quantum attack.

CRQC · Cryptographically Relevant Quantum Computer

A quantum computer capable of breaking RSA-2048 or equivalent classical cryptography. No authoritative arrival date exists. NIST transition guidance removes quantum-vulnerable algorithms by 2035, with high-risk systems moving earlier.

HNDL · Harvest Now, Decrypt Later

Adversary captures encrypted traffic today and stores it. When a CRQC arrives, every captured ciphertext is retroactively decryptable. Long-life records (medical, financial, classified, transcripts) are HNDL targets the moment they touch a wire.

KEM · Key Encapsulation Mechanism

A primitive that establishes a shared symmetric key between two parties without traditional public-key encryption. ML-KEM, HQC, BIKE, FrodoKEM, McEliece are all KEMs. Used to wrap AES-256-GCM data keys in QNSI vault + KMS.

Hybrid PQC · X25519MLKEM768

Composition of a classical KEM (X25519) and a PQC KEM (ML-KEM-768) where session security holds if either is unbroken. Standard for PQC TLS today - used by QNSI edge-gateway, AWS KMS, Google Cloud KMS, Cloudflare, and the major browsers.

Lattice-based cryptography

Cryptography whose security reduces to the hardness of problems on mathematical lattices (Learning With Errors, Module-LWE, NTRU). ML-KEM, ML-DSA, FN-DSA are all lattice-based. Most widely deployed PQC family in 2026.

Code-based cryptography

Cryptography whose security reduces to decoding random linear codes. McEliece (1978), HQC, BIKE, CROSS. Longest cryptanalytic track record of any PQC family.

Cryptographic agility · Crypto-agility

The architectural property that lets an organisation swap one cryptographic algorithm for another without changing application code or data-at-rest formats. QNSI crypto-policy tiers + KMS algorithm parameter implement this directly - application code calls `kms.encrypt(key)` and the policy decides which algorithm runs.

Cross-verification

Running the same cryptographic operation through two independent implementations and comparing results - defends against implementation bugs (not algorithm weakness). QNSI cross-verifies between liboqs (C/native) and @noble/post-quantum (pure-JS) on Maximum and Government tiers across the 18 algorithms shared by both providers.

FIPS 203

NIST Federal Information Processing Standard for ML-KEM. Final, published August 2024. Authoritative spec for ML-KEM-512 / 768 / 1024 parameter sets, key generation, encapsulation, and decapsulation procedures.

FIPS 204

NIST Federal Information Processing Standard for ML-DSA. Final, published August 2024. Authoritative spec for ML-DSA-44 / 65 / 87.

FIPS 205

NIST Federal Information Processing Standard for SLH-DSA. Final, published August 2024. Authoritative spec for SLH-DSA across SHA2 and SHAKE hash families.

FIPS 140-3

NIST standard for cryptographic MODULE validation (CMVP). Distinct from FIPS 203/204/205, which standardize ALGORITHMS. 8 connector implementations - 6 via PKCS#11 (AWS CloudHSM · Azure Dedicated HSM · Thales Luna · Entrust nShield · Utimaco CryptoServer · Marvell LiquidSecurity) and 2 via REST API (HashiCorp Vault Transit · Fortanix DSM). The generic PKCS#11 path is verified with SoftHSM, the Vault REST path is verified with a live Vault backend, and QNSI's shipped provider plus HSPK custody path are proven on AWS CloudHSM hsm2m.medium in FIPS mode. Named hardware is enabled only after per-deployment qualification. AWS CloudHSM can provide FIPS 140-3 Level 3 custody under Marvell Semiconductor, Inc.'s certificate #4703 only after the customer provisions and QNSI qualifies that service for the deployment. Native-PQC HSM and cloud-KMS products now exist; their algorithms, firmware, and validation scope vary. QNSI's current HSPK API supports ML-DSA-44/65/87 as a software signing compatibility path rooted in qualified HSM custody, while QNSI's 87-algorithm catalog is a broader software migration and interoperability surface.

CNSA 2.0 · Commercial National Security Algorithm Suite 2.0

NSA mandate to transition US National Security Systems to post-quantum algorithms. ML-KEM-1024, ML-DSA-87, SLH-DSA-256 are the CNSA 2.0 algorithm set. Compliance dates: 2030-2033 depending on system class. QNSI Government tier locks exactly to this algorithm set.

NIST ACVP · Automated Cryptographic Validation Protocol

NIST's automated protocol for testing cryptographic implementations against canonical test vectors. Run as part of the CAVP (Cryptographic Algorithm Validation Program). QNSI runs an ACVP-shaped conformance harness against both providers and publishes results at /verify/conformance with SHA-3-256 tamper-binding.

NIST SP 800-208

NIST Special Publication on stateful hash-based signatures (XMSS, LMS) - used for code-signing and firmware. QNSI supports the SLH-DSA family for these workloads.

NIST SP 800-90A/B/C

NIST Special Publications on random bit generation. 800-90A defines DRBG (deterministic generators); 800-90B defines entropy sources; 800-90C composes them into an RBG. QNSI entropy chain is documented at /security/entropy with citations to each.

MAS TRM · Monetary Authority of Singapore - Technology Risk Management

Singapore's regulator-grade IT risk framework for licensed financial institutions. Released January 2021. QNSI evaluates 10 MAS TRM controls live in audit-service. Live evaluation page at /security/compliance.

PDPA · Personal Data Protection Act (Singapore)

Singapore's data protection law (2012, revised 2021). QNSI evaluates 9 PDPA obligations including consent, purpose limitation, protection, retention, and breach notification.

DORA · Digital Operational Resilience Act (EU)

EU regulation covering ICT third-party risk and operational resilience for financial entities. Applies to insurers, asset managers, banks, payment providers. QNSI maps to DORA via its continuous compliance evidence chain.

CBOM · Cryptographic Bill of Materials

CycloneDX-compatible inventory of every cryptographic asset across an organisation's estate - algorithms, keys, certificates, TLS endpoints, code-signing keys. QNSI crypto-inventory-service exports CBOM with per-asset NIST classification and HNDL-exposure scoring.

BYOH · Bring Your Own HSM

Deployment model in which a capability-qualified customer HSM becomes the root of trust for QNSI KMS. Only after qualification may sign / wrap / unwrap operations be represented as executing inside the customer boundary. 6 connector implementations use PKCS#11 (AWS CloudHSM, Azure Dedicated HSM, Thales Luna, Entrust nShield, Utimaco CryptoServer, Marvell LiquidSecurity) and 2 use REST (HashiCorp Vault Transit, Fortanix DSM).

SSE-X · Searchable Symmetric Encryption with eXtended PQC

QNSI's searchable encryption layer - clients can query encrypted indexes without the server seeing plaintext. PQC-wrapped data keys protect the underlying AES-256-GCM symmetric encryption. Used in vault search, storage search, and encrypted vector search for RAG.

Crypto-policy tier

Per-tenant enforcement level that locks which PQC algorithms and parameter sets are allowed. Four tiers: default (all 87 algorithms), strict (FIPS-finalised KEMs + signatures), maximum (strongest parameter sets, cross-verification mandatory), government (CNSA 2.0 lock + HSM required). Defined in packages/security/src/crypto-policy.ts.

Audit chain

QNSI audit-service source defines hash chaining, SHA3-512 Merkle aggregation, and ML-DSA checkpoint signing. Complete ingestion from every producer, root publication, and reconstruction of each historical operation require deployment evidence and remain NOT VERIFIED until recorded.

Tenant isolation

QNSI source defines per-tenant keys, audit chains, policy, edge authorization, service identity, KMS scoping, and vault scoping. Complete isolation across synchronous, asynchronous, storage, cache, export, log, and support paths requires deployment-specific negative testing.