Knowledge Base

## The Quantum Threat Current public-key cryptography (RSA, ECDSA, ECDH) relies on the difficulty of factoring large numbers or computing discrete logarithms. Shor's algorithm, running on a cryptographically relevant quantum computer (CRQC), can solve these problems in polynomial time. **Timeline estimates for CRQC:** - Conservative: 2035-2040 - Aggressive: 2030-2035 - Current state: ~1,000 logical qubits (need ~4,000+ for RSA-2048) ## Harvest Now, Decrypt Later (HNDL) Adversaries are already collecting encrypted data today with the intent to decrypt it once quantum computers become available. This is called "harvest now, decrypt later" (HNDL) and affects any data with long-term confidentiality requirements. ## NIST PQC Standardization The National Institute of Standards and Technology (NIST) ran a multi-year competition to standardize post-quantum algorithms: - **2016**: NIST announces PQC standardization process - **2017**: 69 submissions received - **2022**: First algorithms selected (Kyber, Dilithium, SPHINCS+, FALCON) - **2024**: FIPS 203, 204, 205 published as final standards - **2025**: FIPS 206 (FALCON) expected ## Algorithm Categories 1. **Lattice-based**: ML-KEM, ML-DSA, FN-DSA (most efficient, smallest keys) 2. **Hash-based**: SLH-DSA (conservative, well-understood security) 3. **Code-based**: Classic McEliece, BIKE, HQC (large keys, fast operations) 4. **Multivariate**: MAYO, UOV (small signatures, specialized use) 5. **Isogeny-based**: SIKE (broken in 2022, not recommended)

## Overview ML-KEM is a key encapsulation mechanism (KEM) that allows two parties to establish a shared secret over an insecure channel. It replaces classical key exchange protocols like ECDH and RSA-KEM. ## Parameter Sets | Parameter Set | Security Level | Public Key | Ciphertext | Shared Secret | |---------------|----------------|------------|------------|---------------| | ML-KEM-512 | NIST Level 1 | 800 bytes | 768 bytes | 32 bytes | | ML-KEM-768 | NIST Level 3 | 1,184 bytes| 1,088 bytes| 32 bytes | | ML-KEM-1024 | NIST Level 5 | 1,568 bytes| 1,568 bytes| 32 bytes | ## Security Basis ML-KEM's security is based on the hardness of the Module Learning With Errors (MLWE) problem. No known quantum algorithm provides a significant speedup for solving MLWE. ## Use Cases - TLS 1.3 key exchange (hybrid with X25519) - Encrypted storage key wrapping - Secure messaging key agreement - VPN tunnel establishment ## QNSP Implementation QNSP uses ML-KEM-768 by default for: - PQC-TLS termination at the edge gateway - Envelope encryption for storage service - Key wrapping in KMS service - Session key establishment in auth service

## Overview ML-DSA is a digital signature algorithm that provides authentication and non-repudiation. It replaces classical signature schemes like RSA-PSS and ECDSA. ## Parameter Sets | Parameter Set | Security Level | Public Key | Signature | Secret Key | |---------------|----------------|------------|-----------|------------| | ML-DSA-44 | NIST Level 2 | 1,312 bytes| 2,420 bytes| 2,560 bytes| | ML-DSA-65 | NIST Level 3 | 1,952 bytes| 3,293 bytes| 4,032 bytes| | ML-DSA-87 | NIST Level 5 | 2,592 bytes| 4,595 bytes| 4,896 bytes| ## Security Basis ML-DSA combines the MLWE problem (for key generation) with the MSIS problem (for signature security). The Fiat-Shamir transform provides security in the random oracle model. ## Use Cases - Code signing and software updates - Document signing and notarization - API authentication tokens (JWT) - Certificate issuance and revocation - Audit log signing ## QNSP Implementation QNSP uses ML-DSA-65 by default for: - JWT signing in auth service - Audit event signing in audit service - Document metadata signing in storage service - API request authentication

## Overview SLH-DSA is a stateless hash-based signature scheme. Unlike lattice-based schemes, its security relies only on the properties of hash functions, making it a conservative choice for long-term security. ## Parameter Sets SLH-DSA offers many parameter sets trading off signature size, key size, and speed: | Variant | Security | Public Key | Signature | Use Case | |---------|----------|------------|-----------|----------| | SLH-DSA-SHA2-128s | Level 1 | 32 bytes | 7,856 bytes | Small keys | | SLH-DSA-SHA2-128f | Level 1 | 32 bytes | 17,088 bytes | Fast signing | | SLH-DSA-SHAKE-256s | Level 5 | 64 bytes | 29,792 bytes | High security | ## Security Basis SLH-DSA uses a hypertree of many-time signature schemes (FORS + WOTS+). Security reduces to the collision resistance and preimage resistance of the underlying hash function. ## Use Cases - Root certificate signing (long-term keys) - Firmware signing (conservative security) - Legal document signing (archival requirements) - Government/defense applications ## QNSP Implementation QNSP supports SLH-DSA for: - Long-term key signing in KMS service - Root of trust establishment - Compliance-critical document signing

## What are Hardware Enclaves? Hardware enclaves (also called Trusted Execution Environments or TEEs) use CPU features to create isolated memory regions. Code running inside an enclave is protected from: - The host operating system - The hypervisor/VMM - Other processes and VMs - Physical memory attacks (with encryption) ## Supported Enclave Technologies ### Intel SGX (Software Guard Extensions) - Memory Encryption Engine (MEE) - Enclave Page Cache (EPC) - Remote attestation via Intel Attestation Service - Best for: Small, security-critical workloads ### AMD SEV (Secure Encrypted Virtualization) - SEV-SNP (Secure Nested Paging) - Full VM encryption - Memory integrity protection - Best for: Lift-and-shift confidential VMs ### AWS Nitro Enclaves - Isolated compute environments - No persistent storage, no networking - Cryptographic attestation - Best for: Key management, sensitive data processing ### NVIDIA Confidential Computing - GPU memory encryption - Attestation for AI workloads - Best for: Confidential AI training/inference ## QNSP Enclave Integration QNSP's AI Orchestrator can deploy workloads to hardware enclaves: 1. **Attestation**: Verify enclave integrity before deployment 2. **Key provisioning**: Securely inject keys into enclave 3. **Sealed storage**: Persist encrypted state across restarts 4. **Audit logging**: Cryptographically signed execution logs

## Why Migrate Now? 1. **HNDL threat**: Data encrypted today may be decrypted by future quantum computers 2. **Compliance**: NIST, NSA, and regulators are mandating PQC timelines 3. **Long migration cycles**: Enterprise crypto migrations take 5-10 years 4. **Crypto agility**: Building PQC-ready infrastructure enables future flexibility ## Migration Phases ### Phase 1: Crypto Inventory - Discover all cryptographic assets (keys, certificates, algorithms) - Map data flows and encryption points - Identify quantum-vulnerable algorithms (RSA, ECDSA, ECDH) - QNSP's Crypto Inventory Service automates this discovery ### Phase 2: Risk Assessment - Classify data by sensitivity and retention period - Prioritize systems with long-lived secrets - Identify compliance requirements (FIPS, PCI-DSS, HIPAA) ### Phase 3: Hybrid Deployment - Deploy hybrid classical+PQC algorithms - Example: X25519 + ML-KEM-768 for key exchange - Maintains backward compatibility - Provides defense-in-depth ### Phase 4: PQC-Native - Transition to PQC-only where possible - Update certificates and PKI - Retire classical algorithms ## QNSP Migration Tools - **Crypto Inventory Service**: Automated discovery and tracking - **Policy Engine**: Enforce algorithm allowlists per tenant - **Hybrid TLS**: X25519+ML-KEM at edge gateway - **Migration Dashboard**: Track progress and compliance