Post-Quantum Cryptography

Post-quantum cryptography (PQC) provides algorithms designed to be secure against attacks by both classical and quantum computers. cryptopp-modern includes implementations of the NIST PQC standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205).

The Quantum Threat

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

Note: BLAKE3 is believed to retain adequate security margin under Grover, but is not a NIST standard. 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:

Don’t forget authentication: If you upgrade key exchange to PQC but keep authentication on classical signatures, a future quantum attacker could impersonate endpoints. Plan key exchange and authentication together.

Available Algorithms

Key Encapsulation (Key Exchange)

Digital Signatures

Choosing an Algorithm

For Key Exchange / Encryption

Need defence against both classical AND quantum attacks today?
├── YES → Consider X-Wing (hybrid X25519 + ML-KEM-768)
│         Aims to remain secure if either component remains secure
│         Good transition strategy while PQC matures
│         Note: X-Wing is still an IETF draft
│
└── 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)?
│   └── Use SLH-DSA
│       Based only on hash function security
│       Larger signatures (~17 KB) but different trust model
│
├── 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. SLH-DSA achieves small public keys (32-64 bytes) because hash-based schemes derive verification data from the signature itself—the tradeoff is very large signatures (8-50 KB).

Migration Strategy

Phase 1: Hybrid Mode (Recommended Now)

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

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

Benefits:

• Secure against both classical and quantum attacks
• If PQC algorithms have undiscovered weaknesses, classical algorithms provide backup
• Gradual transition without breaking compatibility

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):

Recommendation: Level 3 provides excellent security for most applications.

Quick Examples

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, but estimates range from 10-30 years for cryptographically-relevant quantum computers. The risk is that encrypted data captured today could be decrypted in the future.

Should I use PQC now?

For new applications with long-term security requirements, yes. Use hybrid approaches (X-Wing) to get the best of both worlds.

Are PQC algorithms slower?

Lattice-based algorithms (ML-KEM, ML-DSA) are reasonably fast—comparable to RSA. Hash-based signatures (SLH-DSA) are slower but offer conservative security assumptions.

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 - Hash-based signatures
• X-Wing API Reference - Hybrid key encapsulation
• Public-Key Cryptography - Classical algorithms