Post-Quantum Cryptography

Post-quantum cryptography (PQC) provides algorithms designed to be secure against attacks by both classical and quantum computers. cryptopp-modern implements the NIST PQC standards ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), along with the stateful hash-based signature schemes LMS/HSS from NIST SP 800-208.

The Quantum Threat

Quantum computers threaten the cryptographic algorithms that secure most of today’s internet:

For compliance-oriented applications, use SHA-256 or SHA-3.

Key point: Public-key cryptography based on factoring or discrete logarithms is vulnerable to quantum attack. Symmetric cryptography remains viable with 256-bit keys.

“Harvest Now, Decrypt Later”

Adversaries may be collecting encrypted traffic today, planning to decrypt it once quantum computers become available. Data with long-term confidentiality requirements should transition to PQC now:

Available Algorithms

Key Encapsulation (Key Exchange)

Digital Signatures

LMS/HSS is not a drop-in replacement for ordinary signature APIs. Signing state must be managed durably. See the LMS/HSS page for details.

Choosing an Algorithm

For Key Exchange

Need defence against both classical AND quantum attacks today?
├── YES → A hybrid approach may be appropriate
│         X-Wing (X25519 + ML-KEM-768) is one such design
│         Aims to remain secure if either component holds
│         Note: X-Wing remains an IETF draft, not a final standard
│
└── NO → Building a pure post-quantum system?
    ├── YES → Use ML-KEM-768 (FIPS 203)
    │         NIST standard, smaller than X-Wing
    │
    └── NO → Use X25519 (classical)
             Smallest keys, well-understood security

For Digital Signatures

What are your priorities?
├── Conservative security (no lattice assumptions)?
│   ├── Can you manage signer state reliably?
│   │   ├── YES, and signing volume is bounded
│   │   │   └── Consider LMS/HSS (SP 800-208)
│   │   │       Hash-only security, small signatures (~2.6 KB)
│   │   │       BUT: stateful, each signature consumes state
│   │   │
│   │   └── NO, or signing volume is unpredictable
│   │       └── Use SLH-DSA (FIPS 205)
│   │           Stateless, no state management needed
│   │           Larger signatures (~17 KB)
│   │
│   └── Not sure about state management?
│       └── Use SLH-DSA, safer default for most applications
│
├── Balanced performance and size?
│   └── Use ML-DSA-65
│       NIST standard (FIPS 204)
│       ~3.3 KB signatures, fast signing/verification
│
└── Maximum security level needed?
    └── Use ML-DSA-87 or SLH-DSA-256 variants
        256-bit security, larger keys and signatures

Size and Performance Comparison

Key Encapsulation

Digital Signatures

Sizes vary by parameter set. The SLH-DSA row shows the “fast” (f) variant; the “small” (s) variant trades signing speed for roughly half the signature size (~8 KB). SLH-DSA achieves small public keys (32-64 bytes) because hash-based schemes derive verification data from the signature itself.

Migration Strategy

Phase 1: Hybrid Mode (Common transition approach)

Use hybrid algorithms that combine classical and post-quantum cryptography:

• Key Exchange: X-Wing (X25519 + ML-KEM-768)
• Signatures: Consider dual signatures for some critical applications

Benefits:

• Secure against both classical and quantum attacks
• A well-designed hybrid approach can reduce transition risk if one component later proves weaker than expected
• Gradual transition without breaking compatibility

Note that swapping algorithm primitives is only part of the picture. Protocols such as TLS, SSH, and application-level formats each have their own PQC adoption timelines and integration details.

Phase 2: Pure Post-Quantum (Future)

Once PQC algorithms are thoroughly analysed and quantum computers become a near-term threat:

• Key Exchange: ML-KEM-768 or ML-KEM-1024
• Signatures: ML-DSA-65 or SLH-DSA

Security Levels

NIST defines security categories (often compared to AES work factors):

For many applications, Level 3 is a practical default, balancing security margin and size.

Quick Examples

For LMS/HSS usage examples, see the LMS/HSS API reference and the Stateful Signing Integration Guide. Stateful signing has different operational requirements from the examples below.

Hybrid Key Exchange with X-Wing

#include <cryptopp/xwing.h>
#include <cryptopp/osrng.h>
#include <cryptopp/secblock.h>

using namespace CryptoPP;

AutoSeededRandomPool rng;

// Recipient generates key pair
XWingDecapsulator recipient(rng);

// Share public key with sender
SecByteBlock publicKey(recipient.GetKey().GetPublicKeySize());
recipient.GetKey().GetPublicKey(publicKey.begin());

// Sender encapsulates
XWingEncapsulator sender(publicKey.begin(), publicKey.size());
SecByteBlock ciphertext(sender.CiphertextLength());
SecByteBlock sharedSecret(sender.SharedSecretLength());
sender.Encapsulate(rng, ciphertext.begin(), sharedSecret.begin());

// Recipient decapsulates
SecByteBlock recipientSecret(recipient.SharedSecretLength());
recipient.Decapsulate(ciphertext.begin(), recipientSecret.begin());
// sharedSecret == recipientSecret

// IMPORTANT: Treat sharedSecret as key material.
// Feed it into a KDF (e.g., HKDF), then use an AEAD
// (AES-GCM or ChaCha20-Poly1305) for data encryption.

Post-Quantum Signatures with ML-DSA

#include <cryptopp/mldsa.h>
#include <cryptopp/osrng.h>
#include <cryptopp/secblock.h>
#include <string>

using namespace CryptoPP;

AutoSeededRandomPool rng;

// Generate key pair
MLDSASigner<MLDSA_65> signer(rng);
MLDSAVerifier<MLDSA_65> verifier(signer);

// Sign a message
std::string message = "Important document";
SecByteBlock signature(signer.SignatureLength());
size_t sigLen = signer.SignMessage(rng,
    (const byte*)message.data(), message.size(),
    signature.begin());

// Verify the signature
bool valid = verifier.VerifyMessage(
    (const byte*)message.data(), message.size(),
    signature.begin(), sigLen);

// For protocols: define what you sign (context string,
// transcript hash, domain separation) to avoid cross-protocol attacks.

Common Questions

When will quantum computers break current cryptography?

Unknown. Estimates vary widely, and the real risk is that encrypted data captured today may be decrypted later if quantum capabilities improve.

Should I use PQC now?

For new applications with long-term confidentiality or authenticity requirements, often yes. A hybrid approach combining classical and post-quantum algorithms can be a practical transition strategy.

Are PQC algorithms slower?

Lattice-based algorithms such as ML-KEM and ML-DSA are generally practical on modern systems, with different size and performance trade-offs from RSA and ECC. Hash-based signatures (SLH-DSA, LMS/HSS) are slower but rely only on hash function security.

Why are PQC keys and signatures so large?

The mathematical structures that resist quantum attacks require more data to represent. This is a fundamental tradeoff for quantum resistance.

Standards Compliance

See Also

• ML-KEM API Reference - Key encapsulation
• ML-DSA API Reference - Digital signatures
• SLH-DSA API Reference - Stateless hash-based signatures
• LMS/HSS API Reference - Stateful hash-based signatures
• Stateful Signing Guide - State contract, backends, common mistakes
• X-Wing API Reference - Hybrid key encapsulation
• Public-Key Cryptography - Classical algorithms