Forem: Quantum Sequrity

Post-Quantum Encryption for Healthcare and HIPAA

Quantum Sequrity — Tue, 12 May 2026 13:00:10 +0000

Post-Quantum Encryption for Healthcare and HIPAA

Industry

Post-Quantum Encryption for Healthcare and HIPAA

11 min read

Healthcare Data: A High-Value, Long-Lived Target

Healthcare organizations store some of the most sensitive and long-lived data in any industry. Electronic protected health information (ePHI) includes medical diagnoses, treatment histories, genetic data, prescription records, and insurance details. Unlike a stolen credit card number that can be replaced in days, a compromised medical record exposes a patient permanently. The information it contains does not change: your medical history is your medical history for life.

This makes healthcare a prime target for sophisticated adversaries executing harvest-now, decrypt-later attacks. An attacker who captures encrypted ePHI today does not need to break the encryption immediately. They can store the ciphertext and wait for a cryptographically relevant quantum computer (CRQC) to become available. At that point, any data protected solely by RSA or elliptic curve key exchange becomes readable.

The financial impact of healthcare breaches is already severe. According to the IBM Cost of a Data Breach Report 2023, healthcare data breaches averaged $10.93 million per incident, the highest of any industry for the thirteenth consecutive year. Adding quantum-enabled retrospective decryption to the threat model makes proactive migration to post-quantum cryptography a matter of organizational survival.

HIPAA Encryption Requirements: What the Law Says

The Health Insurance Portability and Accountability Act (HIPAA) Security Rule establishes national standards for protecting ePHI. Two sections are directly relevant to encryption:

45 CFR 164.312(a)(2)(iv) -- Encryption and Decryption (Data at Rest): Covered entities must implement a mechanism to encrypt and decrypt ePHI. This is classified as an "addressable" specification under the Security Rule, meaning organizations must either implement it or document why an equivalent alternative is reasonable and appropriate.
45 CFR 164.312(e)(2)(ii) -- Encryption (Data in Transit): Covered entities must implement a mechanism to encrypt ePHI whenever deemed appropriate, particularly when transmitted over electronic communications networks.

The word "addressable" is frequently misunderstood. It does not mean optional. As the HHS Office for Civil Rights has clarified, covered entities that choose not to implement an addressable specification must document their rationale and implement an equivalent alternative measure. In practice, the vast majority of healthcare organizations implement encryption for both at-rest and in-transit ePHI because the risk of not doing so is indefensible.

Critically, HIPAA does not specify which encryption algorithms to use. It defers to NIST for cryptographic guidance. This means that as NIST standards evolve to address the quantum threat, the definition of adequate encryption under HIPAA evolves with them.

Why Healthcare Is Uniquely Vulnerable to Quantum Threats

Several characteristics make healthcare data exceptionally vulnerable to harvest-now, decrypt-later attacks:

Extended Retention Periods

HIPAA requires covered entities to retain medical records for a minimum of six years from the date of creation or the date when the record was last in effect. Many states impose longer requirements. For example, some states require retention of adult patient records for ten years or more after the last encounter, and pediatric records must often be kept until the patient reaches the age of majority plus additional years. In practice, many healthcare systems retain records indefinitely.

This creates a concrete problem: data encrypted today with RSA-2048 key exchange could be stored by an adversary and decrypted within the retention window. If a CRQC becomes operational within the next 10 to 15 years, records that are still legally required to exist will be retroactively exposed.

Lifetime Relevance of Patient Data

Unlike financial data that may lose value after a few years, medical records remain relevant and sensitive for a patient's entire life. Genetic data, chronic condition diagnoses, mental health records, and substance abuse treatment records can be used for discrimination, blackmail, or identity fraud decades after creation. A 30-year-old patient's records encrypted today could be decrypted and exploited when that patient is 45 or 50.

Interconnected Systems and Data Sharing

Modern healthcare relies on electronic health record (EHR) systems, health information exchanges (HIEs), telehealth platforms, and cloud-based analytics. ePHI is transmitted between hospitals, clinics, pharmacies, insurers, and laboratories. Each transmission is a potential capture point for a harvest-now, decrypt-later adversary. The key exchange mechanism used during these transmissions is the specific vulnerability that post-quantum cryptography addresses.

Current State: What Most Healthcare Organizations Use

The typical healthcare encryption stack today consists of:

AES-256-GCM or AES-256-CBC for symmetric encryption of data at rest
TLS 1.2 or 1.3 with RSA or ECDH key exchange for data in transit
RSA-2048 or RSA-4096 for key wrapping and digital signatures

The symmetric layer (AES-256) is not the problem. AES-256 is considered quantum-resistant because Grover's algorithm only reduces its effective security from 256 bits to 128 bits, which remains computationally infeasible. The vulnerability lies in the key exchange and digital signature layers. RSA and ECDH rely on mathematical problems (integer factorization and discrete logarithm) that Shor's algorithm, running on a CRQC, can solve efficiently.

This means an attacker who captures a TLS session encrypted with RSA key exchange can later extract the session key and decrypt all data in that session. The AES encryption is only as strong as the key exchange that established it.

The NIST Post-Quantum Solution: ML-KEM + AES-256-GCM

NIST finalized FIPS 203 (ML-KEM) in August 2024, providing a standardized post-quantum key encapsulation mechanism. The recommended approach for healthcare is a hybrid scheme that combines ML-KEM with a classical algorithm like X25519:

ML-KEM (FIPS 203) provides quantum-resistant key encapsulation based on the Module Learning With Errors problem
X25519 provides classical elliptic curve Diffie-Hellman key exchange, battle-tested since 2006
AES-256-GCM provides authenticated symmetric encryption of the actual data

In this hybrid model, an attacker must break both ML-KEM and X25519 to recover the encryption key. If a weakness is discovered in ML-KEM, X25519 still protects the data. If a quantum computer breaks X25519, ML-KEM still protects the data. This defense-in-depth approach is exactly what healthcare's risk profile demands.

For digital signatures on medical records and audit logs, FIPS 204 (ML-DSA) provides the post-quantum equivalent, again recommended in hybrid combination with Ed25519 for the same belt-and-suspenders security guarantee.

How QNSQY Addresses Healthcare Encryption Needs

QNSQY was designed with high-security, regulated environments in mind. Several capabilities are directly relevant to healthcare compliance:

Air-Gapped Encryption

QNSQY's CLI operates with zero network access for all cryptographic operations. On Linux, seccomp-bpf system call filtering blocks all network-related system calls at the kernel level. File content, passwords, and encryption keys never leave the machine. The only permitted network access is to the billing API (billing.quantumsequrity.com), and even that traffic is encrypted with a PQC envelope (ML-KEM-1024 + X25519 + AES-256-GCM). No ePHI is ever transmitted.

This architecture directly supports HIPAA's requirement to protect ePHI against unauthorized access. There is no cloud processing, no third-party key management, and no data exfiltration path through the encryption tool itself.

Audit Logging

HIPAA's administrative safeguards (45 CFR 164.312(b)) require audit controls to record and examine activity in information systems containing ePHI. QNSQY provides built-in audit logging that records all cryptographic operations: encryptions, decryptions, key generations, signature operations, and verification results. Logs can be exported for integration with existing SIEM platforms. Each log entry is integrity-protected to prevent tampering.

Hybrid Post-Quantum Encryption by Default

Every encryption operation in QNSQY uses hybrid ML-KEM + X25519 key encapsulation with AES-256-GCM symmetric encryption. This is not an optional setting that administrators might forget to enable. It is the default and only mode of operation. Even the free tier uses ML-KEM-512 + X25519, providing NIST Security Level 1 quantum resistance.

For healthcare organizations handling particularly sensitive data (genetic records, long-term patient archives), ML-KEM-768 and ML-KEM-1024 provide Security Levels 3 and 5 respectively.

Memory Protection

QNSQY uses mlock() to prevent encryption keys and passwords from being swapped to disk, and all sensitive memory is zeroized on drop. This addresses the HIPAA technical safeguard requirement for access controls on systems processing ePHI, extending protection to the memory layer where keys temporarily reside during cryptographic operations.

Compliance Framework Alignment

Healthcare organizations evaluating post-quantum encryption should consider alignment with these frameworks:

NIST SP 800-66 (HIPAA Security Rule Implementation)

NIST SP 800-66 provides detailed guidance for implementing the HIPAA Security Rule. It maps each HIPAA requirement to specific technical controls. Organizations adopting FIPS 203/204-compliant encryption can document this as their encryption implementation, satisfying the addressable specifications in 45 CFR 164.312.

NIST Cybersecurity Framework (CSF)

The NIST Cybersecurity Framework, widely adopted in healthcare, includes "Protect" functions covering data security. Migrating to post-quantum encryption aligns with the framework's emphasis on proactive risk management and its "Identify" function for assessing emerging threats. The quantum computing threat is precisely the kind of forward-looking risk that the CSF is designed to address.

HHS Enforcement and Breach Notification

The HHS Office for Civil Rights (OCR) enforces HIPAA and investigates breaches. Under the HIPAA Breach Notification Rule, data encrypted with NIST-compliant algorithms is considered "unsecured ePHI" only if the encryption is broken. Using quantum-resistant encryption reduces the risk that a future quantum attack will retroactively convert a non-breach into a reportable breach, potentially saving organizations from the financial and reputational damage of breach notification.

Migration Steps for Healthcare Organizations

Transitioning to post-quantum encryption does not require replacing all systems overnight. A practical migration follows these steps:

Inventory cryptographic assets. Identify all systems that process, store, or transmit ePHI. Document which encryption algorithms and key exchange mechanisms each system uses. This is the same cryptographic inventory recommended by OMB M-23-02 for federal agencies, and it is equally valuable for healthcare organizations.
Prioritize by data sensitivity and retention. Records with the longest retention requirements and highest sensitivity (genetic data, psychiatric records, pediatric records) face the greatest harvest-now, decrypt-later risk and should migrate first.
Start with data encryption at rest. Encrypting archived ePHI with a hybrid post-quantum tool like QNSQY is the lowest-friction first step. It does not require changes to network infrastructure, EHR systems, or existing workflows. Files can be re-encrypted individually or in batches.
Evaluate TLS migration. Migrating in-transit encryption to post-quantum TLS requires server and client support for ML-KEM-based key exchange. This is a longer-term project that depends on vendor adoption. In the meantime, encrypting sensitive files before transmission provides an additional layer of protection regardless of the transport encryption.
Document compliance decisions. Record the rationale for adopting post-quantum encryption, the algorithms selected, and the migration timeline. This documentation satisfies HIPAA's requirement to assess risks and implement appropriate security measures, and provides evidence of due diligence in the event of an OCR investigation.
Test and validate. Run the new encryption tools in a staging environment before production deployment. Verify that encrypted files can be decrypted, that audit logs capture all operations, and that performance is acceptable for your data volumes.

Start with the highest-risk data.
You do not need to migrate everything at once. Begin with long-retention, high-sensitivity records: genetic data, pediatric records, and psychiatric records. These face the greatest harvest-now, decrypt-later risk because they must be retained the longest and remain sensitive indefinitely.

The Cost of Waiting

Healthcare organizations that delay post-quantum migration face a compounding risk. Every day that ePHI is transmitted or stored using only classical key exchange, adversaries may be capturing that data. The captured ciphertext does not expire. It sits in storage, waiting for the day a CRQC can process it. The longer an organization waits to migrate, the larger the window of vulnerable data becomes.

Proactive migration is also significantly cheaper than reactive migration after a quantum-enabled breach. The $10.93 million average breach cost in healthcare does not account for the unprecedented scale of a retroactive quantum decryption event, where years of captured ciphertext could be decrypted simultaneously.

The Bottom Line

Healthcare's combination of long retention periods, lifetime-sensitive data, and strict regulatory requirements makes it one of the industries most vulnerable to harvest-now, decrypt-later attacks. HIPAA requires encryption of ePHI but does not specify algorithms, deferring instead to NIST standards. As NIST has now standardized post-quantum algorithms in FIPS 203 and FIPS 204, the definition of adequate encryption is evolving.

Organizations that adopt hybrid post-quantum encryption today protect their patients' data against both current and future threats. Those that wait risk a retroactive breach of every record encrypted with vulnerable key exchange mechanisms during the waiting period.

Protect Patient Data Against Quantum Threats

QNSQY provides HIPAA-aligned hybrid post-quantum encryption with air-gapped operation and audit logging.

Sources

45 CFR Part 164, Subpart C -- Security Standards for the Protection of Electronic Protected Health Information (U.S. Code of Federal Regulations)
NIST SP 800-66 Rev. 2 -- Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (NIST, February 2024)
FIPS 203 -- Module-Lattice-Based Key-Encapsulation Mechanism Standard (NIST, August 2024)
FIPS 204 -- Module-Lattice-Based Digital Signature Standard (NIST, August 2024)
NIST Cybersecurity Framework (NIST)
Cost of a Data Breach Report 2023 (IBM Security)
Breach Notification Rule (HHS Office for Civil Rights)

Originally published at quantumsequrity.com.

AES-256-GCM: Quantum-Safe Encryption

Quantum Sequrity — Mon, 11 May 2026 13:00:22 +0000

AES-256-GCM: Quantum-Safe Encryption

Security

AES-256-GCM: Why 256-Bit Encryption Survives Quantum Computers

15 min read

The Padlock on Everything You Do Online

Every time you visit a website with "https" in the address bar, buy something online, send a message through WhatsApp, or store a file in the cloud, your data is being scrambled by an encryption algorithm. More often than not, that algorithm is AES-256-GCM. It is the single most widely deployed encryption system on the planet. Banks use it. Governments use it. The military uses it. Your phone uses it right now, without you knowing, to protect the data on its storage chip.

But what is it, exactly? The name looks like an alphabet soup of letters and numbers. Let us break it down piece by piece, because understanding what protects your data is the first step toward making good decisions about security.

Breaking Down the Name: AES, 256, and GCM

The name "AES-256-GCM" has three parts, and each one matters.

AES stands for Advanced Encryption Standard. It is the encryption algorithm itself, selected by the U.S. National Institute of Standards and Technology (NIST) in 2001 after a five-year public competition. Fifteen candidate algorithms were submitted from research teams around the world. After multiple rounds of public analysis, an algorithm called Rijndael (designed by two Belgian cryptographers, Joan Daemen and Vincent Rijmen) won the competition. NIST published it as FIPS 197, the Federal Information Processing Standard for encryption. AES replaced the older DES (Data Encryption Standard), which had been the government standard since 1977 but had become too weak as computers got faster.

256 is the key size in bits. Think of the key as the secret combination to a lock. A 256-bit key means there are 2^256 possible combinations. That number is staggeringly large. To put it in perspective: there are roughly 2^80 atoms in the observable universe. The number of possible AES-256 keys is trillions upon trillions of times larger than the number of atoms in existence. There is no computer, and no collection of computers, that could try all those combinations before the heat death of the universe.

GCM stands for Galois/Counter Mode. AES by itself can only encrypt one small block of data at a time (128 bits, or 16 bytes). GCM is the "mode of operation" that tells AES how to handle files of any size, and it adds a critical extra feature: authentication. We will get into what that means shortly.

Symmetric Encryption: One Key, Two Jobs

AES is a symmetric encryption algorithm. This means the same key that locks the data also unlocks it. Think of it like a house key: you use the same key to lock the front door and to open it later.

This is different from asymmetric (or "public-key") encryption, where you have two different keys: one public, one private. Asymmetric encryption is used for things like exchanging keys over the internet, where two strangers need to establish a shared secret without ever meeting. But asymmetric encryption is slow. Hundreds or thousands of times slower than AES.

So in practice, almost every encryption system works like this: use asymmetric encryption to securely agree on a shared key, then use AES (symmetric encryption) to do the actual heavy lifting of encrypting the data. The asymmetric step happens once; the symmetric step handles gigabytes of data at full speed.

QNSQY follows this exact pattern. The post-quantum key exchange (ML-KEM + X25519) is the asymmetric step that produces a shared key. Then AES-256-GCM takes that key and encrypts your actual file. The key exchange is the handshake; AES-256-GCM is the workhorse.

How AES Actually Scrambles Your Data

AES works on blocks of 128 bits (16 bytes) at a time. For each block, it applies a series of mathematical operations called "rounds." AES-256 uses 14 rounds. Each round performs four operations:

SubBytes: Every byte is replaced with a different byte according to a fixed lookup table (called an S-box). This introduces non-linearity, which means even a tiny change in input produces a wildly different output.
ShiftRows: Bytes within each row of the 4x4 block are shifted by different amounts. This spreads the influence of each byte across the entire block.
MixColumns: Each column of the block is mathematically mixed with the others using polynomial multiplication. This further diffuses the data so that every output byte depends on multiple input bytes.
AddRoundKey: The block is combined with a portion of the encryption key using an XOR operation. This is what ties the encryption to your specific key.

After 14 rounds of these operations, the original 16 bytes of your file have been transformed into 16 bytes of ciphertext that look like completely random noise. Without the key, there is no known shortcut to reverse this transformation other than trying every possible key, which, as we covered, is not feasible.

The beauty of this design is its simplicity and its thoroughness. Each round is individually simple, but stacking 14 of them together creates an avalanche effect: changing a single bit of the input changes approximately half the bits of the output. This makes the encryption resistant to every known form of mathematical attack.

Why 256 Bits? The Quantum Computer Question

AES comes in three key sizes: 128, 192, and 256 bits. For decades, AES-128 was considered perfectly secure. And against conventional computers, it still is. No one can brute-force a 128-bit key. But quantum computers change the calculus.

Quantum computers threaten cryptography through two specific algorithms, and understanding the difference between them is essential.

Shor's algorithm is the one that makes headlines. It can break public-key cryptography (RSA, elliptic curves, Diffie-Hellman) by solving certain math problems exponentially faster than any classical computer. If a sufficiently large quantum computer is built, RSA-2048 crumbles. This is why the world is moving to post-quantum algorithms like ML-KEM.

Grover's algorithm is less dramatic but still important. It speeds up brute-force searches. Specifically, it provides a quadratic speedup, which means it effectively cuts the key length in half. Think of it this way: if your lock has a combination with 2^256 possibilities, a quantum computer running Grover's algorithm can find the right one in roughly 2^128 attempts, instead of the full 2^256.

Grover's impact on AES key sizes: AES-128 drops from 128-bit security to 64-bit security under Grover's algorithm. A 64-bit search is within reach of a well-funded attacker even today, using classical hardware. AES-256 drops from 256-bit to 128-bit security, which remains far beyond any foreseeable computing capability. This is why AES-256 is the minimum for quantum safety.

Algorithm	Classical Security	Post-Grover Security	Quantum-Safe?
AES-128	128-bit	64-bit	No
AES-192	192-bit	96-bit	Marginal
AES-256	256-bit	128-bit	Yes

The NSA's CNSA 2.0 suite (Commercial National Security Algorithm Suite) mandates AES-256 for protecting classified information through the quantum era. NIST's post-quantum guidance makes the same recommendation. When the people responsible for protecting state secrets say "use AES-256," it is worth paying attention.

There is also a practical constraint that makes the Grover threat even less concerning. Grover's algorithm requires a quantum computer to maintain "coherence" (a fragile quantum state) for the entire duration of the search. For AES-256, that means sustaining 2^128 quantum operations without a single error. Current quantum computers can maintain coherence for milliseconds. The gap between where quantum hardware is and where it would need to be is enormous.

What GCM Does (And Why It Is Non-Negotiable)

Here is a scenario that illustrates why encryption alone is not enough. Suppose you encrypt a file containing a bank transfer instruction: "Send $1,000 to Alice." An attacker intercepts the encrypted file. They cannot read it. But what if they could modify it? What if, by flipping certain bits in the ciphertext, they could change the amount or the recipient without ever knowing the original message?

This is not hypothetical. With basic encryption modes (like the old CBC mode), bit-flipping attacks are real and have been exploited in practice. The attacker does not need to decrypt anything. They just need to make strategic modifications to the ciphertext, and the recipient decrypts a message that looks legitimate but has been tampered with.

GCM solves this problem by adding authentication. GCM is an AEAD mode, which stands for Authenticated Encryption with Associated Data. Here is what that means in plain terms:

Encryption (Counter Mode): GCM uses AES in counter mode (CTR). It generates a unique number (a counter) for each 128-bit block, encrypts that counter with the AES key to produce a stream of random-looking bytes (called a keystream), and then XORs that keystream with your plaintext. The result is ciphertext. Because each block uses a different counter value, this process is parallelizable, meaning different parts of a large file can be encrypted simultaneously across multiple CPU cores.
Authentication (GHASH): Simultaneously, GCM runs a mathematical function called GHASH over the ciphertext. GHASH is a polynomial hash that uses multiplication in a Galois field (a branch of abstract algebra, hence the "G" in GCM). The result is a 128-bit authentication tag. This tag is like a mathematical fingerprint of the entire ciphertext plus any additional metadata you want to protect.

When you decrypt, GCM recomputes the authentication tag and compares it to the one stored with the file. If even a single bit of the ciphertext was changed, the tags will not match, and decryption is rejected entirely. There is no partial decryption. There is no "best effort" recovery. Either the data is exactly what was encrypted, or you get an error. Period.

The "Associated Data" part: AEAD lets you authenticate data that you do not want to encrypt. For example, QNSQY uses this to authenticate the file header (which contains the algorithm version, salt, and other metadata). This header needs to be readable before decryption starts, but it also needs to be tamper-proof. GCM authenticates it alongside the ciphertext, so any modification to the header is also detected.

This is why modern cryptographic standards insist on authenticated encryption. Using AES without authentication (in modes like ECB or even plain CTR) is considered a security flaw. GCM provides both confidentiality and integrity in a single, efficient operation.

The Nonce: GCM's One Critical Rule

GCM has one strict requirement: every encryption operation must use a unique nonce (number used once). The nonce is 96 bits (12 bytes) in standard GCM. It does not need to be secret, but it absolutely must never be reused with the same key.

If you encrypt two different messages with the same key and the same nonce, an attacker can XOR the two ciphertexts together and recover both plaintexts. Worse, they can forge authentication tags, completely breaking the integrity guarantee. This is not a theoretical weakness; it has been exploited in real attacks against systems that mismanaged nonces.

QNSQY generates a fresh 96-bit random nonce for every single encryption operation using a cryptographically secure random number generator. Since each file gets its own nonce, and keys are derived fresh for each operation via the hybrid KEM process, nonce reuse is not a practical concern. The probability of a random 96-bit collision is astronomically small.

For systems that encrypt billions of messages with the same key (like TLS sessions), the 96-bit nonce becomes a limiting factor. That is one reason why XChaCha20-Poly1305 exists as an alternative: its 192-bit nonce makes random collisions even less likely. QNSQY offers XChaCha20-Poly1305 as an option on every tier for users who want this extra margin.

Performance: Why AES-256-GCM Is Practically Free

Encryption has a reputation for being slow. In the 1990s, that was true. Running DES or Triple-DES in software was computationally expensive. But in 2008, Intel introduced AES-NI (AES New Instructions), a set of hardware instructions built directly into the CPU that perform AES rounds in a single clock cycle. AMD followed with their own implementation shortly after. Today, every x86-64 processor sold since roughly 2010, and most ARM processors used in modern phones and tablets, have hardware AES acceleration.

With AES-NI, AES-256-GCM encryption and decryption routinely exceeds 25 GB/s per CPU core. That means a 1 GB file encrypts in under 100 milliseconds. A 100 MB document encrypts in under 10 milliseconds. For most real-world file sizes, the encryption step is literally faster than the time it takes to read the file from your hard drive. The disk is the bottleneck, not the encryption.

Property	AES-256-GCM	XChaCha20-Poly1305
Default in QNSQY	Yes (all tiers)	Optional (all tiers)
Hardware acceleration	AES-NI (x86-64, ARM)	Software only
Throughput (AES-NI)	>25 GB/s	~1-2 GB/s
Nonce size	96-bit	192-bit
Nonce reuse tolerance	Catastrophic	More forgiving
Best for	Most platforms	No AES-NI, high nonce safety

Where You Already Use AES-256-GCM (Without Knowing It)

AES-256-GCM is not some niche algorithm used only by security specialists. It is the default cipher suite in most of the technology you already use:

Web browsing (TLS 1.3): When you visit any HTTPS website, your browser negotiates a cipher suite with the server. In TLS 1.3, AES-256-GCM is one of the two mandatory cipher suites. Every online banking session, every email login, every search query is protected by it.
Disk encryption: BitLocker (Windows), FileVault (macOS), and LUKS (Linux) all use AES-256 for full-disk encryption. If your laptop is stolen, the thief sees nothing but random noise on the drive.
VPNs: IPsec and WireGuard VPN tunnels use AES-256-GCM (or its close cousin ChaCha20-Poly1305) to encrypt traffic between your device and the VPN server.
SSH: When you connect to a remote server via SSH, AES-256-GCM is typically the negotiated encryption algorithm.
Cloud storage: AWS, Google Cloud, and Azure all use AES-256 for encrypting data at rest in their storage services.
Messaging: Signal, WhatsApp, and other encrypted messengers use AES-256-GCM as the symmetric cipher inside their encryption protocols.

The reason AES is everywhere is that it has survived 25 years of relentless attack by the global cryptographic research community. Thousands of papers have been published analyzing AES. The best known attack against full AES-256 (a "biclique" attack published in 2011) reduces the search space from 2^256 to 2^254.4. That is a theoretical improvement of roughly four times faster, which is completely irrelevant in practice when the original number is already incomprehensibly large.

AES-256-GCM in QNSQY

In QNSQY, AES-256-GCM is the default AEAD cipher in every tier (Free, Pro, and Business). Here is how it fits into the overall encryption process:

Key derivation: If you are encrypting with a password, QNSQY runs your password through Argon2id (a memory-hard key derivation function) to produce a 256-bit AES key. If you are encrypting with a recipient's public key, the hybrid key exchange (ML-KEM + X25519) produces the key.
Nonce generation: A fresh 96-bit random nonce is generated from the operating system's cryptographic random number generator.
Encryption: The file contents are encrypted with AES-256-GCM using the derived key and nonce. The file header (containing metadata like the algorithm version, salt, and KEM ciphertext) is included as associated data, meaning it is authenticated but not encrypted.
Output: The resulting .qs file contains the header, the nonce, the encrypted data, and the 128-bit authentication tag. Everything needed to decrypt (except the key) is in the file.

QNSQY also offers XChaCha20-Poly1305 as an alternative on every tier. Both algorithms provide equivalent security (256-bit keys, 128-bit authentication tags). The practical difference is that AES-256-GCM is faster on hardware with AES-NI (which is almost everything), while XChaCha20-Poly1305 has a larger nonce and performs well in software on platforms without hardware AES acceleration.

A 25-Year Track Record

AES was published in 2001. In the quarter century since, it has been studied more intensively than perhaps any other cryptographic algorithm in history. It has been formally verified. It has been subjected to side-channel analysis, differential cryptanalysis, linear cryptanalysis, algebraic attacks, related-key attacks, and every other technique cryptographers have invented. No practical attack has ever been found against full AES-256.

The GCM mode was standardized by NIST in 2007 as SP 800-38D. It has similarly been analyzed extensively. The known weaknesses of GCM (nonce reuse vulnerability, short tag lengths if misconfigured) are well-understood and easily avoided with proper implementation. QNSQY uses the full 128-bit tag and fresh random nonces, avoiding both pitfalls.

When you encrypt a file with QNSQY, you are using an algorithm that has been vetted by the NSA for classified information, mandated by NIST for government systems, deployed by every major technology company, and scrutinized by the world's best cryptographers for over two decades. Combined with post-quantum key exchange, it provides security against both today's threats and tomorrow's quantum computers.

Sources

NIST FIPS 197: Advanced Encryption Standard (AES), November 2001. csrc.nist.gov/publications/detail/fips/197/final
NIST SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007. csrc.nist.gov/publications/detail/sp/800-38d/final
Grover, L. K. "A Fast Quantum Mechanical Algorithm for Database Search," Proceedings of the 28th Annual ACM Symposium on Theory of Computing, 1996.
NSA CNSA 2.0: Commercial National Security Algorithm Suite 2.0. media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
Bogdanov, A. et al. "Biclique Cryptanalysis of the Full AES," ASIACRYPT 2011.

Quantum-Safe Symmetric Encryption

Every QNSQY encrypted file uses AES-256-GCM by default. 256-bit keys. Authenticated. Hardware-accelerated.

Originally published at quantumsequrity.com.

Protect Data from Quantum Computers

Quantum Sequrity — Sun, 10 May 2026 13:00:13 +0000

Protect Data from Quantum Computers

Guide

How to Protect Your Data from Quantum Computers

14 min read

The Quantum Threat Is Not Hypothetical

Quantum computers will break most of today's encryption. This is not speculation or fear-mongering. It is a mathematical certainty based on Shor's algorithm, published in 1994 and verified by every cryptographer who has examined it since. The only question is when quantum hardware becomes powerful enough to run the algorithm at scale.

The timeline matters because of a strategy called "harvest now, decrypt later." Intelligence agencies and sophisticated attackers are already recording encrypted internet traffic and storing it in massive data centers. They cannot read it today. But when quantum computers mature, they will decrypt everything they have collected. Your medical records from 2024, your financial transactions, your private messages, and your legal documents could all become readable.

If your data needs to stay secret for more than 10 years, you should already be concerned. If it needs to stay secret for 20 years or more (medical records, legal documents, government secrets), the situation is urgent.

Time-Sensitive: Data you encrypt today with RSA-based tools can be stored by adversaries now and decrypted when quantum computers mature. The NSA's CNSA 2.0 guidance mandates that all National Security Systems transition to post-quantum cryptography by 2035, with software implementations starting immediately.

What Data Is Actually at Risk?

Not all encryption is equally vulnerable. Understanding what breaks and what survives helps you prioritize.

Vulnerable to Quantum Attack

Any system that uses public-key cryptography for key exchange is at risk. This includes:

RSA (used in email encryption like PGP/GPG, many VPNs, older TLS connections): Shor's algorithm factors the large numbers RSA relies on. RSA-2048, which would take a classical computer 300 trillion years to break, could fall in hours on a sufficiently large quantum computer.
ECDH/ECDSA (used in modern TLS, SSH, Signal, WhatsApp, cryptocurrency wallets): Shor's algorithm solves the elliptic curve discrete logarithm problem. All key sizes are vulnerable.
Diffie-Hellman (used in some VPNs and older protocols): Same vulnerability as RSA. The discrete logarithm problem is efficiently solvable by quantum computers.

Safe from Quantum Attack

Symmetric encryption like AES is not broken by quantum computers. Grover's algorithm provides a quadratic speedup, which means it effectively halves the key length. AES-256 becomes roughly equivalent to AES-128, which is still considered secure. AES-128 becomes equivalent to AES-64, which would be too weak. The solution is simple: use AES-256, and you are fine.

The problem is that AES alone cannot protect data in transit. Two computers that have never communicated before need a way to establish a shared AES key. That key exchange step currently relies on RSA or ECDH, both of which are quantum-vulnerable. If an attacker records the key exchange, they can later use a quantum computer to extract the AES key from it, and then decrypt everything. The encryption itself is strong. The key agreement mechanism is the weak link.

Which Files Need Protection?

Not all data requires the same level of concern. Think about how long the data needs to remain confidential.

Medical records: HIPAA requires protection for the patient's lifetime plus years after death. A 30-year-old's medical records from today need to remain confidential for 50+ years. They will absolutely still be sensitive when quantum computers arrive.
Financial records: Tax returns, bank statements, investment records. Sensitivity varies but can extend 10-20 years for estate planning and legal compliance. Corporate financial data may be relevant for decades.
Legal documents: Wills, trust documents, contracts, attorney-client communications. Many of these are sensitive indefinitely. A will encrypted today with RSA could be decrypted by an adversary in 15 years, potentially before the grantor has even passed away.
Business intellectual property: Trade secrets, proprietary algorithms, product roadmaps, merger/acquisition documents. The competitive value of this data often lasts decades.
Personal archives: Private photos, journals, messages. Would you want these publicly readable in 15 years? People's private correspondence has been used for blackmail, identity theft, and reputational damage.
Cryptocurrency wallets and private keys: Bitcoin and Ethereum use ECDSA for transaction signing. A quantum computer that can solve the elliptic curve discrete logarithm problem could forge transactions and drain wallets. Unlike other data, cryptocurrency keys have direct monetary value.
Government and military communications: Classified information can remain sensitive for 25-75 years depending on classification level. The NSA has already mandated the transition to post-quantum algorithms for all National Security Systems.

Why AES-256 Survives but RSA Does Not

This point deserves a clear explanation because it confuses many people.

RSA is based on the mathematical difficulty of factoring large numbers. A 2048-bit RSA key is the product of two roughly 300-digit prime numbers. Finding those primes from the product is extraordinarily hard for classical computers. Shor's algorithm, running on a quantum computer, can find those primes efficiently. It does not matter how large you make the RSA key. Shor's algorithm scales polynomially, meaning it can always keep up. Making the key bigger only slows the attack slightly.

AES-256 is a symmetric cipher. There is no mathematical structure for a quantum computer to exploit. The best quantum attack is Grover's algorithm, which is essentially a "smart search" that checks possible keys faster, but only by a square root factor. For AES-256, this means checking 2^128 possibilities instead of 2^256. That still requires an astronomical number of operations. 2^128 is roughly 340,000,000,000,000,000,000,000,000,000,000,000,000 operations. Even a quantum computer running for the lifetime of the universe could not complete this search.

This is why quantum-safe encryption combines post-quantum key agreement (ML-KEM, which replaces RSA/ECDH) with classical symmetric encryption (AES-256-GCM, which does not need replacing). The key agreement step is the part that needs to be quantum-resistant. The actual data encryption using AES-256 is already safe.

Practical Steps: What You Can Do Right Now

For Individuals

Identify your most sensitive files. Medical records, financial documents, legal papers, cryptocurrency wallets, private archives. Make a list.
Re-encrypt with quantum-safe tools. Files currently encrypted with GPG (which uses RSA or ECDH) or VeraCrypt (which uses RSA for key exchange) should be re-encrypted using post-quantum algorithms. QNSQY's free tier uses ML-KEM-512 + X25519 hybrid encryption, which protects against both classical and quantum attacks.
Use strong passwords. Post-quantum encryption protects the key exchange, but your password is still the first line of defense. Use a passphrase of 4 or more random words, or 16+ characters of mixed types. QNSQY processes passwords through Argon2id, which requires 128 MB of memory per attempt, making brute-force attacks extremely expensive. But Argon2id cannot compensate for a password like "password123."
Store encrypted backups in multiple locations. Files encrypted with quantum-safe algorithms are safe to store on cloud services (Google Drive, Dropbox, iCloud). Even if the cloud provider is compromised, the encryption protects the contents. Keep copies in at least two separate locations.

For Organizations

Conduct a cryptographic inventory. Identify every system that uses RSA, ECDH, or other quantum-vulnerable algorithms. This includes TLS certificates, VPN configurations, database encryption, backup encryption, code signing, and email encryption.
Prioritize by data sensitivity and lifetime. Data that must remain confidential for 10+ years should be migrated first. Patient records, financial data, trade secrets, and government-classified information are top priorities.
Adopt hybrid cryptography. During the transition period, use hybrid systems that combine post-quantum and classical algorithms. This protects against quantum attacks while maintaining backward compatibility and insurance against unforeseen weaknesses in new algorithms.
Plan for algorithm agility. Build systems that can swap cryptographic algorithms without rewriting entire applications. NIST may update or replace algorithms as the field evolves. Hardcoding a single algorithm into your architecture creates long-term risk.
Re-encrypt archived data. Old backups and archives encrypted with RSA or ECDH are a ticking time bomb. Schedule re-encryption using post-quantum algorithms.

Understanding the Protection Layers

When you encrypt a file with QNSQY, multiple independent algorithms protect your data at different layers:

Layer	Algorithm	What It Does
Password Processing	Argon2id (128 MB memory, multiple iterations)	Turns your password into a cryptographic key. Memory-hard design makes GPU/ASIC brute-force attacks economically infeasible.
Key Agreement	ML-KEM-512 + X25519 (hybrid)	Two independent key encapsulation operations. ML-KEM resists quantum attacks. X25519 is proven against classical attacks. Both must be broken to compromise the key.
Data Encryption	AES-256-GCM	Encrypts the actual file contents. Authenticated encryption detects any tampering. AES-256 is quantum-safe (Grover's algorithm only reduces it to 128-bit equivalent security).
Integrity Verification	BLAKE3	Cryptographic hash of the entire encrypted file. Detects any modification, corruption, or truncation.

Each layer addresses a different threat. Argon2id handles password guessing. Hybrid ML-KEM + X25519 handles key compromise (both classical and quantum). AES-256-GCM handles data confidentiality and authentication. BLAKE3 handles file integrity. An attacker would need to defeat all four layers simultaneously to access your data.

The Harvest Now, Decrypt Later Problem

The most dangerous aspect of the quantum threat is that it operates retroactively. An attacker does not need a quantum computer today to threaten your data. They only need to record your encrypted data today and wait.

This strategy, called "harvest now, decrypt later" (HNDL), is well-documented and acknowledged by intelligence agencies on all sides. The NSA's CNSA 2.0 guidance implicitly acknowledges HNDL by mandating immediate action on post-quantum migration, years before quantum computers are expected to arrive. The reasoning is straightforward: if you wait until quantum computers exist to switch to quantum-safe encryption, all the data you transmitted before the switch can be retroactively decrypted.

Consider a concrete example. A hospital sends a patient's MRI results to a specialist via encrypted email using standard TLS with ECDH key exchange. An adversary with access to the network path (which could be an intelligence agency tapping an undersea cable, a compromised router at an ISP, or a state-sponsored attacker) records the encrypted session. Today, they cannot read it. In 15 years, they use a quantum computer to extract the ECDH session key and decrypt the email. The MRI results, along with the patient's name, diagnosis, and treatment plan, are now exposed.

The patient is still alive. The information is still sensitive. And there is nothing anyone can do to un-expose it.

This is why the time to switch to quantum-safe encryption is now, not when quantum computers arrive. Encryption protects data in the future, but the encrypted form of that data exists in the present. If the present-day encryption is quantum-vulnerable, the future protection is illusory.

The Real Quantum Threat Timeline

Understanding the timeline helps you calibrate urgency. Nobody knows exactly when quantum computers will be able to break current encryption, but several credible organizations have published estimates.

NIST began the post-quantum standardization process in 2016, stating that cryptographically relevant quantum computers were likely 15 to 20 years away. That puts the window at 2031 to 2036. The Global Risk Institute's 2023 survey of 37 quantum computing experts found a 50% probability of a cryptographically relevant quantum computer by 2033. The NSA's CNSA 2.0 guidance, published in 2022, mandates that all National Security Systems begin transitioning to post-quantum cryptography immediately, with full migration required by 2035.

Google's Quantum AI team achieved a significant milestone in 2024 with the Willow chip, demonstrating 105 qubits with error correction rates below the threshold needed for fault-tolerant computation. While still far from the millions of physical qubits needed to break RSA-2048, this demonstrates that quantum error correction, long considered the primary engineering bottleneck, is making real progress.

The honest assessment: cryptographically relevant quantum computers are probably 10 to 20 years away. But "probably" is not a guarantee. Breakthroughs in quantum error correction or novel qubit architectures could accelerate the timeline. And more importantly, the "harvest now, decrypt later" threat means that data encrypted today is already at risk if it needs to remain secret longer than the time until quantum computers arrive.

What the Transition Looks Like for Different Users

Individual Users

If you are an individual with sensitive files (medical records, financial documents, personal archives), the transition is straightforward. Install a quantum-safe encryption tool, re-encrypt your most sensitive files, and use quantum-safe encryption for all new sensitive data going forward. The entire process can be completed in an afternoon for personal use.

Small and Medium Businesses

For organizations, the transition involves more planning. Start by inventorying all systems that use encryption: VPN configurations, TLS certificates, database encryption, backup systems, email encryption. Prioritize systems that handle data with long sensitivity lifetimes (customer records, financial data, intellectual property). Adopt quantum-safe tools for data encryption first, as this is the easiest change. Then work with your IT team or managed service provider to plan the transition for network protocols.

Large Enterprises and Government

Large organizations typically need 3 to 7 years for a full cryptographic transition. This includes discovery (finding all cryptographic dependencies), testing (ensuring new algorithms work with existing systems), deployment (rolling out changes across the organization), and verification (confirming that all systems have been migrated). NIST recommends starting with "crypto-agile" architectures that can swap algorithms without rewriting applications, then migrating to post-quantum algorithms as part of normal upgrade cycles.

Common Questions

Is AES-256 enough on its own?

AES-256 is quantum-safe for encrypting data, but it cannot help two parties agree on a shared key over an insecure channel. You need a key agreement mechanism (like ML-KEM) to establish the AES key in the first place. If the key agreement is quantum-vulnerable (RSA or ECDH), the AES encryption provides no protection because the attacker can simply extract the key.

Is the free version of QNSQY actually secure?

Yes. The free version uses ML-KEM-512 + X25519 for key encapsulation and AES-256-GCM for data encryption. These are the same NIST-standardized algorithms used in paid tiers. The free tier has a 100 MB file size limit and uses the Level 1 security parameter (ML-KEM-512), which provides 128-bit post-quantum security. Paid tiers add access to higher security levels (ML-KEM-768 at Level 3, ML-KEM-1024 at Level 5) and features like batch encryption, vault storage, and threshold encryption.

Can I decrypt files on another computer?

Yes. The .qs file contains everything needed for decryption except your password. Install QNSQY on any supported platform (Windows, macOS, Linux), provide the same password, and the file decrypts. The file format is platform-independent.

What happens if I forget my password?

QNSQY has no backdoor, no recovery mechanism, and no master key. If you forget your password, your data is permanently unrecoverable. This is a deliberate security design: any recovery mechanism would be a potential attack vector. Use a password manager, or write down your passphrase and store it in a physically secure location (a safe, a safety deposit box).

Why Act Now Rather Than Later

Every month you delay is another month of data that could be harvested and stored by adversaries waiting for quantum computers. But the urgency goes beyond the harvest-now-decrypt-later threat.

Cryptographic transitions are historically slow. The migration from DES to AES took over a decade. Some systems were still using DES 15 years after AES was standardized. The migration from SHA-1 to SHA-2 took even longer, with major web browsers not dropping SHA-1 support until 2017, over six years after SHA-1 was officially deprecated.

Organizations with large deployed systems need years to plan, test, and roll out cryptographic changes. If the quantum computer timeline is 10 to 15 years, and the migration timeline is 3 to 7 years, the window for action is already closing. Starting now provides the time needed for a careful, thorough transition rather than a panicked, error-prone one.

For individuals, the situation is simpler but no less important. You can start protecting your files today with freely available quantum-safe encryption tools. There is no cost, no performance penalty, and no technical barrier. The only risk is in not acting.

Sources

Learn About Quantum Encryption

Originally published at quantumsequrity.com.

Why Hybrid Encryption Matters Blog

Quantum Sequrity — Sat, 09 May 2026 13:01:04 +0000

Security

Why Hybrid Encryption Matters

13 min read

Why Use Two Locks When One Should Be Enough?

The front door of your house probably has one lock. That works fine for everyday life. But the vault at a bank has a time-lock mechanism, a combination dial, and a physical key requirement. Nuclear missile silos require two officers to turn their keys simultaneously. Airplane cockpit doors have multiple independent locking mechanisms.

The more important something is, the more layers of protection it gets. Cryptographers apply the same principle through something called hybrid encryption: using two completely independent encryption algorithms at the same time, so that an attacker must break both to access the data.

QNSQY combines two key encapsulation algorithms in every encryption operation:

ML-KEM: A post-quantum algorithm standardized by NIST as FIPS 203 in August 2024. Based on lattice mathematics that quantum computers cannot efficiently solve.
X25519: A classical elliptic curve algorithm designed by Daniel Bernstein in 2006. Used by billions of devices every day for TLS, SSH, Signal, and WhatsApp. Extensively studied for nearly two decades.

The encryption key that protects your file depends on both algorithms. An attacker who breaks ML-KEM but not X25519 still cannot read your data. An attacker who breaks X25519 but not ML-KEM still cannot read your data. Both must fall simultaneously.

The Honest Reason We Need Both

ML-KEM passed one of the most rigorous evaluation processes in cryptographic history: eight years of public scrutiny by the global cryptography community, coordinated by NIST. Hundreds of published papers analyzed its security. Multiple research teams attempted to break it. It survived everything.

X25519 has been deployed in production systems since approximately 2014. It protects a significant fraction of all HTTPS traffic on the internet. Every major browser, operating system, and messaging application uses it. Twelve years of real-world deployment across billions of devices is an extraordinary track record.

So why not just use one of them?

The answer is that cryptography has a history of surprises. Algorithms that appeared secure for years have occasionally fallen to unexpected mathematical breakthroughs. MD5 was considered secure for over a decade before collision attacks were discovered. SHA-1 was used for 15 years before practical collision attacks rendered it obsolete. The NIST Dual_EC_DRBG random number generator was a published standard that turned out to contain a deliberate backdoor.

Nobody expects ML-KEM to have such a flaw. But nobody expected those earlier problems either. And ML-KEM is built on lattice mathematics that, while extensively studied, has been in widespread cryptographic use for a much shorter time than the mathematical foundations of RSA or elliptic curves. There is a nonzero chance, however small, that a breakthrough in lattice cryptanalysis could weaken ML-KEM.

Conversely, X25519 is known to be vulnerable to quantum computers. Shor's algorithm can solve the elliptic curve discrete logarithm problem efficiently. When a sufficiently powerful quantum computer exists, X25519 will be broken. This is not speculation; it is mathematical certainty.

The hybrid approach eliminates both risks:

If ML-KEM Has an Unforeseen Classical Weakness

X25519 still protects your data against classical attackers. This is the scenario where a cryptographer discovers a mathematical shortcut that makes lattice problems easier to solve than expected. Even in this worst case, your data remains protected by a proven algorithm with two decades of analysis behind it.

If a Quantum Computer Breaks X25519

ML-KEM still protects your data. This is the expected scenario: quantum computers will break elliptic curve cryptography. But ML-KEM was specifically designed and evaluated for quantum resistance. Your data remains safe.

How Hybrid Key Combination Actually Works

The technical details of how two key encapsulation results are combined matter, because doing it wrong could undermine the security of the whole construction. QNSQY uses a carefully designed process:

ML-KEM encapsulation runs. This produces a shared secret (let us call it SS1, a 32-byte random value) and a ciphertext that gets stored in the encrypted file.
X25519 key exchange runs independently. This produces a second shared secret (SS2, another 32-byte value) and an ephemeral public key that gets stored in the file.
Your password is processed through Argon2id. This produces a third key component (SS3) derived from your password and a random salt. Argon2id uses 128 MB of memory per iteration, making brute-force attacks against your password economically infeasible.
All three secrets are fed into HKDF-SHA3-256. HKDF (HMAC-based Key Derivation Function) is a standard construction defined in RFC 5869. It takes multiple input key materials and produces a single output key. The critical property: the output is at least as strong as the strongest input. If any one of the three inputs is secure, the output key is secure.
The HKDF output becomes the AES-256-GCM key. This key encrypts the actual file contents. AES-256-GCM provides both confidentiality (nobody can read the data) and authenticity (any modification to the encrypted file is detected).

The mathematical guarantee of this construction is important. Because the final key is derived through HKDF from all three components, an attacker cannot compute the key without knowing all three inputs. Breaking ML-KEM gives them SS1 but not SS2 or SS3. Breaking X25519 gives them SS2 but not SS1 or SS3. Guessing your password gives them SS3 but not SS1 or SS2. They need all three.

The AND Construction vs. the OR Construction

Security engineers distinguish between two types of multi-algorithm constructions, and the difference is critical:

AND construction: The attacker must break Algorithm A AND Algorithm B to succeed. Security is at least as strong as the stronger of the two.

OR construction: The attacker can break Algorithm A OR Algorithm B to succeed. Security is only as strong as the weaker of the two.

QNSQY always uses the AND construction. Both ML-KEM and X25519 must be broken for the key to be compromised. This is the maximum security approach.

An example of the wrong way to do hybrid encryption would be to encrypt the data once with ML-KEM's key and then separately encrypt it again with X25519's key, where either key alone could decrypt the data. That would be an OR construction, and it would actually be less secure than using the stronger algorithm alone, because an attacker only needs to break the weaker one.

The HKDF key combination method used by QNSQY ensures AND semantics. The final AES key depends on all input components. There is no way to "short circuit" the derivation by knowing only one input.

What the Major Security Organizations Say

Hybrid encryption is not a novel idea from any single company. It is the recommended approach from every major security standards body and intelligence agency that has published guidance on the post-quantum transition:

NIST (United States): Published SP 800-227 "Recommendations for Key-Encapsulation Mechanisms," which specifically addresses hybrid key establishment combining post-quantum and classical algorithms. NIST acknowledges that hybrid approaches provide "defense in depth during the transition to post-quantum cryptography."
NSA (United States): The CNSA 2.0 guidance for National Security Systems recommends a phased transition that begins with hybrid configurations. The NSA recognizes that organizations need the insurance of classical algorithms while post-quantum algorithms accumulate real-world deployment experience.
ENISA (European Union): The European Union Agency for Cybersecurity recommends hybrid modes for the transition period, specifically combining NIST-standardized post-quantum algorithms with established classical algorithms.
BSI (Germany): Germany's Federal Office for Information Security published Technical Guideline TR-02102, which recommends hybrid key exchange using post-quantum and classical algorithms during the transition period. The BSI is notably conservative; their recommendation of the hybrid approach carries significant weight.
ANSSI (France): France's national cybersecurity agency also endorses hybrid approaches, emphasizing that post-quantum algorithms should supplement, not replace, classical algorithms during the transition.

The consensus is unanimous. Every major security authority in the Western world recommends the hybrid approach. The reasoning is always the same: post-quantum algorithms provide quantum resistance, classical algorithms provide decades of proven security, and combining both ensures that a failure in one does not compromise the entire system.

Real-World Hybrid Deployments

Hybrid post-quantum cryptography is not just a theoretical recommendation. It is already deployed in production systems used by billions of people:

Google Chrome and ML-KEM in TLS

In 2024, Google enabled hybrid ML-KEM + X25519 key exchange in Chrome for TLS 1.3 connections. When you visit a website that supports this configuration, your browser performs both a classical X25519 key exchange and a post-quantum ML-KEM key encapsulation. The two shared secrets are combined to produce the TLS session key. Google reported that the ML-KEM operation adds roughly 0.4 milliseconds to the TLS handshake, an amount invisible to users. The larger public key (1,184 bytes for ML-KEM-768 compared to 32 bytes for X25519) adds a small amount to the data transmitted during the handshake but does not measurably affect page load times.

Cloudflare's Post-Quantum Deployment

Cloudflare, which handles a significant percentage of global web traffic, began supporting post-quantum key exchange in its edge network. Their engineering blog documented the deployment of hybrid ML-KEM + X25519 across their infrastructure. Their measurements confirmed that the performance impact is negligible for real-world web browsing, with the slight increase in handshake size offset by the complete absence of additional round-trips.

Signal Messenger

Signal updated its protocol (PQXDH) to include a post-quantum key exchange layer alongside its existing X25519-based protocol. Every new Signal session now uses post-quantum protection, with X25519 providing the classical fallback.

These deployments demonstrate that hybrid encryption is not a theoretical concept or a performance burden. It works at massive scale with no user-visible impact.

Performance: Does Running Two Algorithms Slow Things Down?

This is a reasonable concern, and the answer is: no, not in any way you would notice.

The key encapsulation operations (ML-KEM + X25519) happen once per file, at the very beginning of the encryption process. On a modern computer:

ML-KEM-768 key generation + encapsulation takes approximately 70 microseconds total
X25519 key exchange takes approximately 120 microseconds
HKDF key combination takes approximately 1 microsecond
Total hybrid key establishment: under 200 microseconds (0.2 milliseconds)

For context, 200 microseconds is about one five-thousandth of a second. A human blink takes roughly 300,000 microseconds (300 milliseconds). The hybrid key exchange is 1,500 times faster than a blink.

The actual data encryption using AES-256-GCM is where time is spent. AES-256-GCM on modern hardware (with AES-NI instruction set support) processes data at several gigabytes per second. A 100 MB file takes about 30 milliseconds to encrypt. A 1 GB file takes about 300 milliseconds. In both cases, the 0.2 millisecond hybrid key exchange is a negligible fraction of the total time.

The only measurable cost of hybrid encryption is the additional storage space for the ML-KEM ciphertext in the encrypted file header. An ML-KEM-768 ciphertext is 1,088 bytes. An X25519 public key is 32 bytes. The total overhead is roughly 1,120 bytes added to the file. For a 1 MB file, that is 0.1% overhead. For a 100 MB file, it rounds to zero.

What Happens If One Algorithm Is Eventually Broken?

This is the entire point of the hybrid approach, and it is worth spelling out the scenarios explicitly.

Scenario 1: ML-KEM is broken by a classical attack in 2032. A mathematician discovers a shortcut for solving lattice problems. ML-KEM keys can now be recovered in minutes. However, your file is still protected because the AES-256-GCM key was derived from both ML-KEM and X25519. The attacker knows the ML-KEM shared secret but not the X25519 shared secret. Without both, they cannot compute the AES key. Your data remains safe against all classical computers.

Scenario 2: A quantum computer breaks X25519 in 2035. This is the expected outcome. A quantum computer running Shor's algorithm recovers the X25519 shared secret. However, the AES key also depends on the ML-KEM shared secret, which quantum computers cannot recover (that is the entire purpose of ML-KEM). Your data remains safe against quantum computers.

Scenario 3: Both are broken simultaneously. This would require a quantum computer that breaks X25519 AND a classical mathematical breakthrough that breaks ML-KEM, happening at the same time. This is an extraordinarily unlikely combination. But even in this worst case, your password (processed through Argon2id) provides a third independent key component. An attacker would need all three.

Hybrid for Signatures Too: ML-DSA + Ed25519

Hybrid encryption is not only about key encapsulation. Digital signatures face the same quantum threat, and the same hybrid principle applies.

QNSQY uses hybrid signatures for file signing and integrity verification. Every signed file gets two independent signatures:

ML-DSA (FIPS 204): A post-quantum lattice-based signature. Resistant to Shor's algorithm.
Ed25519: A classical elliptic curve signature. Used by SSH, TLS, and major software distribution systems for over a decade.

A forger must produce valid signatures for both algorithms to fool the verification. If ML-DSA were broken, the Ed25519 signature would still catch the forgery. If a quantum computer breaks Ed25519, the ML-DSA signature would still catch the forgery. The verification only passes when both signatures are valid.

This mirrors the AND construction used for key encapsulation. Just as the encryption key depends on both ML-KEM and X25519, the signature verification depends on both ML-DSA and Ed25519. The security philosophy is consistent across all operations.

When Will We Stop Needing Hybrid?

Hybrid encryption is a transitional strategy. At some point, the cryptographic community will have enough confidence in post-quantum algorithms that the classical component becomes unnecessary overhead. When will that be?

The honest answer is: probably 10 to 20 years from now. Consider the precedent. AES was standardized in 2001. By 2010, it was used everywhere, but many systems still supported older algorithms like 3DES as a fallback. By 2020, most systems had fully transitioned to AES-only. The complete lifecycle from standardization to universal confidence took roughly 20 years.

ML-KEM was standardized in 2024. Following the AES precedent, universal confidence might arrive around 2040 to 2045. Until then, the hybrid approach provides insurance that costs nothing in terms of security and very little in terms of performance.

NIST's guidance explicitly frames hybrid as a transition mechanism. Once post-quantum algorithms have accumulated sufficient deployment experience (measured in years of real-world use at scale), organizations may choose to use post-quantum algorithms alone. But during the transition period, there is no downside to hybrid, and significant upside.

NIST SP 800-227: The Official Hybrid Guidance

NIST addressed hybrid key establishment directly in Special Publication 800-227, "Recommendations for Key-Encapsulation Mechanisms." This document provides specific guidance on how to combine post-quantum and classical algorithms safely.

Key points from the guidance:

Hybrid key establishment should combine the shared secrets from both algorithms using a secure key derivation function (like HKDF).
The combined key should depend on both components so that compromise of one does not compromise the final key (the AND property).
Organizations should maintain hybrid configurations during the transition period until sufficient confidence in post-quantum algorithms has accumulated from real-world deployment.
The hybrid approach does not introduce new security weaknesses. The combined system is at least as strong as the stronger individual component.

QNSQY's implementation follows these recommendations exactly: two independent key encapsulations, HKDF combination, AND construction security.

Sources

Double Protection, Zero Hassle

QNSQY automatically uses hybrid ML-KEM + X25519 encryption. You don't need to configure anything.

Originally published at quantumsequrity.com.

ML-DSA vs SLH-DSA: Which to Choose

Quantum Sequrity — Fri, 08 May 2026 13:00:11 +0000

ML-DSA vs SLH-DSA: Which to Choose

Cryptography

ML-DSA vs SLH-DSA: Choosing Your Signature Algorithm

14 min read

What Are Digital Signatures, and Why Should You Care?

Imagine you receive a letter in the mail. How do you know who actually sent it? Someone could have forged the return address. How do you know nobody opened the envelope, changed a few words, and resealed it? In the physical world, we have notaries, wax seals, and registered mail. In the digital world, we have digital signatures.

A digital signature is a piece of math attached to a file or message that proves two things. First, authenticity: the file genuinely came from the person or organization claiming to have sent it. Second, integrity: the file has not been changed, even by a single bit, since it was signed. If someone modifies the file after signing, the signature check fails.

You rely on digital signatures constantly, even if you never think about them. Every time your phone installs a software update, it checks a digital signature to confirm the update came from Apple or Google, not a hacker. Every time your browser connects to your bank, it verifies a chain of digital signatures on the bank's security certificate. Every time a hospital transfers a medical record, signatures confirm the data has not been tampered with.

The problem is that the digital signature algorithms we have used for decades (RSA, ECDSA, EdDSA) will all be broken by a sufficiently powerful quantum computer. A quantum algorithm called Shor's algorithm can solve the underlying math problems in hours instead of billions of years. The signatures that protect software updates, financial transactions, and medical records will become forgeable.

NIST (the U.S. National Institute of Standards and Technology) spent eight years evaluating replacement algorithms that quantum computers cannot break. In August 2024, they published two post-quantum signature standards: ML-DSA (FIPS 204) and SLH-DSA (FIPS 205). Both are quantum-safe. Both are NIST-approved. But they work in fundamentally different ways, with different tradeoffs. Choosing between them matters.

ML-DSA: The Fast, General-Purpose Option

ML-DSA stands for Module-Lattice Digital Signature Algorithm. It was standardized as NIST FIPS 204 in August 2024. During NIST's evaluation process, it was known by its competition name, CRYSTALS-Dilithium.

The word "lattice" refers to the mathematical structure that makes ML-DSA secure. Think of a lattice as a grid of points in space. In two dimensions, a lattice is like graph paper: an orderly grid of dots. Now imagine that grid extended into hundreds of dimensions. In such a high-dimensional lattice, certain problems become extremely hard to solve. Specifically, given a random point somewhere near the lattice, finding the closest actual lattice point is a problem that neither classical nor quantum computers can solve efficiently. This is called the "Closest Vector Problem," and ML-DSA's security depends on a related problem called Module Learning With Errors (MLWE).

What does this mean in practice? ML-DSA is fast. A modern computer can generate thousands of signatures per second with ML-DSA. Verification is even faster. Keys and signatures are relatively compact compared to other post-quantum schemes. This makes ML-DSA a natural fit for high-volume applications: web servers handling thousands of TLS connections, code signing pipelines processing hundreds of software releases, or data encryption tools signing documents one after another.

ML-DSA comes in three security levels, each with different key and signature sizes:

Variant	NIST Security Level	Signature Size	Public Key Size	Private Key Size
ML-DSA-44	Level 2 (128-bit)	2,420 bytes	1,312 bytes	2,560 bytes
ML-DSA-65	Level 3 (192-bit)	3,293 bytes	1,952 bytes	4,032 bytes
ML-DSA-87	Level 5 (256-bit)	4,627 bytes	2,592 bytes	4,896 bytes

The numbers (44, 65, 87) refer to the internal matrix dimensions used by the algorithm. Higher numbers mean larger keys and signatures, but also higher security margins. ML-DSA-44 provides security comparable to AES-128, which is considered strong enough for most applications today. ML-DSA-87 provides security comparable to AES-256, which is what governments use for top-secret information.

NIST designates ML-DSA as their primary recommendation for general-purpose digital signatures. If you need a post-quantum signature algorithm and have no specific reason to choose something else, ML-DSA is the default answer.

SLH-DSA: The Ultra-Conservative Backup

SLH-DSA stands for Stateless Hash-Based Digital Signature Algorithm. It was standardized as NIST FIPS 205 in August 2024. During the NIST evaluation, it was known as SPHINCS+.

SLH-DSA takes a completely different approach to security. Instead of relying on lattice mathematics, it relies entirely on hash functions: the same kind of cryptographic functions used in password storage, blockchain, and data integrity checks. Hash functions take any input and produce a fixed-size output (a "digest"). They have three critical properties: you cannot reverse them (given the output, you cannot figure out the input), you cannot find two different inputs that produce the same output, and changing even one bit of the input completely changes the output.

Why does this matter? Hash functions are some of the most studied and best-understood tools in all of cryptography. The SHA family of hash functions has been scrutinized by thousands of researchers for over two decades. We have a deep, mature understanding of what makes hash functions secure. Lattice problems, by comparison, are newer to cryptography. They have been studied seriously since the late 1990s, but that is significantly less time than hash functions have been under the microscope.

SLH-DSA's internal structure combines three building blocks, all constructed purely from hash functions:

WOTS+ (Winternitz One-Time Signatures): A scheme that can sign a single message using only hash chains. You start with a secret value and hash it repeatedly; the number of times you hash encodes the message bits.
FORS (Forest of Random Subsets): A few-time signature scheme that signs short messages by revealing selected leaves from multiple small trees of hash values.
Hypertree: A tree of Merkle trees that chains together many WOTS+ instances, allowing the single public key (the root hash) to authenticate a large number of one-time keys.

The result is a signature algorithm whose security depends on exactly one assumption: that the underlying hash function (SHA-256 or SHAKE256) behaves like a secure hash function. No lattice math. No number theory. No algebraic structure. Just hashing. If the hash function is good, the signatures are unforgeable. Period.

How does this compare to LMS, the other hash-based signature scheme? LMS (standardized in NIST SP 800-208) is also hash-only, but it is stateful: each signature uses up a "leaf" in a Merkle tree, and the key has a fixed maximum number of signatures. SLH-DSA is stateless: you can sign as many times as you want with the same key, just like ML-DSA. The statefulness of LMS makes it simpler and produces smaller signatures, but requires careful tracking of which leaves have been used. SLH-DSA trades larger signatures for the convenience of not having to manage state. For most users, stateless operation is strongly preferred.

The tradeoff for this simplicity is size. SLH-DSA signatures are much larger than ML-DSA signatures:

Variant	NIST Security Level	Signature Size	Public Key Size	Speed (f vs s)
SLH-DSA-128f	Level 1 (128-bit)	17,088 bytes	32 bytes	Fast signing
SLH-DSA-128s	Level 1 (128-bit)	7,856 bytes	32 bytes	Slow signing, smaller sig
SLH-DSA-192f	Level 3 (192-bit)	35,664 bytes	48 bytes	Fast signing
SLH-DSA-256f	Level 5 (256-bit)	49,856 bytes	64 bytes	Fast signing

Notice the "f" and "s" suffixes. Each SLH-DSA security level comes in two flavors: "f" (fast) optimizes for signing speed at the cost of larger signatures, while "s" (small) produces smaller signatures but takes significantly longer to sign. Even the "fast" variants are slower than ML-DSA for signing, though verification speed is reasonable.

Also notice the public key sizes: 32 to 64 bytes. SLH-DSA has the tiniest public keys of any post-quantum signature scheme. The public key is just a hash value. This can be useful in systems where public keys are stored long-term or distributed widely.

Head-to-Head Comparison

Here is a direct comparison between ML-DSA and SLH-DSA across the dimensions that matter most:

Property	ML-DSA (FIPS 204)	SLH-DSA (FIPS 205)
Security basis	Module-LWE lattice problem	Hash function security only
Signature size (128-bit security)	2,420 bytes	7,856 - 17,088 bytes
Public key size (128-bit security)	1,312 bytes	32 bytes
Signing speed	Very fast (thousands/sec)	Slower (tens to hundreds/sec)
Verification speed	Very fast	Moderate
Years of cryptanalysis on underlying math	~25 years (lattices since late 1990s)	~30+ years (hash functions since early 1990s)
NIST recommendation	Primary general-purpose standard	Conservative backup standard
NIST standard number	FIPS 204	FIPS 205
Stateless?	Yes	Yes

The core tradeoff is clear. ML-DSA gives you speed and compactness, built on lattice math that is well-studied but newer to cryptography. SLH-DSA gives you the most conservative security guarantee possible, built on hash functions that have been analyzed for decades, but your signatures will be 7x to 20x larger.

Why NIST Standardized Both

If ML-DSA is faster and more compact, why did NIST bother standardizing SLH-DSA at all? The answer is algorithm diversity, and it is a principle that the cryptographic community takes very seriously.

Every cryptographic algorithm is a bet on a mathematical problem being hard to solve. ML-DSA bets on lattice problems. If someone discovers an efficient algorithm for solving lattice problems (classical or quantum), ML-DSA breaks. That would be a catastrophe if ML-DSA were the only post-quantum signature standard, because every system that adopted it would be vulnerable simultaneously.

SLH-DSA bets on hash functions. A breakthrough against lattice problems would not affect SLH-DSA at all. The two algorithms fail independently. By standardizing both, NIST ensures that the world has a ready-made fallback if lattice-based cryptography is ever compromised. Organizations can deploy SLH-DSA as a second line of defense, or use it for their most sensitive, longest-lived signatures while using ML-DSA for everyday operations.

This is the same philosophy behind hybrid encryption: do not put all your trust in one mathematical assumption. NIST explicitly designed the post-quantum standards portfolio to include algorithms from multiple mathematical families so that no single breakthrough can break everything.

When to Choose ML-DSA

ML-DSA is the right choice for the majority of applications. Choose it when:

You need speed. Web servers, API gateways, and CI/CD pipelines that sign or verify thousands of items per second will benefit from ML-DSA's performance. Signing and verification are both extremely fast.
Bandwidth matters. If signatures are transmitted over a network (TLS handshakes, certificate chains, IoT devices on cellular connections), ML-DSA's 2.4 KB signatures are far more practical than SLH-DSA's 17+ KB signatures.
Storage is a concern. If you are signing millions of software packages, database records, or audit log entries, the per-signature storage cost adds up. ML-DSA keeps that cost low.
You want NIST's primary recommendation. NIST explicitly positions ML-DSA as the default post-quantum signature algorithm. Compliance frameworks that reference NIST standards will default to ML-DSA.

When to Choose SLH-DSA

SLH-DSA is the right choice when the conservative security guarantee outweighs the size and speed costs. Choose it when:

Signatures must be verifiable for decades. If you are signing legal documents, property records, or archival medical records that need to hold up 30 or 50 years from now, SLH-DSA's hash-only security basis provides the strongest assurance that the signatures will still be valid.
You need a hedge against lattice breakthroughs. If your organization's threat model considers the possibility that lattice-based cryptography could be weakened by future research, SLH-DSA provides an independent safety net.
Regulatory requirements demand algorithm diversity. Some compliance frameworks require using algorithms from at least two distinct mathematical families. SLH-DSA satisfies this when paired with lattice-based ML-DSA.
Signature size is acceptable. Firmware images, software releases, and large documents can easily absorb an extra 15-50 KB of signature data without meaningful impact.
You want the smallest possible public keys. SLH-DSA's 32-64 byte public keys are ideal for systems where public keys are stored on constrained devices or embedded in certificates that are cached long-term.

The Quantum Threat to Signatures: Why This Matters Now

You might wonder why you should care about post-quantum signatures today, when large-scale quantum computers do not exist yet. The answer depends on whether you care about the past or just the present.

For encryption, the threat is immediate because of "harvest now, decrypt later" attacks. Adversaries record encrypted data today and store it until quantum computers can decrypt it. For signatures, the threat is different but equally serious. Once quantum computers exist, an attacker could forge signatures on firmware updates, software packages, legal documents, and certificates. If your system trusts signatures created with RSA or ECDSA, a quantum-capable attacker could impersonate any signer, modify any signed document, and inject malicious code into any signed software update.

Migrating to ML-DSA or SLH-DSA now means that the signatures you create today will still be trustworthy in the quantum era. Signatures on legal documents, medical records, and archival materials need to be verifiable for decades. Starting the migration now protects the long-term integrity of everything you sign.

Real-World Use Cases

Hospital Medical Records

A hospital system that signs patient records should use ML-DSA for day-to-day operations: fast signing, compact signatures, minimal overhead on already-complex healthcare IT systems. For long-term archival records that may need to be verified 30+ years later, the hospital might use SLH-DSA to ensure the signatures remain trustworthy regardless of future advances in attacking lattice problems.

Software Distribution

A software company signing thousands of packages per day for distribution to millions of users should use ML-DSA. The combination of fast signing, fast verification, and compact signatures keeps the distribution pipeline efficient. Every extra kilobyte in a signature is multiplied by millions of downloads.

Root Certificate Authorities

A certificate authority that signs a root certificate once every 10-20 years might choose SLH-DSA for that root signature, since it will need to be trusted for decades and the signature is only generated once. Intermediate certificates, signed more frequently, could use ML-DSA.

QNSQY's Approach

QNSQY provides both algorithms, and combines them with classical cryptography for defense-in-depth:

Hybrid ML-DSA + Ed25519: The default signing mode. Your file gets both a post-quantum signature (ML-DSA) and a classical signature (Ed25519). An attacker would need to break both to forge a signature. Available on Pro tier and above.
SLH-DSA options: All six SLH-DSA parameter sets (128/192/256, f/s) are available on Pro tier. Choose the security level and speed/size tradeoff that fits your needs.
ML-DSA-44 (Free tier): Basic quantum-safe signing is available to everyone at no cost, with no file size restrictions.

For most users, the hybrid ML-DSA + Ed25519 mode is the right default. It provides both post-quantum and classical security with minimal overhead. Switch to SLH-DSA when you need the most conservative security guarantee available, and the larger signatures are acceptable for your use case.

The Short Version

Question	ML-DSA	SLH-DSA
Is it quantum-safe?	Yes	Yes
Is it NIST-approved?	Yes (FIPS 204)	Yes (FIPS 205)
Is it fast?	Very	Moderate
Are signatures compact?	Yes (2.4 - 4.6 KB)	No (7.8 - 49.9 KB)
Is the security assumption conservative?	Good (lattices)	Best possible (hash functions only)
Best for?	Everyday signing, high volume	Long-term archival, maximum assurance

Sources

Sign Your Files with Confidence

QNSQY Pro includes both ML-DSA and SLH-DSA signing options. Business adds FN-DSA (Falcon) and LMS.

View Pricing

Originally published at quantumsequrity.com.

ML-KEM: Future of Key Encapsulation

Quantum Sequrity — Thu, 07 May 2026 13:00:34 +0000

ML-KEM: Future of Key Encapsulation

Cryptography

Understanding ML-KEM: The Future of Key Encapsulation

14 min read

What Problem Does ML-KEM Solve?

Every time you buy something online, log into your email, or send a private message, your computer needs to do something tricky: it needs to agree on a secret code with another computer, over an open connection that anyone could be watching.

Think about it like this. You and a friend are standing on opposite sides of a crowded room. You need to agree on a secret word that only the two of you will know. But everyone in the room can hear everything you say. How do you do it?

This is the "key agreement" problem, and it is one of the most important problems in all of computer security. For the past 30 years, we have solved it using mathematical tricks based on the difficulty of factoring very large numbers (RSA) or computing discrete logarithms on elliptic curves (ECDH). These tricks work because regular computers simply cannot do those calculations fast enough to break them in any reasonable time.

ML-KEM is a new solution to this problem. It stands for Module-Lattice Key Encapsulation Mechanism, and it was standardized by NIST as FIPS 203 in August 2024. The reason we need it is simple: quantum computers can solve those old mathematical problems very quickly. ML-KEM uses different math that quantum computers cannot crack.

Key Encapsulation vs. Key Exchange: A Subtle but Important Difference

You might hear the terms "key exchange" and "key encapsulation" used interchangeably, but they are actually different operations. Understanding the difference helps you understand what ML-KEM actually does.

In a traditional key exchange (like Diffie-Hellman or ECDH), both parties contribute equally. Each side generates a value, they swap those values, and then both sides independently calculate the same shared secret. Neither party alone chose the secret; it emerged from the combination of both contributions.

In a key encapsulation mechanism (KEM), the process is asymmetric. One party (let us call them Alice) publishes a public key. The other party (Bob) uses that public key to generate a random shared secret and produce a "ciphertext" that only Alice can open. Bob sends the ciphertext to Alice. Alice uses her private key to "decapsulate" it and recover the same shared secret. The secret was chosen by Bob's side of the process, and the ciphertext acts like a locked box that only Alice's private key can open.

The practical result is the same: both parties end up with the same shared secret that nobody else knows. But the KEM approach turns out to be much easier to build securely from lattice mathematics, which is why NIST chose it for the post-quantum standard.

Why Current Encryption Will Break

To understand why we need ML-KEM, you need to understand what quantum computers change. Today, virtually all key agreement on the internet relies on one of two mathematical problems:

Integer factorization (used by RSA): Given two very large prime numbers multiplied together, find the original primes. A 2048-bit RSA key means the product is roughly 617 digits long. Classical computers cannot factor numbers this large in any practical timeframe.
Elliptic curve discrete logarithm (used by ECDH and X25519): Given a point on a mathematical curve that was reached by "walking" some number of steps from a starting point, figure out how many steps were taken. With 256-bit curves, the number of possible answers is astronomically large.

In 1994, mathematician Peter Shor published an algorithm showing that a quantum computer could solve both of these problems exponentially faster than any classical computer. For RSA-2048, a classical supercomputer would need roughly 300 trillion years. A sufficiently powerful quantum computer running Shor's algorithm could do it in hours.

The key phrase is "sufficiently powerful." Today's quantum computers have a few thousand noisy qubits. Breaking RSA-2048 would require roughly 4,000 error-corrected logical qubits, which translates to millions of physical qubits with current error correction technology. We are not there yet. But quantum hardware is improving rapidly, and the consensus among researchers is that cryptographically relevant quantum computers will arrive within 10 to 20 years. NIST began the standardization process in 2016 specifically because cryptographic transitions take many years, and waiting until quantum computers exist would be far too late.

The Lattice Problem: Why ML-KEM Is Hard to Break

ML-KEM is built on a mathematical structure called a lattice. A lattice, in mathematical terms, is a regular grid of points in space. Think of tiles on a bathroom floor: a perfectly repeating grid in two dimensions. Now imagine that grid extended into three dimensions, like a crystal structure. Now imagine it in 256 dimensions, or 512, or 1024. You cannot visualize this, and that is exactly the point.

The specific hard problem ML-KEM relies on is called the Module Learning With Errors (Module-LWE) problem. Here is a simplified version of how it works:

Imagine you have a system of equations like this: you know a matrix A (public), and you are given a result b that equals A times some secret vector s, plus a small amount of random noise e. Your goal is to figure out the secret s. Without the noise, this would be basic linear algebra, solvable by any college freshman. But the noise makes it brutally hard. With enough dimensions (hundreds or thousands), no known algorithm, classical or quantum, can efficiently separate the signal from the noise.

An analogy: imagine someone tells you the result of a calculation, but they have rounded every intermediate step slightly and randomly. From the rounded result, you need to work backwards to find the exact original inputs. In two or three dimensions, you might manage it. In 768 dimensions, even the most powerful computer we can imagine cannot do it.

Grover's algorithm, which gives quantum computers a general speedup for search problems, does apply here, but only as a square-root speedup. That means a lattice problem with 256-bit security against classical computers still has roughly 128-bit security against quantum computers. ML-KEM's parameter sets are designed to account for this, so all three security levels remain robust even against quantum attackers.

How ML-KEM Works Step by Step

The ML-KEM process has three operations: key generation, encapsulation, and decapsulation.

1. Key Generation

Alice's computer generates a random secret (the private key) and uses it along with a public matrix A to create a public key. The public key contains A and a value t that is computed as A*s + e, where s is the secret and e is random noise. Alice publishes the public key and keeps the private key hidden.

2. Encapsulation

Bob wants to establish a shared secret with Alice. His computer takes Alice's public key and generates a fresh random value. Using that random value plus Alice's public key, his computer produces two things: a ciphertext c (which is safe to send publicly), and a shared secret key K (which Bob keeps). The ciphertext is essentially the random value encrypted in a way that only Alice's private key can reverse.

3. Decapsulation

Alice receives the ciphertext c and uses her private key to recover the same shared secret K. At this point, both Alice and Bob have the same key K. They can now use K as the key for a symmetric cipher like AES-256-GCM to encrypt their actual messages.

ML-KEM also includes an important safety feature called an "implicit rejection" mechanism. If someone sends Alice a malformed ciphertext (either by accident or as an attack), instead of producing an error message that might leak information, the decapsulation produces a random-looking output derived from the private key and the ciphertext. This prevents a class of attacks called "chosen ciphertext attacks" where an attacker tries to learn about the private key by observing how the system responds to bad inputs.

The Three Security Levels

FIPS 203 defines three parameter sets for ML-KEM. Each one represents a different trade-off between security strength and performance. The numbers in the names (512, 768, 1024) refer to the dimension of the lattice used.

Parameter Set	NIST Security Level	Equivalent Strength	Public Key Size	Ciphertext Size
ML-KEM-512	Level 1	At least as hard to break as AES-128	800 bytes	768 bytes
ML-KEM-768	Level 3	At least as hard to break as AES-192	1,184 bytes	1,088 bytes
ML-KEM-1024	Level 5	At least as hard to break as AES-256	1,568 bytes	1,568 bytes

To put "128-bit security" in perspective: it means an attacker would need to perform approximately 2^128 operations to break the encryption. That number, 340 undecillion (340 followed by 36 zeros), exceeds the estimated number of atoms in the observable universe. Even a quantum computer running Grover's algorithm against a 128-bit target would need 2^64 operations, which is still computationally infeasible.

Notice that these key sizes are significantly larger than classical alternatives. An X25519 public key is only 32 bytes. An ML-KEM-768 public key is 1,184 bytes, roughly 37 times larger. This is one of the practical trade-offs of post-quantum cryptography. The math that resists quantum attacks requires bigger numbers, which means bigger keys. For data encryption, this overhead is negligible. For protocols like TLS that perform many key exchanges per second, it matters more, which is one reason Google's Chrome team worked hard to optimize their ML-KEM deployment.

How Fast Is ML-KEM?

Despite the larger key sizes, ML-KEM is remarkably fast. On modern hardware, the three operations take approximately:

Key generation: approximately 30 microseconds for ML-KEM-768
Encapsulation: approximately 40 microseconds for ML-KEM-768
Decapsulation: approximately 40 microseconds for ML-KEM-768

For comparison, RSA-2048 key generation takes tens of milliseconds (hundreds of times slower), and even X25519, which is considered very fast, takes about 120 microseconds per key exchange operation. ML-KEM is actually faster than most classical key agreement algorithms at the computational step itself. The only real overhead is the additional bytes transmitted for the larger keys and ciphertexts.

In a data encryption context, the KEM operation happens once per file. The actual data encryption (using AES-256-GCM) dominates the total time. Whether you encrypt a 1 MB document or a 25 GB video, the ML-KEM step adds well under a millisecond.

The NIST Standardization Process

ML-KEM did not appear out of nowhere. It is the result of an eight-year public process that is one of the most thorough algorithm evaluations in cryptographic history.

In December 2016, NIST issued a call for proposals for post-quantum cryptographic algorithms. They received 82 submissions from research teams around the world. Over three rounds of evaluation (2017-2020, 2020-2022, and 2022-2024), NIST and the global cryptography community analyzed each submission for security, performance, and implementation characteristics.

The algorithm that became ML-KEM was originally submitted as "CRYSTALS-Kyber" by a team of researchers from Europe. It survived every round, was selected as a finalist, and was published as FIPS 203 on August 13, 2024. During the evaluation, hundreds of published papers analyzed Kyber's security. Multiple research teams attempted to find weaknesses. The algorithm was also tested against side-channel attacks (where an attacker tries to learn secrets by measuring how long operations take or how much power the computer uses).

The fact that ML-KEM survived eight years of concentrated attack by the world's best cryptanalysts is the strongest evidence for its security. No algorithm can be mathematically proven secure in an absolute sense (this is true of all public-key cryptography, classical or post-quantum). But ML-KEM has passed the most rigorous public evaluation process ever conducted for a cryptographic standard.

Why Hybrid: ML-KEM + X25519 Together

QNSQY never uses ML-KEM alone. Every encryption operation combines ML-KEM with X25519, a classical elliptic curve algorithm. This approach is called "hybrid" cryptography, and major security organizations including NIST, NSA, ENISA (the EU cybersecurity agency), and BSI (Germany's Federal Office for Information Security) all recommend it.

The reasoning is straightforward. ML-KEM has been publicly studied for about nine years. X25519 has been publicly studied for about fifteen years and has been deployed in billions of devices. ML-KEM is believed to be secure against quantum computers but is relatively new. X25519 is thoroughly proven against classical computers but will fall to quantum attacks.

By combining both, QNSQY runs two independent key encapsulation operations and feeds both results into a key derivation function (HKDF-SHA3-256) to produce the final encryption key. An attacker must break both ML-KEM and X25519 to recover the key. If ML-KEM were somehow broken by a classical attack nobody anticipated, X25519 still protects the data. If a quantum computer breaks X25519, ML-KEM still protects the data. You need to defeat both locks to get in.

NIST published guidance on hybrid approaches in SP 800-227, specifically addressing how to safely combine post-quantum and classical algorithms during the transition period. The hybrid approach adds minimal computational overhead (both key operations complete in well under a millisecond combined) and provides meaningful insurance against unexpected cryptanalytic breakthroughs in either family of algorithms.

Common Misconceptions About ML-KEM

Several misunderstandings about ML-KEM circulate online. Clearing these up helps you make informed decisions.

"ML-KEM is unproven and experimental"

ML-KEM is a published NIST Federal Information Processing Standard (FIPS 203). It went through an eight-year public evaluation that is more rigorous than the process that standardized AES. The underlying mathematics (lattice problems, Learning With Errors) have been studied in academic cryptography since the 1990s. Oded Regev's foundational work on LWE was published in 2005, giving the core mathematical problem over 20 years of scrutiny. ML-KEM is not experimental. It is a vetted, standardized algorithm.

"Post-quantum algorithms are too slow for practical use"

This was partially true for early candidates, but ML-KEM is one of the fastest public-key cryptographic algorithms ever standardized. Its key generation, encapsulation, and decapsulation are faster than RSA operations at comparable security levels and comparable to X25519. The only trade-off is key size, not speed.

"We can wait until quantum computers are closer"

This ignores two facts. First, cryptographic transitions take years. Moving the entire internet from DES to AES took over a decade. Organizations with large deployed systems need time to plan, test, and migrate. Second, the "harvest now, decrypt later" attack means that data encrypted today with vulnerable algorithms is already at risk from future quantum computers. If your data needs to remain secret for 10 or more years, the time to act was yesterday.

"AES-256 is already quantum-safe, so we do not need ML-KEM"

AES-256 is quantum-safe for the encryption step, but AES is a symmetric cipher. It requires both parties to already share the same key. ML-KEM solves the key agreement problem: how two parties who have never communicated establish a shared AES key in the first place. Without quantum-safe key agreement, AES-256 cannot protect data because the key exchange itself is vulnerable. ML-KEM and AES-256 solve different parts of the encryption problem and are used together.

What ML-KEM Means for Your Files

When you encrypt a file with QNSQY, here is what happens at the ML-KEM level:

QNSQY generates a fresh ML-KEM keypair and a fresh X25519 keypair for this encryption.
The encapsulation step produces two shared secrets: one from ML-KEM and one from X25519.
Your password is processed through Argon2id (a memory-hard key derivation function) to produce a third key component.
All three components are combined via HKDF-SHA3-256 to produce the final AES-256-GCM encryption key.
The file content is encrypted with AES-256-GCM using that key.
The ML-KEM ciphertext, X25519 public key, Argon2id salt, and encrypted data are packaged into a .qs file.

When you decrypt, the reverse happens: your password regenerates the Argon2id component, the KEM ciphertexts are decapsulated with the private keys (which are themselves derived from the password), and all three are recombined to produce the same AES-256-GCM key.

The result is a file that is protected by three independent factors: the strength of ML-KEM against quantum computers, the proven strength of X25519 against classical computers, and the strength of your password processed through memory-hard Argon2id. All three would need to fail simultaneously for the encryption to be broken.

Sources

Ready to Protect Your Data?

QNSQY uses ML-KEM + X25519 hybrid encryption in all tiers, including the free version.

Originally published at quantumsequrity.com.

Lattice-Based Cryptography: Foundation of PQC

Quantum Sequrity — Wed, 06 May 2026 13:00:46 +0000

Lattice-Based Cryptography: Foundation of PQC

Education

Lattice-Based Cryptography: Foundation of PQC

12 min read

Why Lattices Matter

Three of the four algorithms NIST selected for post-quantum standardization in 2022 are built on lattice mathematics: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and FN-DSA (draft FIPS 206 (draft)) for compact signatures. Lattice-based cryptography is, by selection volume, the dominant foundation of the post-quantum era.

This article explains what lattices are, why the mathematical problems they pose are believed to resist quantum computers, and how ML-KEM and ML-DSA translate those hard problems into practical encryption and signing algorithms. Every claim about hardness, history, and algorithm design is grounded in published academic research and NIST documentation.

What Is a Lattice?

A lattice is a regular, repeating grid of points in multi-dimensional space. In two dimensions, think of an infinite sheet of graph paper where every intersection is a lattice point. Mathematically, a lattice is defined by a set of basis vectors: you generate every point in the lattice by taking integer combinations of those basis vectors.

For example, in two dimensions, if your basis vectors are (1, 0) and (0, 1), you get the standard integer grid. But basis vectors do not have to be perpendicular or unit length. The vectors (2, 1) and (1, 3) also define a lattice, just one with a different shape and spacing.

Cryptographic lattices exist in hundreds or thousands of dimensions, not just two. This is crucial, because the problems that are easy in low dimensions become extraordinarily hard in high dimensions.

Hard Problems on Lattices

The security of lattice-based cryptography rests on the computational difficulty of certain geometric problems. The two foundational problems are the Shortest Vector Problem and the Closest Vector Problem.

The Shortest Vector Problem (SVP)

Given a lattice (defined by its basis), find the shortest non-zero vector in the lattice. In two dimensions, this is trivial: you can visually inspect the grid. In 500 dimensions, no known algorithm can solve it efficiently. The best known classical algorithms, based on lattice sieving (a technique that searches for short vectors by combining slightly longer ones), run in exponential time: roughly 2^0.292n where n is the lattice dimension.

Critically, the best known quantum algorithms for SVP do not do fundamentally better. Quantum sieving achieves roughly 2^0.265n, which is a modest constant-factor improvement, not the exponential speedup that Shor's algorithm provides against RSA and elliptic curve cryptography. There is no known polynomial-time quantum algorithm for SVP, and the problem has been studied for over 40 years.

The Closest Vector Problem (CVP)

Given a lattice and an arbitrary target point in space, find the lattice point closest to the target. CVP is at least as hard as SVP (there are known reductions from SVP to CVP), and it similarly resists both classical and quantum computation in high dimensions. CVP is the geometric intuition behind the Learning With Errors problem described below.

Learning With Errors: The Core Hard Problem

The Learning With Errors (LWE) problem was introduced by Oded Regev in 2005. Regev proved a remarkable result: solving LWE on average is at least as hard as solving several standard lattice problems (including approximate SVP) in the worst case. This worst-case-to-average-case reduction is one of the strongest security guarantees in all of cryptography.

Here is how LWE works. You have a secret vector s with n integer components. You also have a public random matrix A. You compute the product A * s and then add a small random error vector e to get:

b = A * s + e
Where A is a public random matrix, s is the secret, and e is a small error vector. Given (A, b), recovering s is believed to be hard, even for quantum computers.

The addition of the small error e is what makes the problem hard. Without error, recovering s from A and b is straightforward linear algebra (Gaussian elimination). But the error transforms it into a problem equivalent to finding the closest lattice point to a noisy target, which is a variant of CVP.

The genius of Regev's 2005 result is the connection: anyone who can efficiently solve LWE can also solve worst-case lattice problems like approximate SVP. Since no one has found efficient algorithms for SVP in over four decades of trying (including with quantum computers), we have strong confidence that LWE is hard.

From LWE to Module-LWE

Plain LWE works, but it has a practical drawback: the public matrix A is enormous. For cryptographically relevant dimensions (n = 512 or higher), storing and transmitting a fully random matrix requires megabytes of data. This is impractical for real-world cryptography.

The solution is structured lattices. In 2010, Vadim Lyubashevsky, Chris Peikert, and Oded Regev introduced Ring-LWE, which replaces the random matrix with a structured matrix derived from polynomial rings. This dramatically reduces key sizes while preserving provable security reductions (though to slightly different lattice problems, namely the hardness of ideal lattices).

Module-LWE (MLWE), used by both ML-KEM and ML-DSA, is a middle ground between plain LWE and Ring-LWE. Instead of a single polynomial ring element, Module-LWE works over small matrices of polynomial ring elements. This provides:

Efficiency: Keys and ciphertexts are orders of magnitude smaller than plain LWE
Flexibility: Security levels can be adjusted by changing the module rank (the matrix dimension) rather than the underlying ring
Conservative security: The security assumption (Module-LWE hardness) is weaker than Ring-LWE's assumption (ideal lattice hardness), meaning MLWE is at least as hard to break and likely harder

NIST chose Module-LWE as the basis for both ML-KEM and ML-DSA precisely because of this balance between efficiency and security conservatism.

How ML-KEM Uses Lattice Cryptography

ML-KEM (FIPS 203) is a key encapsulation mechanism: it allows two parties to establish a shared secret key over an insecure channel. Here is a simplified description of how it works:

Key generation: The receiver generates a random secret vector s and a public matrix A (derived from a seed for compactness). The public key is (A, b = A*s + e) where e is small noise. The private key is s.
Encapsulation: The sender generates a random message m, derives a random vector r, and computes ciphertext components using the public key. The ciphertext encodes m in a way that is obscured by the MLWE problem.
Decapsulation: The receiver uses the private key s to compute an approximation of the encoded message. Because s is the secret, the noise can be stripped away and m recovered exactly. The shared secret is then derived from m using a hash function.

An attacker who intercepts the public key and ciphertext faces the MLWE problem: they would need to recover s from (A, b), which requires solving approximate SVP on a high-dimensional lattice. No known classical or quantum algorithm can do this efficiently.

How ML-DSA Uses Lattice Cryptography

ML-DSA (FIPS 204) is a digital signature algorithm based on a "Fiat-Shamir with Aborts" framework applied to the MLWE problem. The construction works differently from ML-KEM but relies on the same underlying lattice hardness:

Key generation: Generate a secret signing key consisting of short polynomial vectors (s1, s2). The public verification key contains a matrix A and the value t = A*s1 + s2.
Signing: To sign a message, the signer picks a random masking vector y, computes w = A*y, hashes (w, message) to get a challenge c, and computes the response z = y + c*s1. The critical step is a rejection sampling check: if z would leak information about s1 (because it is too large or has the wrong distribution), the signer discards the attempt and tries again with a new y. This "abort" mechanism ensures that published signatures reveal nothing about the secret key.
Verification: The verifier checks that A*z - c*t is close to the original commitment w and that z is within acceptable bounds. This can be done using only the public key.

The security argument is that forging a signature requires either recovering the short secret vectors (s1, s2) from the public key (which is the MLWE problem) or finding a valid (z, c) pair without knowing the secret (which requires solving a related hard lattice problem).

NIST Security Levels

NIST defines five security levels for post-quantum algorithms, based on the computational effort required to break them. The levels are defined relative to the cost of breaking specific symmetric algorithms:

NIST Level	Equivalent Security	ML-KEM Parameter Set	ML-DSA Parameter Set
Level 1	At least as hard as breaking AES-128	ML-KEM-512	ML-DSA-44
Level 3	At least as hard as breaking AES-192	ML-KEM-768	ML-DSA-65
Level 5	At least as hard as breaking AES-256	ML-KEM-1024	ML-DSA-87

The numbers in the parameter set names (512, 768, 1024 for ML-KEM; 44, 65, 87 for ML-DSA) refer to internal parameters: the module rank and polynomial degree for ML-KEM, and the matrix dimensions for ML-DSA. Higher values mean larger keys and signatures but stronger security margins.

For most applications, NIST Level 1 (ML-KEM-512 / ML-DSA-44) provides ample security. Level 3 and Level 5 are recommended for classified data, long-term secrets (data that must remain confidential for 30+ years), or environments with stringent regulatory requirements.

Advantages of Lattice-Based Cryptography

Performance: Lattice operations involve matrix-vector multiplication over polynomial rings, which is highly parallelizable and fast on modern hardware. ML-KEM key generation, encapsulation, and decapsulation each complete in microseconds on standard processors.
Reasonable key sizes: ML-KEM-768 public keys are 1,184 bytes and ciphertexts are 1,088 bytes. While larger than X25519's 32-byte keys, these sizes are practical for all modern applications including TLS, email, and data encryption.
Strong theoretical foundations: Worst-case-to-average-case reductions (Regev 2005, Lyubashevsky-Peikert-Regev 2010) provide security guarantees that most other cryptographic assumptions lack. Breaking the average-case cryptosystem implies solving worst-case lattice problems.
Versatility: The same lattice framework supports KEMs, signatures, fully homomorphic encryption, and other advanced primitives. This makes lattice cryptography a long-term investment for the research community and implementers.
Extensive analysis: Lattice problems have been studied in mathematics and computer science since the work of Minkowski in the 1890s. The cryptographic applications have been under intense scrutiny since at least 1996 (Ajtai's worst-case hardness results). CRYSTALS-Kyber and CRYSTALS-Dilithium specifically have been publicly analyzed since their submission to NIST in 2017.

Limitations and Open Questions

No cryptographic system is without tradeoffs. Lattice-based cryptography has several limitations worth understanding:

Larger keys and ciphertexts than classical crypto: ML-KEM-768 keys are about 37 times larger than X25519 keys. For most applications this is acceptable, but for extremely constrained devices (smart cards, IoT sensors with minimal memory) it can be a challenge.
Newer than RSA and ECC: While lattice problems have a long mathematical history, their use in deployed cryptographic systems is recent. RSA has been in production since the 1970s and ECC since the 2000s. Lattice-based systems have only been standardized since 2024.
Structured lattice assumptions: The efficiency of ML-KEM and ML-DSA comes from using structured (Module-LWE) rather than unstructured (plain LWE) lattices. While no attack exploiting this structure has been found, it remains a theoretical concern. This is one reason NIST selected the hash-based SLH-DSA (FIPS 205) and the code-based HQC as non-lattice alternatives.
No unconditional security proof: LWE's security is based on the assumed hardness of lattice problems. If someone discovers a polynomial-time algorithm for SVP (classical or quantum), all lattice-based cryptography would be broken. The cryptographic community considers this extremely unlikely given decades of failed attempts, but it is not mathematically proven to be impossible.

Why Hybrid Deployment Is Essential

Given these considerations, the security community recommends hybrid deployment: combining a lattice-based algorithm with a classical algorithm in every operation. QNSQY implements this by pairing ML-KEM with X25519 for key encapsulation and ML-DSA with Ed25519 for signatures.

In a hybrid scheme, an attacker must break both algorithms to compromise the operation. If a breakthrough breaks lattice cryptography, X25519 and Ed25519 still protect the data (until quantum computers large enough to run Shor's algorithm are built). If quantum computers break X25519 and Ed25519, ML-KEM and ML-DSA still protect the data. The combined system is at least as strong as the stronger of the two components.

This defense-in-depth approach is consistent with guidance from NIST, NSA (CNSA 2.0), and the European Union Agency for Cybersecurity (ENISA). It is the safest strategy during the transition period when both classical and post-quantum algorithms are being deployed and tested at scale.

Sources

FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (NIST, August 2024)
FIPS 204: Module-Lattice-Based Digital Signature Standard (NIST, August 2024)
Regev, O. "On lattices, learning with errors, random linear codes, and cryptography." Journal of the ACM 56.6 (2009): 34. Originally presented at STOC 2005.
Lyubashevsky, V., Peikert, C., and Regev, O. "On ideal lattices and learning with errors over rings." Journal of the ACM 60.6 (2013): 43. Originally presented at EUROCRYPT 2010.
NIST Post-Quantum Cryptography Project
CRYSTALS: Cryptographic Suite for Algebraic Lattices (ML-KEM and ML-DSA reference implementations)

Protect Your Data with Lattice-Based Cryptography

QNSQY uses ML-KEM + X25519 hybrid encryption and ML-DSA + Ed25519 hybrid signatures on every tier, including free.

Originally published at quantumsequrity.com.

NIST FIPS 203/204/205: The Complete Guide Blog

Quantum Sequrity — Tue, 05 May 2026 13:01:11 +0000

Research

NIST FIPS 203/204/205: The Complete Guide

14 min read

Who is NIST, and Why Do Their Standards Matter?

NIST is the National Institute of Standards and Technology, a non-regulatory agency within the U.S. Department of Commerce. NIST does not make laws or enforce regulations. What it does is publish technical standards that define how things should work, from the length of a meter to the algorithms that protect your bank account.

When it comes to cryptography, NIST's standards are the global reference. The U.S. government requires all federal agencies and their contractors to use NIST-approved cryptographic algorithms. But NIST's influence extends far beyond government. Financial institutions, healthcare organizations, technology companies, and critical infrastructure operators worldwide adopt NIST standards because they represent the consensus of the global cryptographic research community. When NIST says an algorithm is safe to use, it means that hundreds of the world's best mathematicians and computer scientists have tried to break it and failed.

FIPS stands for Federal Information Processing Standards. A FIPS publication is the highest level of standard NIST issues for information technology. When an algorithm receives a FIPS number, it means NIST has fully vetted it and considers it ready for production use in systems that protect sensitive information. AES (the encryption algorithm that protects nearly everything on the internet) is FIPS 197. SHA-2 (the hash function used in Bitcoin, TLS, and countless other systems) is FIPS 180-4. These are the standards the world runs on.

In August 2024, NIST published three new FIPS standards for post-quantum cryptography: FIPS 203, FIPS 204, and FIPS 205. A fourth, FIPS 206 (draft), is in draft. Together with the existing SP 800-208, these standards define the complete set of algorithms designed to protect information against attacks by both classical and quantum computers.

The Complete Standards at a Glance

Standard	Algorithm	Purpose	Status	Math Family
FIPS 203	ML-KEM	Key encapsulation (key exchange)	Final (Aug 2024)	Lattice
FIPS 204	ML-DSA	Digital signatures	Final (Aug 2024)	Lattice
FIPS 205	SLH-DSA	Digital signatures (conservative)	Final (Aug 2024)	Hash-based
FIPS 206 (draft)	FN-DSA	Digital signatures (compact)	Draft	Lattice (NTRU)
SP 800-208	LMS / XMSS	Stateful hash-based signatures	Final (Oct 2020)	Hash-based

FIPS 203: ML-KEM (Key Encapsulation)

ML-KEM stands for Module-Lattice-Based Key Encapsulation Mechanism. Before NIST standardized it, it was known as CRYSTALS-Kyber. ML-KEM replaces the key exchange algorithms that quantum computers will break: RSA key exchange and Elliptic Curve Diffie-Hellman (ECDH).

To understand what ML-KEM does, think about how two people can agree on a secret in a room full of eavesdroppers. Imagine Alice wants to send Bob a secret message, but Eve is listening to every word they say. Alice cannot just whisper the encryption key to Bob, because Eve will hear it. Key encapsulation solves this problem: Alice and Bob can agree on a shared secret, in plain earshot of Eve, without Eve being able to figure out what the secret is.

The process works like this:

Bob generates a key pair: a public key (which he shares openly) and a private key (which he keeps secret).
Alice "encapsulates" a random secret using Bob's public key. This produces a ciphertext and the shared secret.
Alice sends the ciphertext to Bob. Eve can see this ciphertext, but it is useless to her without Bob's private key.
Bob "decapsulates" the ciphertext using his private key, recovering the same shared secret that Alice generated.
Alice and Bob now share a secret key that they use for symmetric encryption (like AES-256-GCM) to protect their actual communications.

ML-KEM's security is based on the Module Learning With Errors (MLWE) problem. In simplified terms: take a lattice (a regular grid of points in high-dimensional space), add small random errors to it, and the resulting noisy data is computationally indistinguishable from truly random data. Extracting the original lattice structure from the noisy data is a problem that neither classical nor quantum computers can solve efficiently.

ML-KEM comes in three sizes:

ML-KEM-512: NIST Level 1 (128-bit security). Public key: 800 bytes. Ciphertext: 768 bytes. Fast and compact.
ML-KEM-768: NIST Level 3 (192-bit security). Public key: 1,184 bytes. Ciphertext: 1,088 bytes. The balanced option.
ML-KEM-1024: NIST Level 5 (256-bit security). Public key: 1,568 bytes. Ciphertext: 1,568 bytes. Maximum security margin.

For comparison, a classical RSA-2048 public key is 256 bytes and its ciphertext is 256 bytes, but RSA is completely broken by quantum computers. ML-KEM keys are larger, but they actually provide security in the quantum era.

NIST designates ML-KEM as the primary recommendation for post-quantum key encapsulation. In March 2025, NIST also selected HQC (Hamming Quasi-Cyclic), a code-based KEM, as a backup algorithm built on different mathematical assumptions. HQC provides algorithm diversity: if a breakthrough compromises lattice-based cryptography, HQC remains secure because its security depends on error-correcting code problems instead. ML-KEM is faster and more compact; HQC is the insurance policy.

FIPS 204: ML-DSA (Digital Signatures)

ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm. Before standardization, it was known as CRYSTALS-Dilithium. ML-DSA replaces the signature algorithms that quantum computers will break: RSA signatures and ECDSA.

Where ML-KEM solves the problem of agreeing on a shared secret, ML-DSA solves the problem of proving identity and data integrity. A digital signature proves that a specific person or organization created or approved a piece of data, and that the data has not been modified since it was signed.

Think of it as a mathematical notary stamp. When your phone checks a software update, it verifies a digital signature to ensure the update was actually published by the developer and was not modified by an attacker in transit. When your browser connects to your bank, it verifies a chain of digital signatures on the bank's certificate to confirm the site is genuine.

ML-DSA uses the same lattice mathematics as ML-KEM (the MLWE problem), but applied to the different problem of creating and verifying signatures. It comes in three security levels:

ML-DSA-44: NIST Level 2 (128-bit security). Signature: 2,420 bytes. Public key: 1,312 bytes.
ML-DSA-65: NIST Level 3 (192-bit security). Signature: 3,309 bytes. Public key: 1,952 bytes.
ML-DSA-87: NIST Level 5 (256-bit security). Signature: 4,627 bytes. Public key: 2,592 bytes.

ML-DSA is NIST's primary recommendation for general-purpose post-quantum digital signatures. It is fast (thousands of signatures per second on modern hardware), reasonably compact, and well-understood. If you need a post-quantum signature algorithm and have no specific reason to choose otherwise, ML-DSA is the answer.

FIPS 205: SLH-DSA (Conservative Signatures)

SLH-DSA stands for Stateless Hash-Based Digital Signature Algorithm. Before standardization, it was known as SPHINCS+. SLH-DSA does the same job as ML-DSA (digital signatures), but with a completely different approach to security.

While ML-DSA relies on lattice mathematics, SLH-DSA relies only on hash functions (SHA-256, SHA-512, SHAKE128, SHAKE256). Hash functions are the most studied and best-understood primitives in all of cryptography. They have been analyzed intensively for over 30 years. SLH-DSA's security proof boils down to: if the underlying hash function is secure, the signatures are unforgeable.

Why did NIST standardize SLH-DSA if ML-DSA already exists? Algorithm diversity. If a mathematical breakthrough compromises lattice problems, ML-DSA and ML-KEM would both be affected. SLH-DSA would be completely unaffected, because its security depends on different mathematics. SLH-DSA is the safety net.

The tradeoff is size. SLH-DSA signatures are much larger than ML-DSA signatures:

SLH-DSA-128f: 17,088-byte signatures, but only 32-byte public keys
SLH-DSA-192f: 35,664-byte signatures, but only 48-byte public keys
SLH-DSA-256f: 49,856-byte signatures, but only 64-byte public keys

Each parameter set comes in "f" (fast signing, larger signatures) and "s" (slower signing, smaller signatures) variants. SLH-DSA is best suited for applications where the security guarantee matters more than signature size: long-term archival, root certificates, regulatory requirements for hash-based algorithms.

FIPS 206 (draft) (Draft): FN-DSA (Compact Signatures)

FN-DSA stands for FFT over NTRU-Lattice-Based Digital Signature Algorithm, formerly known as Falcon. FIPS 206 (draft) is currently in draft form, with finalization expected around 2027.

FN-DSA produces the smallest post-quantum signatures of any standardized algorithm. An FN-DSA-512 signature is about 666 bytes, compared to ML-DSA-44's 2,420 bytes. This 3.6x size advantage matters in bandwidth-constrained environments: TLS certificate chains, IoT devices, blockchain transactions.

The tradeoff is implementation complexity. FN-DSA's signing process requires high-precision floating-point arithmetic, and subtle implementation errors can leak secret key information through side-channel attacks. This is why NIST recommends ML-DSA as the default and positions FN-DSA as a secondary option for specific use cases where compact signatures are critical.

FN-DSA uses NTRU lattices, a different type of lattice from the module lattices used by ML-DSA and ML-KEM. This means FN-DSA provides algorithm diversity even within the lattice family.

SP 800-208: LMS and XMSS (Stateful Signatures)

NIST SP 800-208 standardizes two stateful hash-based signature schemes: LMS (Leighton-Micali Signatures, based on RFC 8554) and XMSS (eXtended Merkle Signature Scheme, based on RFC 8391). These were published in October 2020, predating the FIPS standards by nearly four years.

Like SLH-DSA, LMS and XMSS rely only on hash functions for their security. The difference is that LMS/XMSS are stateful: each signature uses up a "leaf" in a Merkle tree, and the key can only produce a fixed number of signatures determined at key creation time. Reusing a leaf (signing twice with the same one-time key) completely breaks security.

This statefulness limits LMS/XMSS to use cases where the number of signatures is bounded and predictable, such as firmware signing, code signing, and bootloader verification. The NSA's CNSA 2.0 suite specifically requires LMS or XMSS for these applications.

The advantage of statefulness is simplicity. LMS has a shorter, simpler security proof than SLH-DSA and produces smaller signatures (2.5-5 KB vs 17-50 KB for SLH-DSA). If you can manage the state tracking requirement, LMS gives you hash-only security with less overhead.

How These Standards Relate to Each Other

The five standards form a complete toolkit, covering different needs with different tradeoffs:

Need	Primary Standard	Backup / Alternative
Key exchange / encryption	FIPS 203 (ML-KEM, lattice)	HQC (code-based, selected March 2025)
General-purpose signatures	FIPS 204 (ML-DSA, lattice)	FIPS 205 (SLH-DSA, hash-based)
Compact signatures	FIPS 206 (draft) draft (FN-DSA, NTRU lattice)	ML-DSA (if size is less critical)
Firmware / code signing	SP 800-208 (LMS/XMSS, hash-based)	ML-DSA (if statefulness is unacceptable)

The design is deliberate: NIST built the portfolio across three mathematical families (lattice, hash-based, code-based) so that no single mathematical breakthrough can compromise everything. Each pair of primary/backup standards relies on independent math, providing genuine defense-in-depth at the standards level.

NIST Security Levels Explained

NIST defines five security levels for post-quantum algorithms, numbered 1 through 5. Each level corresponds to the difficulty of breaking the algorithm, measured against a well-known benchmark:

Level 1: At least as hard to break as AES-128. This is the minimum for general commercial use.
Level 2: At least as hard to break as SHA-256 collision resistance.
Level 3: At least as hard to break as AES-192.
Level 4: At least as hard to break as SHA-384 collision resistance.
Level 5: At least as hard to break as AES-256. This is what governments require for top-secret information.

Each algorithm in the portfolio is available at multiple levels, allowing organizations to choose the security margin appropriate for their needs. Level 1 is adequate for most commercial applications. Level 5 provides the maximum margin for the most sensitive use cases. Higher levels mean larger keys and signatures, so there is always a tradeoff between security margin and efficiency.

The Eight-Year Process: Why It Took So Long

NIST launched the Post-Quantum Cryptography Standardization Process in December 2016 with a public call for proposals. They received 82 complete submissions from research teams around the world. What followed was a multi-round public evaluation that took eight years:

Round 1 (2017-2019): 69 submissions accepted for evaluation. The global cryptographic community analyzed each submission for security weaknesses, implementation flaws, and performance issues. 26 advanced to Round 2.
Round 2 (2019-2020): Deeper analysis of the 26 remaining candidates. 15 advanced (7 finalists + 8 alternates) to Round 3.
Round 3 (2020-2022): Intensive scrutiny of the finalists. In July 2022, NIST selected four algorithms for standardization: CRYSTALS-Kyber (now ML-KEM), CRYSTALS-Dilithium (now ML-DSA), SPHINCS+ (now SLH-DSA), and Falcon (now FN-DSA).
Round 4 (2022-2025): A separate track evaluated additional KEM candidates for algorithm diversity. HQC was selected in March 2025.
Standardization (2024): FIPS 203, 204, and 205 published in August 2024. FIPS 206 (draft) in draft.

This eight-year timeline is not bureaucratic delay; it is how cryptographic standards should be developed. Rushing a cryptographic standard into production without sufficient public analysis is how you end up with Dual EC DRBG (an NSA-compromised random number generator that was tragically standardized too quickly). NIST's process gives the global research community time to find flaws before the algorithms are deployed in systems that protect billions of people.

What About AES and SHA? Are They Quantum-Safe?

AES is quantum-safe. Grover's quantum search algorithm can theoretically speed up brute-force attacks against AES, but only by a square-root factor. AES-256 drops from 256-bit security to roughly 128-bit security against a quantum attacker, which is still extremely strong. AES-128 would drop to about 64-bit security, which is marginal, so organizations should prefer AES-256 going forward.

SHA-256 and SHA-3 are quantum-safe. Hash functions are affected by Grover's algorithm in a similar way: collision resistance drops by a cube-root factor, and pre-image resistance drops by a square-root factor. SHA-256 retains about 128 bits of collision resistance against quantum computers, which is adequate. SHA-3 is in the same position.

The quantum threat is specifically to public-key cryptography: the algorithms used for key exchange (RSA, ECDH) and digital signatures (RSA, ECDSA, EdDSA). These algorithms rely on math problems (integer factoring, discrete logarithms) that Shor's algorithm solves efficiently. Symmetric algorithms (AES) and hash functions (SHA-2, SHA-3) are not based on these problems and are not vulnerable to Shor's algorithm.

This is why the new FIPS standards replace only the public-key components. ML-KEM replaces RSA/ECDH for key exchange. ML-DSA replaces RSA/ECDSA for signatures. AES stays as the symmetric encryption algorithm. The new standards protect the key exchange, and AES protects the data.

Compliance and Migration Timelines

The NSA's CNSA 2.0 guidance sets the following deadlines for U.S. national security systems:

2025: Begin deploying PQC for firmware and software signing (LMS/XMSS).
2030: Stop using RSA and ECDH for key establishment. Switch to ML-KEM or approved PQC alternatives.
2033: Stop using RSA and ECDSA for digital signatures. Switch to ML-DSA, SLH-DSA, or approved PQC alternatives.
2035: All national security systems must use post-quantum cryptography exclusively.

These deadlines apply to government and defense systems, but the private sector has an even more urgent reason to migrate: harvest-now, decrypt-later attacks. Adversaries are recording encrypted communications today, storing them, and waiting for quantum computers to become powerful enough to decrypt them. If your data needs to remain confidential for 10, 20, or 30 years, the migration deadline is not 2035. It is now.

Healthcare records, financial data, trade secrets, legal communications, and personal data all have long confidentiality requirements. A patient's medical record encrypted with RSA today could be decrypted by a quantum computer in 2035, exposing private health information. The time to migrate is before the data is captured, not after.

Sources

NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), August 2024
NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA), August 2024
NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA), August 2024
NIST FIPS 206 (draft) (Initial Public Draft): FN-DSA
NIST SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes, October 2020
NSA CNSA 2.0: Commercial National Security Algorithm Suite 2.0, September 2022
NIST Post-Quantum Cryptography Project Page

NIST-Compliant Encryption

QNSQY implements all three FIPS standards: ML-KEM, ML-DSA, and SLH-DSA.

Originally published at quantumsequrity.com.

Classical vs Quantum-Safe Encryption Compared

Quantum Sequrity — Mon, 04 May 2026 13:00:58 +0000

Classical vs Quantum-Safe Encryption Compared

Education

Classical vs Quantum-Safe Encryption: Full Comparison

11 min read

Why This Comparison Matters Now

With NIST finalizing the first post-quantum cryptography standards on August 13, 2024 (FIPS 203, FIPS 204, and FIPS 205), organizations face a concrete decision: continue relying solely on classical cryptography, or begin transitioning to quantum-safe algorithms. Making that decision requires understanding the real differences between these two families of algorithms, not just in theoretical security, but in key sizes, performance, maturity, and practical deployment considerations.

This post provides a side-by-side comparison of classical encryption (RSA, ECC, Ed25519, X25519) and the NIST-standardized post-quantum replacements (ML-KEM, ML-DSA). If you are new to post-quantum cryptography, our introduction to what post-quantum cryptography is provides useful background.

Overview Comparison

The following table summarizes the key differences across the most important dimensions:

Aspect	Classical (RSA / ECC)	Post-Quantum (ML-KEM / ML-DSA)
Security basis	Integer factorization (RSA), elliptic curve discrete logarithm (ECC)	Module Learning With Errors (lattice problems)
Quantum resistance	No -- broken by Shor's algorithm	Yes -- no known efficient quantum attack
Maturity	Decades of deployment and analysis (RSA: 1977, ECC: 1990s)	Newly standardized (FIPS 203/204: August 2024), underlying math studied since ~2005
Standards	FIPS 186-5 (DSA/ECDSA), PKCS#1 (RSA), RFC 7748 (X25519), RFC 8032 (Ed25519)	FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)
Key sizes	Small (32-512 bytes)	Larger (800-2,592 bytes)
Ciphertext / signature sizes	Small (64-512 bytes)	Larger (768-4,627 bytes)
Performance	ECC very fast; RSA signing fast, verification fast	ML-KEM encapsulation/decapsulation very fast; ML-DSA signing/verification fast
Widely deployed	Yes -- virtually all internet infrastructure	Early adoption phase; growing library and protocol support

Security Basis: What Makes Them Hard to Break

Classical: Factoring and Discrete Logarithms

RSA's security relies on the difficulty of factoring the product of two large prime numbers. Given a 2048-bit modulus n, finding its prime factors p and q is computationally infeasible for classical computers. The best classical factoring algorithms (General Number Field Sieve) run in sub-exponential time.

ECC-based schemes (ECDH, ECDSA, Ed25519, X25519) rely on the elliptic curve discrete logarithm problem (ECDLP). Given a point on an elliptic curve that is the result of multiplying a base point by an unknown scalar, finding that scalar is computationally hard. ECC achieves equivalent security to RSA with much smaller keys: 256-bit ECC is roughly equivalent to 3072-bit RSA.

Both problems are broken in polynomial time by Shor's algorithm on a quantum computer. For a deeper explanation of how this works, see our post on why quantum computers threaten classical encryption.

Post-Quantum: Lattice Problems

ML-KEM and ML-DSA are based on the Module Learning With Errors (MLWE) problem, a variant of the Learning With Errors (LWE) problem applied to polynomial modules over lattices. The underlying hardness assumption is that finding short vectors in high-dimensional lattices is computationally intractable, even for quantum computers. Lattice problems have been studied by mathematicians since the 19th century, and no quantum algorithm is known to solve them significantly faster than the best classical algorithms.

SLH-DSA (FIPS 205) takes a different approach: its security is based solely on the properties of hash functions (specifically, the security of the hash function family used). This makes SLH-DSA extremely conservative, as it relies on one of the most well-understood building blocks in all of cryptography.

Key Size Comparison

One of the most visible differences between classical and post-quantum algorithms is key and ciphertext/signature sizes. Post-quantum algorithms generally require larger keys. Here are the exact sizes from the NIST standards:

Key Encapsulation (Key Exchange)

Algorithm	Public Key	Ciphertext	Shared Secret	Security Level
X25519	32 bytes	32 bytes	32 bytes	~128-bit classical
RSA-2048	256 bytes	256 bytes	Varies	~112-bit classical
RSA-4096	512 bytes	512 bytes	Varies	~140-bit classical
ML-KEM-512	800 bytes	768 bytes	32 bytes	128-bit quantum (NIST Level 1)
ML-KEM-768	1,184 bytes	1,088 bytes	32 bytes	192-bit quantum (NIST Level 3)
ML-KEM-1024	1,568 bytes	1,568 bytes	32 bytes	256-bit quantum (NIST Level 5)

Digital Signatures

Algorithm	Public Key	Signature	Security Level
Ed25519	32 bytes	64 bytes	~128-bit classical
RSA-2048	256 bytes	256 bytes	~112-bit classical
ML-DSA-44	1,312 bytes	2,420 bytes	128-bit quantum (NIST Level 2)
ML-DSA-65	1,952 bytes	3,309 bytes	192-bit quantum (NIST Level 3)
ML-DSA-87	2,592 bytes	4,627 bytes	256-bit quantum (NIST Level 5)

Key Size Context
While ML-KEM and ML-DSA keys are larger than ECC keys, they are comparable to or smaller than RSA keys at equivalent security levels. ML-KEM-768 (1,184-byte public key) is still smaller than many RSA-4096 key structures used in practice. The size increase is a manageable trade-off for quantum resistance.

Performance

Performance is often cited as a concern when discussing post-quantum algorithms, but the reality is more nuanced than many expect:

Key Encapsulation Performance

ML-KEM is fast. In benchmarks, ML-KEM-768 key generation, encapsulation, and decapsulation each complete in microseconds on modern hardware. This is significantly faster than RSA key generation (which involves finding large primes) and comparable to or faster than X25519 for the encapsulation/decapsulation operations. The lattice-based arithmetic in ML-KEM involves matrix-vector multiplications over small polynomial rings, which maps efficiently to modern CPU instructions.

Digital Signature Performance

ML-DSA signing and verification are also fast, completing in microseconds on modern CPUs. Signing speed is comparable to Ed25519, and verification is fast as well. RSA signing is fast but RSA verification, while also fast for small public exponents, involves working with much larger numbers.

The performance difference you are most likely to notice in practice is not in computation but in bandwidth and storage: larger keys and signatures mean more data transmitted and stored. For network protocols like TLS, the larger handshake sizes add some latency, particularly on constrained or high-latency connections. For data encryption (the primary use case for QNSQY), the overhead is negligible relative to the file data itself.

Maturity and Confidence

Classical: Decades of Battle-Testing

RSA has been in production use since the 1980s. Diffie-Hellman was published in 1976. ECC adoption grew through the 2000s and 2010s. These algorithms have been scrutinized by thousands of researchers over decades. Vulnerabilities that have been found (such as padding oracle attacks on RSA PKCS#1 v1.5, or weak curve parameters) have been addressed through improved implementations and updated standards. The mathematical hardness assumptions have held up against classical attacks.

This depth of analysis provides high confidence in classical algorithms against classical threats. The problem, of course, is that this confidence does not extend to quantum threats.

Post-Quantum: New Standards, Established Math

ML-KEM and ML-DSA are newly standardized (August 2024), but the underlying mathematical problems are not new. The Learning With Errors problem was introduced by Oded Regev in 2005 and has been extensively studied. The CRYSTALS-Kyber submission (which became ML-KEM) was introduced in NIST's 2016 call for proposals and underwent eight years of public review, analysis, and multiple rounds of evaluation before standardization.

No practical attack has been found against ML-KEM or ML-DSA at their specified parameter sets. However, the shorter track record compared to RSA or ECC means there is inherently less accumulated confidence. This is precisely why the hybrid approach is recommended during the transition period.

Why Hybrid Is the Best Approach

Given the trade-offs between classical maturity and post-quantum resistance, combining both in a hybrid scheme provides the strongest overall security guarantee:

If classical algorithms are broken by quantum computers (expected), the post-quantum component (ML-KEM or ML-DSA) provides protection.
If a post-quantum algorithm is found to have a weakness (unlikely but possible with newer algorithms), the classical component (X25519 or Ed25519) provides protection against non-quantum attackers.
An attacker must defeat both algorithms simultaneously to compromise the data. The overall security level is at least as strong as the stronger of the two components.

QNSQY implements hybrid encryption for all operations: ML-KEM + X25519 for key encapsulation, and ML-DSA + Ed25519 for digital signatures. For how hybrid encryption works, see why hybrid encryption matters. For the ML-KEM side of the hybrid, see ML-KEM explained.

Migration Considerations

Moving from classical to post-quantum cryptography involves practical considerations beyond algorithm selection:

Protocol and Format Changes

Larger keys and signatures affect protocol message sizes. TLS handshakes become larger. Certificate chains grow. File headers expand. Systems with hard-coded buffer sizes or strict payload limits may need updates. Testing interoperability across updated and non-updated systems is essential.

Key Management

Post-quantum keys are larger and may require updates to key storage systems, hardware security modules (HSMs), and key distribution protocols. Organizations using smart cards or constrained devices should evaluate whether those devices can handle the larger key sizes.

Compliance and Standards Alignment

FIPS 203 and FIPS 204 are now official NIST standards. Organizations subject to FIPS compliance (government agencies, contractors, healthcare, financial services) should incorporate these into their cryptographic policies. NIST has also published transition guidance recommending a phased approach.

Incremental Adoption

Full infrastructure migration takes years. A practical approach is to start with hybrid mode: deploy post-quantum algorithms alongside classical ones. This provides immediate quantum resistance for new data while maintaining backward compatibility and avoiding a disruptive cutover.

For data encryption, the migration path is more straightforward. Tools like QNSQY allow you to encrypt individual files with hybrid PQC today, without changing your entire infrastructure. Files encrypted now with ML-KEM + X25519 will remain secure against both classical and quantum attacks for the foreseeable future.

Real-World Deployment Status

Post-quantum algorithms are no longer theoretical. Real-world deployment is already underway across major platforms and protocols.

TLS and Web Browsers

Google Chrome and Cloudflare began experimental deployments of hybrid key exchange using ML-KEM (then called Kyber) in TLS 1.3 connections during 2023 and 2024. These experiments demonstrated that hybrid handshakes with ML-KEM-768 + X25519 complete successfully at scale, with the primary impact being a modest increase in handshake size (roughly 1,100 additional bytes for the KEM ciphertext). Connection latency impact was minimal on broadband connections but measurable on high-latency mobile networks.

Signal Protocol

The Signal messaging application updated its X3DH key agreement protocol to include a post-quantum component (PQXDH) using ML-KEM-768 in September 2023. This was one of the first major consumer-facing deployments of post-quantum cryptography, protecting billions of messages against future quantum decryption.

Government Adoption

The U.S. government, through NSA CNSA 2.0, has mandated ML-KEM-1024 and ML-DSA-87 for all National Security Systems, with phased deadlines beginning in 2025. Federal agencies are actively conducting cryptographic inventories under OMB Memorandum M-23-02 and beginning migration of their highest-priority systems.

Library Support

Major cryptographic libraries have added PQC support. The Open Quantum Safe (liboqs) project provides C implementations of all NIST-standardized algorithms. OpenSSL 3.x includes PQC provider support. BoringSSL (used in Chrome and Android) has integrated ML-KEM. AWS, Azure, and Google Cloud have begun offering PQC-enabled TLS endpoints for their services. For organizations seeking to protect files at rest without infrastructure changes, standalone tools like QNSQY provide hybrid PQC encryption that can be deployed immediately alongside existing systems.

Summary: Which Should You Use?

Scenario	Recommendation
New systems or applications	Use hybrid: ML-KEM + X25519 (key exchange), ML-DSA + Ed25519 (signatures)
Data that must remain confidential 10+ years	Encrypt now with post-quantum or hybrid algorithms
Legacy systems that cannot be updated	Prioritize migration planning; use PQC at the boundaries where possible
Short-lived data (session keys, ephemeral tokens)	Classical ECC is acceptable today, but hybrid adds zero-cost future-proofing
Regulatory/compliance-driven environments	Follow NIST FIPS 203/204 guidance; begin hybrid deployment

The bottom line: classical cryptography served us well for decades but does not survive the quantum transition. Post-quantum algorithms are standardized, performant, and ready for deployment. Hybrid mode combines the strengths of both. There is no technical reason to delay adoption.

Sources

Start Using Quantum-Safe Encryption Today

QNSQY provides hybrid ML-KEM + X25519 and ML-DSA + Ed25519 encryption across all tiers.

Originally published at quantumsequrity.com.

NIST Post-Quantum Cryptography Timeline: 2016-2026

Quantum Sequrity — Sun, 03 May 2026 13:01:03 +0000

NIST Post-Quantum Cryptography Timeline: 2016-2026

News

NIST Post-Quantum Cryptography Timeline: 2016-2026

11 min read

A Decade of Building Quantum-Resistant Standards

The transition from classical to post-quantum cryptography did not happen overnight. It is the result of a methodical, decade-long effort led by the U.S. National Institute of Standards and Technology (NIST), involving hundreds of researchers from dozens of countries. This timeline documents every major milestone in that process, from the initial call for proposals in 2016 through the publication of final standards and ongoing work in 2025 and beyond.

Understanding this history matters. Organizations planning their post-quantum migration need to know which algorithms have been standardized, which are still in progress, and what comes next. Every date and fact in this article is drawn directly from official NIST publications, press releases, and Federal Register notices.

2016: The Starting Gun

In April 2016, NIST published NISTIR 8105, "Report on Post-Quantum Cryptography", a technical report assessing the threat that quantum computers pose to existing public-key cryptographic systems. The report concluded that new algorithms resistant to quantum attack were needed and that a public, competitive process was the best way to identify them.

On December 20, 2016, NIST formally issued its call for proposals for post-quantum cryptographic algorithms. The call requested submissions in two categories: key encapsulation mechanisms (KEMs) for encryption, and digital signature schemes for authentication. NIST set explicit requirements for security levels, performance, and documentation. Submissions were due by November 30, 2017.

The response was enormous. By the deadline, NIST received 82 submissions from research teams around the world. The submissions spanned five major families of mathematical approaches: lattice-based, code-based, multivariate polynomial, hash-based, and other (including isogeny-based and zero-knowledge approaches).

2017: Round 1 Begins

After reviewing all 82 submissions for completeness and correctness, NIST announced in November 2017 that 69 candidates met the requirements for Round 1 evaluation. The remaining 13 were excluded due to incomplete specifications, known attacks discovered during the submission period, or failure to meet formatting requirements.

The 69 Round 1 candidates broke down by category:

Lattice-based: The largest group, including CRYSTALS-Kyber, CRYSTALS-Dilithium, NTRU, SABER, FrodoKEM, and others
Code-based: Including Classic McEliece, BIKE, HQC, and others based on error-correcting codes
Multivariate: Including Rainbow, GeMSS, and others based on systems of polynomial equations
Hash-based: Including SPHINCS+ and other schemes with security rooted in hash function properties
Other: Including SIKE (isogeny-based) and other novel approaches

NIST organized a public workshop (the First PQC Standardization Conference, April 2018) where submitters presented their designs and the broader cryptographic community provided analysis. This open process was deliberate: NIST wanted the widest possible scrutiny of every candidate.

2019: Round 2 Narrows the Field

In January 2019, after more than a year of public analysis, NIST announced the 26 second-round candidates. This was a significant reduction from 69, driven by cryptanalytic attacks, performance concerns, and comparative analysis.

The 26 candidates included 17 KEM/encryption schemes and 9 signature schemes. Notable survivors at this stage included CRYSTALS-Kyber, CRYSTALS-Dilithium, FALCON, SPHINCS+, NTRU, SABER, Classic McEliece, BIKE, HQC, and SIKE.

Several high-profile eliminations occurred during this round. Multiple multivariate signature schemes were broken or shown to have unacceptable key sizes. Some lattice-based schemes were eliminated because they offered no clear advantage over the leading designs. The second round continued with intensive analysis, including side-channel resistance evaluation and implementation testing on constrained devices.

2020: The Third-Round Finalists

In July 2020, NIST made its most consequential selection to date, announcing 7 finalists and 8 alternate candidates for the third round.

The finalists (algorithms most likely to be standardized) were:

CRYSTALS-Kyber (lattice-based KEM) -- later standardized as ML-KEM
NTRU (lattice-based KEM)
SABER (lattice-based KEM)
Classic McEliece (code-based KEM)
CRYSTALS-Dilithium (lattice-based signature) -- later standardized as ML-DSA
FALCON (lattice-based signature) -- later to become FN-DSA
SPHINCS+ (hash-based signature) -- later standardized as SLH-DSA

The alternate candidates (kept under consideration for potential future standardization) included BIKE, HQC, SIKE, FrodoKEM, and others. NIST explicitly stated that alternates could still be selected if finalists encountered problems or if algorithmic diversity was needed.

2022: The First Selections and a Dramatic Collapse

July 2022 was the watershed month for post-quantum cryptography. NIST announced the first four algorithms selected for standardization:

CRYSTALS-Kyber (renamed ML-KEM) for key encapsulation
CRYSTALS-Dilithium (renamed ML-DSA) for digital signatures
FALCON (later designated FN-DSA) for digital signatures
SPHINCS+ (renamed SLH-DSA) for digital signatures

NIST selected one KEM and three signature algorithms, reflecting the greater diversity needed in signature schemes across different use cases. CRYSTALS-Kyber was chosen as the primary KEM due to its strong security arguments, small key sizes, and fast performance. For signatures, Dilithium was recommended as the general-purpose choice, FALCON for applications requiring the smallest signatures, and SPHINCS+ as a conservative, hash-based alternative not relying on lattice assumptions.

NIST also announced a Round 4 for additional KEM candidates, seeking algorithmic diversity beyond lattice-based schemes. The Round 4 candidates were BIKE, Classic McEliece, HQC, and SIKE.

The SIKE Collapse

In a dramatic development, SIKE was completely broken in July 2022 by researchers Wouter Castryck and Thomas Decru. Their attack, published just weeks after NIST's Round 4 announcement, used classical mathematics (specifically, the theory of isogenies between abelian surfaces) to recover SIKE private keys in minutes on a single laptop. This was not a quantum attack. It was a devastating classical cryptanalytic result that invalidated the entire supersingular isogeny approach to key encapsulation.

The SIKE collapse underscored why NIST's multi-year, public evaluation process is essential. Even algorithms that survived years of analysis can fall to unexpected mathematical breakthroughs. It also reinforced the value of algorithmic diversity: relying on a single mathematical assumption is risky.

CNSA 2.0

In September 2022, the National Security Agency (NSA) published the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), incorporating the newly selected post-quantum algorithms. CNSA 2.0 set timelines for U.S. national security systems to transition to post-quantum cryptography, with requirements beginning as early as 2025 for some applications and full transition mandated by 2033-2035.

2023: Draft Standards for Public Comment

In August 2023, NIST published draft versions of FIPS 203, FIPS 204, and FIPS 205 for a 90-day public comment period. These drafts specified the exact algorithms, parameter sets, and implementation requirements for ML-KEM, ML-DSA, and SLH-DSA respectively.

The public comment period generated extensive feedback from implementers, hardware vendors, and the academic community. Key areas of discussion included side-channel resistance requirements, parameter set naming conventions (the transition from "Kyber" to "ML-KEM" naming), and guidance on hybrid deployment alongside classical algorithms.

August 13, 2024: The Standards Are Published

On August 13, 2024, NIST officially published the first-ever post-quantum cryptographic standards:

FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) -- derived from CRYSTALS-Kyber, specifying ML-KEM-512, ML-KEM-768, and ML-KEM-1024 parameter sets at NIST security levels 1, 3, and 5 respectively
FIPS 204: Module-Lattice-Based Digital Signature Algorithm (ML-DSA) -- derived from CRYSTALS-Dilithium, specifying ML-DSA-44, ML-DSA-65, and ML-DSA-87 parameter sets
FIPS 205: Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) -- derived from SPHINCS+, specifying twelve parameter sets across three security levels and two performance profiles (fast vs. small)

This was a landmark moment. For the first time, organizations worldwide had official, peer-reviewed, government-backed standards for cryptography designed to resist quantum computers. The publication triggered migration planning across industries from finance and healthcare to defense and critical infrastructure.

Alongside the final standards, NIST published a draft of FIPS 206 (draft) for the FN-DSA (FALCON-based) signature scheme. FN-DSA's standardization is proceeding on a separate timeline due to its more complex implementation requirements, particularly around secure sampling of discrete Gaussians.

2025: HQC Selected as the Fifth Algorithm

On March 11, 2025, NIST announced the selection of HQC (Hamming Quasi-Cyclic) as the fifth post-quantum algorithm for standardization. HQC is a code-based key encapsulation mechanism, meaning its security rests on the difficulty of decoding random linear codes rather than on lattice problems.

This selection was driven by NIST's desire for algorithmic diversity. With ML-KEM already standardized as the primary lattice-based KEM, having a code-based alternative provides a critical backup. If a fundamental breakthrough were to weaken lattice-based cryptography, organizations would have an independently secure KEM to fall back on.

HQC offers larger ciphertexts and keys than ML-KEM but is based on mathematical problems (specifically, the syndrome decoding problem) that have been studied for over 60 years with no known efficient quantum or classical algorithm. A draft standard for HQC is expected to follow.

What Comes Next

Several standardization efforts remain in progress or are anticipated:

FIPS 206 (draft) (FN-DSA): The FALCON-derived signature scheme is still in draft form. FN-DSA offers the smallest combined signature-plus-public-key size among the selected signature algorithms, making it attractive for constrained environments. Finalization is expected but no firm date has been announced.
HQC standard: Following its March 2025 selection, a draft FIPS for HQC is anticipated. The standardization process will include a public comment period.
Additional signature schemes: NIST has an ongoing call for additional digital signature algorithms, seeking schemes with short signatures, fast verification, or novel security assumptions beyond lattices and hashes.
Migration guidance: NIST continues to develop transition guidance, including SP 800-227 (Recommendations for Transition to Post-Quantum Cryptography) and updates to existing standards like SP 800-56A/B for key establishment.

Lessons from the NIST Process

The NIST PQC standardization process provides several enduring lessons for cryptographic engineering. First, open competition works. By soliciting proposals worldwide and subjecting them to years of public analysis, NIST identified algorithms that survived scrutiny from hundreds of independent researchers. Second, algorithmic diversity is essential. The SIKE collapse demonstrated that even well-studied mathematical assumptions can fall unexpectedly. NIST's selection of algorithms from different mathematical families (lattices, hashes, codes) ensures that a single breakthrough cannot compromise everything. Third, standardization takes time. Eight years from the initial call to the final standards reflects the depth of analysis required for algorithms that will protect critical infrastructure for decades.

Timeline Summary

Date	Milestone
Apr 2016	NISTIR 8105 published, assessing quantum threat to public-key crypto
Dec 2016	NIST issues call for post-quantum algorithm proposals
Nov 2017	69 complete Round 1 candidates announced (from 82 submissions)
Jan 2019	26 Round 2 candidates selected
Jul 2020	7 finalists and 8 alternates for Round 3
Jul 2022	4 algorithms selected: Kyber (ML-KEM), Dilithium (ML-DSA), FALCON (FN-DSA), SPHINCS+ (SLH-DSA)
Jul 2022	SIKE broken by Castryck-Decru classical attack
Sep 2022	NSA publishes CNSA 2.0 with PQC transition timelines
Aug 2023	Draft FIPS 203, 204, 205 published for public comment
Aug 13, 2024	FIPS 203 (ML-KEM), 204 (ML-DSA), 205 (SLH-DSA) officially published
Mar 11, 2025	HQC selected as 5th PQC algorithm for standardization

Why This Matters for Your Organization

The NIST PQC timeline is not just academic history. It carries direct implications for anyone responsible for data security:

Standards are finalized. FIPS 203, 204, and 205 are published and available for immediate adoption. There is no longer a reason to wait for "the standards to be ready."
Migration timelines are tightening. CNSA 2.0 mandates that U.S. national security systems begin transitioning now, with full compliance required by the early 2030s. Private-sector organizations handling sensitive data should follow a similar schedule.
Harvest-now-decrypt-later is real. Adversaries are collecting encrypted data today with the expectation of decrypting it when quantum computers become available. Data encrypted with only classical algorithms today may be compromised in the future.
Hybrid deployment is the recommended approach. Both NIST and NSA recommend combining post-quantum and classical algorithms during the transition period. If either the post-quantum or classical algorithm is compromised, the other provides continued protection.

QNSQY implements this hybrid approach by default, combining ML-KEM with X25519 for key encapsulation and ML-DSA with Ed25519 for signatures. Every encryption operation uses both classical and post-quantum algorithms, so your data is protected regardless of which mathematical assumptions hold up over time.

Sources

Start Your Post-Quantum Migration

QNSQY implements FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA) in hybrid mode with classical algorithms. Available on all tiers, including free.

Originally published at quantumsequrity.com.

The State of Post-Quantum Cryptography in 2026 Blog

Quantum Sequrity — Sat, 02 May 2026 13:00:06 +0000

Research

The State of Post-Quantum Cryptography in 2026

14 min read

The Standards Are Final. Now What?

For eight years, from 2016 to 2024, the global cryptography community participated in NIST's Post-Quantum Cryptography Standardization Project. Hundreds of researchers from dozens of countries submitted 82 candidate algorithms. These candidates went through multiple rounds of public analysis, attack attempts, and performance benchmarking. In August 2024, NIST published three final standards:

FIPS 203 (ML-KEM): Module Lattice-Based Key Encapsulation Mechanism. This is the algorithm that protects encryption keys during exchange. When two parties need to agree on a shared secret to encrypt data, ML-KEM provides that exchange with quantum resistance.
FIPS 204 (ML-DSA): Module Lattice-Based Digital Signature Algorithm. This is for digital signatures, the cryptographic equivalent of a handwritten signature that proves a document has not been altered and verifies who created it.
FIPS 205 (SLH-DSA): Stateless Hash-Based Digital Signature Algorithm. A backup signature algorithm based on hash functions rather than lattice math, providing algorithm diversity in case a weakness is ever found in lattice-based approaches.

Those standards are no longer drafts or proposals. They are final, published NIST Federal Information Processing Standards, carrying the same authority as AES (FIPS 197) and SHA-2 (FIPS 180-4). Products can now ship with these algorithms and claim NIST compliance. And as of April 2026, many products already do.

FIPS 206 (draft): The Fourth Standard in Draft

NIST is also working on a fourth standard, FIPS 206 (draft), for FN-DSA (originally called FALCON). FN-DSA is another lattice-based signature scheme, but it uses a different mathematical structure (NTRU lattices) from ML-DSA (module lattices). The draft standard was published in late 2024. FN-DSA produces smaller signatures than ML-DSA, which makes it attractive for applications where bandwidth is limited, such as certificates in constrained network protocols. The final standard is expected in 2026 or early 2027.

HQC: NIST Selects a Fourth KEM

In March 2025, NIST announced the selection of HQC (Hamming Quasi-Cyclic) as an additional KEM algorithm for standardization. HQC is based on error-correcting codes, a completely different mathematical foundation from ML-KEM's lattice problems. The reason for selecting a second KEM is algorithm diversity: if a breakthrough attack is discovered against lattice-based schemes (which ML-KEM relies on), organizations need an alternative that would not be affected by the same attack. HQC provides that backup.

HQC is available today in QNSQY v7.x on the Business tier in three security levels (HQC-128, HQC-192, HQC-256). Standardization as a formal FIPS document is expected to be complete by 2027.

Browser Adoption: PQC Is Already Protecting Your Web Traffic

The most visible deployment of post-quantum cryptography is in web browsers. When you visit a website over HTTPS, your browser and the web server negotiate a shared encryption key using a key exchange algorithm. Until recently, that algorithm was always ECDH (based on elliptic curve math vulnerable to quantum attacks). Now, major browsers are using ML-KEM in hybrid mode alongside ECDH.

Chrome 131+ (released November 2024): Google enabled ML-KEM-768 in hybrid mode by default for all TLS 1.3 connections. Chrome previously used Kyber-768 (the pre-standard version) starting in Chrome 124, then switched to the final ML-KEM standard. As of early 2026, ML-KEM is active in Chrome on all platforms (Windows, macOS, Linux, Android, ChromeOS).
Firefox 135+: Mozilla added ML-KEM support in hybrid mode. Firefox's implementation follows the same hybrid TLS approach as Chrome, combining ML-KEM with X25519 so that the connection is protected by both algorithms.
Safari: Apple has been shipping post-quantum key exchange for iMessage since iOS 17.4 (PQ3 protocol, February 2024). Safari browser support for ML-KEM in TLS is expected in a 2026 update.

Cloudflare, one of the largest CDN and web infrastructure providers, reported in their 2025 year-in-review that a significant and growing share of TLS connections to their network used post-quantum key exchange. The majority of these came from Chrome and Firefox users on desktop and Android. This means that for a large portion of everyday web browsing, the key exchange is already quantum-resistant.

Operating System Support

Post-quantum algorithms are being built into operating system cryptography libraries, making them available to every application on the system:

Windows 11 24H2: Microsoft's CNG (Cryptography Next Generation) API added ML-KEM support. Applications that use CNG for TLS or key exchange can use ML-KEM without shipping their own implementation.
macOS Sequoia: Apple's Security framework includes post-quantum primitives. Apple's CryptoKit already supports PQ3 for iMessage, and the underlying algorithms are available to third-party developers.
Linux: The Linux kernel's crypto subsystem added ML-KEM support. OpenSSL 3.x has experimental PQC support via the OQS (Open Quantum Safe) provider. BoringSSL (used by Chrome and Android) shipped ML-KEM support in 2024.

Government Mandates: CNSA 2.0 Timelines

The strongest driver of PQC adoption is government mandates. The NSA published the CNSA 2.0 (Commercial National Security Algorithm Suite) guidance in September 2022, setting firm deadlines for when National Security Systems (NSS) must transition to post-quantum algorithms:

Use Case	CNSA 2.0 Deadline	Required Algorithm
Software/firmware signing	2025	ML-DSA or LMS/XMSS
Web servers/browsers (TLS)	2025	ML-KEM
Networking equipment (VPN, MACsec)	2026	ML-KEM + ML-DSA
Operating systems	2027	ML-KEM + ML-DSA
Custom/legacy applications	2033	All PQC algorithms

These deadlines are not optional for defense contractors, intelligence agencies, or any organization handling classified information. They are also influencing the broader private sector, because many companies follow NIST and NSA guidance even when not legally required to.

The White House also issued National Security Memorandum NSM-10 (May 2022), directing federal agencies to inventory their cryptographic systems and develop migration plans. This has created a wave of "crypto discovery" projects across the U.S. federal government, where agencies are cataloging every system that uses cryptography and planning upgrades.

Enterprise Migration: Where Companies Stand

Moving an entire organization from classical to post-quantum cryptography is not a weekend project. It involves four phases, and most enterprises are still in the early stages:

Discovery. Inventorying every system, application, protocol, and library that uses cryptography. This includes TLS certificates, VPN configurations, database encryption, data encryption, code signing, SSH keys, API authentication, and more. Most large organizations have thousands of cryptographic touchpoints, many of which are undocumented.
Planning. Prioritizing which systems to migrate first based on the sensitivity of the data they protect and the difficulty of migration. Long-lived secrets (healthcare data, legal records, government classified) take priority. Short-lived session keys (web TLS) are lower priority because they are already being addressed by browser vendors.
Hybrid deployment. Running post-quantum algorithms alongside classical algorithms. This is the recommended approach because it provides quantum resistance while maintaining backward compatibility. If a PQC algorithm turns out to have an unexpected weakness, the classical algorithm still provides protection. QNSQY uses this approach by default (ML-KEM + X25519).
Full migration. Removing classical cryptography dependencies entirely. Very few organizations have reached this stage. Most experts recommend staying in the hybrid phase for at least several years until PQC implementations have been thoroughly battle-tested in production.

According to industry surveys and reports from consulting firms, most large enterprises are in Phase 1 (Discovery) or Phase 2 (Planning) as of early 2026. Some early adopters in finance and government are in Phase 3 (Hybrid deployment). No major organization has publicly claimed to be in Phase 4 (Full migration).

Remaining Challenges

Larger Key and Signature Sizes

Post-quantum algorithms produce larger keys and signatures than classical algorithms. An ML-KEM-768 public key is 1,184 bytes, compared to 32 bytes for X25519. An ML-DSA-65 signature is 3,309 bytes, compared to 64 bytes for Ed25519. For data encryption (like QNSQY), this overhead is negligible because the keys and signatures are tiny compared to the file being encrypted. For protocols like TLS, where every connection involves a key exchange and certificate chain, the extra bytes add up. A TLS handshake with ML-KEM and ML-DSA certificates can add several kilobytes to the handshake, increasing connection latency on slow networks.

Migration Complexity

Cryptographic code is embedded deeply in applications, libraries, and hardware. Many systems use RSA or ECDH in places the developers never explicitly chose, because the cryptography is handled by underlying libraries. Changing the algorithm requires updating the library, testing for compatibility, updating configuration, and often modifying the application itself. For organizations with hundreds or thousands of applications, this is a multi-year project.

Developer Tooling

While OpenSSL, BoringSSL, and platform APIs are adding PQC support, the developer experience is still rough. Documentation is sparse. Testing tools are limited. Most PQC libraries are young and have not been through the years of production hardening that OpenSSL's RSA implementation has. This is improving rapidly, but as of early 2026, implementing PQC correctly still requires more expertise than implementing classical cryptography.

Performance Overhead

ML-KEM is actually faster than RSA for key exchange. An ML-KEM-768 encapsulation takes roughly 100 microseconds, compared to several milliseconds for RSA-2048. So for encryption, PQC is often a performance improvement, not a penalty. The overhead is primarily in signatures: ML-DSA signing and verification are slower than Ed25519, and the larger signatures consume more bandwidth. For most applications, this overhead is acceptable. For extremely latency-sensitive or bandwidth-constrained systems (real-time trading, IoT sensors on cellular networks), it requires careful engineering.

Where Quantum Computers Actually Stand

All of this migration effort is driven by the anticipation of future quantum computers. Where are they today?

As of early 2026, the most advanced quantum computers have roughly 1,000 to 1,500 physical qubits. IBM's Heron processor and Google's Willow chip are in this range. These are "noisy intermediate-scale quantum" (NISQ) devices. They can perform certain specialized calculations, but they cannot run Shor's algorithm at a scale that threatens any currently deployed encryption.

Breaking RSA-2048 with Shor's algorithm would require an estimated 4,000+ logical qubits, each of which requires thousands of physical qubits for error correction. The total physical qubit count needed is in the millions. Current error correction rates are improving, but the gap between where quantum hardware is now and where it needs to be for cryptographic relevance is still enormous.

Expert consensus, as reflected in surveys by the Global Risk Institute and statements from NIST, places the arrival of a cryptographically relevant quantum computer (CRQC) at 10 to 20 years from now. Some researchers are more optimistic (under 10 years), others more conservative (over 25 years). No one in the serious research community claims it is impossible. The question is "when," not "if."

The reason to migrate now, despite the computer being years away, is the "harvest now, decrypt later" threat. Data encrypted today with classical algorithms and intercepted by an adversary can be stored indefinitely and decrypted once a CRQC exists. If your data needs to stay secret for 20 years and a CRQC arrives in 15 years, you have a 5-year window where your data is exposed. The only way to close that window is to encrypt with PQC before the data is intercepted.

What Comes Next

FIPS 206 (draft) (FN-DSA) finalization: Expected 2026-2027. Adds a compact lattice-based signature scheme with smaller signatures than ML-DSA.
HQC standardization: The code-based KEM selected in March 2025, expected to be formalized as a FIPS standard by 2027.
Hybrid protocol standardization: IETF working groups are developing standards for hybrid key exchange and hybrid signatures in TLS, SSH, and other protocols. These standards will define exactly how PQC and classical algorithms should be combined.
Hardware acceleration: Intel has announced plans for CPU instructions that accelerate lattice operations, expected in future processor generations. ARM is updating its CryptoCell IP block for mobile and IoT devices.
Additional signature schemes: NIST's additional signature scheme evaluation (launched in 2023) is reviewing candidates for standardization. These address use cases where ML-DSA or SLH-DSA may not be optimal, such as very short signatures for constrained devices.

The IoT and Embedded Challenge

The most difficult frontier for post-quantum migration is the world of IoT (Internet of Things) and embedded devices. These are the smart locks, medical monitors, industrial sensors, automotive controllers, and satellite receivers that run on tiny processors with limited memory and bandwidth. Many of these devices were designed with 20-year lifespans and have firmware that is rarely updated.

ML-KEM-768 requires roughly 2,400 bytes for a public key and ciphertext combined. That is trivial for a laptop or server, but for an embedded device with 32 KB of RAM communicating over a cellular modem, those extra bytes matter. Work is underway in several areas to address this:

Lightweight ML-KEM implementations. Optimized implementations of ML-KEM for ARM Cortex-M processors (common in IoT devices) have been demonstrated by the PQClean project and the ARM PSA Crypto API.
Hardware accelerators. ARM is updating its CryptoCell IP block, which is embedded in billions of chips, to support lattice-based operations natively. This would make ML-KEM nearly as fast as ECDH on resource-constrained devices.
Protocol optimization. IETF working groups are developing protocols that minimize the number of PQC key exchanges required, caching and reusing post-quantum session keys where possible to reduce bandwidth overhead.

For devices that cannot be updated to support PQC, the recommended approach is network-level protection: ensure that the communication channels to and from these devices are PQC-protected, even if the device itself still uses classical cryptography internally. This is a stopgap measure, not a permanent solution, but it buys time until the device can be replaced.

What This Means for Individuals

Most of the discussion about PQC migration focuses on enterprises and governments. But individuals also have data worth protecting for decades: personal photos, family documents, financial records, medical information, private journals. If you use GPG, Age, or another tool that relies solely on classical algorithms, your encrypted archives are vulnerable to future quantum attacks.

The good news is that switching to post-quantum encryption for personal files is far simpler than an enterprise migration. There is no infrastructure to audit, no legacy systems to untangle, and no compliance framework to satisfy. You download a tool like QNSQY, encrypt your files, and you are done. The free tier provides ML-KEM-512 + X25519 hybrid encryption, which is more than sufficient for personal use.

The files most worth re-encrypting are the ones with the longest sensitivity periods: family photos you want to keep private forever, personal financial records, medical information, legal documents, and private correspondence. Start with those and work outward.

What Should You Do Right Now?

Start now. Do not wait for quantum computers to appear. The "harvest now, decrypt later" threat means data encrypted today with classical algorithms is already at risk. Every day you wait is another day of data that could be collected for future decryption.
Use hybrid mode. Combine PQC with classical algorithms. This is the recommended approach from NIST, NSA, and every major security organization. If either algorithm has an undiscovered weakness, the other still provides protection. QNSQY uses hybrid mode by default.
Prioritize long-lived secrets. Not all data is equally sensitive. Focus first on data that needs to remain confidential for more than 10 years: medical records, legal documents, trade secrets, personal archives, government classified material.
Inventory your cryptography. Know where RSA, ECDH, and ECDSA are used in your systems. You cannot migrate what you have not found. Many organizations are discovering cryptographic dependencies they did not know existed.
Test with larger key sizes. PQC keys are larger than classical keys. Test your systems to make sure they can handle the additional bytes in certificates, key exchanges, and signatures. Most modern systems handle this fine, but legacy systems may have buffer size limits.
Stay informed. The PQC landscape is evolving rapidly. FIPS 206 (draft) and the HQC standard are still in progress. IETF hybrid protocol standards are being developed. New hardware acceleration is coming. Follow the NIST PQC project page and your platform vendor's security announcements for updates.

Sources

Be Quantum-Ready

QNSQY implements the latest NIST post-quantum standards.

Originally published at quantumsequrity.com.

Harvest Now, Decrypt Later Threat

Quantum Sequrity — Fri, 01 May 2026 13:00:58 +0000

Harvest Now, Decrypt Later Threat

Research

Harvest Now, Decrypt Later: The Quantum Threat Timeline

13 min read

A Scenario That Is Already Playing Out

Imagine a foreign intelligence service tapping into the undersea fiber optic cables that carry international internet traffic. They record everything: encrypted emails between diplomats, encrypted file transfers between defense contractors, encrypted video calls between corporate executives. They cannot read any of it. The encryption is strong. So they store it all on arrays of hard drives in a government data center and wait.

Five years pass. Ten years. Fifteen years. Then their quantum computing program produces a machine powerful enough to run Shor's algorithm against RSA-2048. In a matter of hours, they begin decrypting the archived traffic. Diplomatic cables from a decade ago reveal negotiating positions that are still politically sensitive. Defense contractor communications expose weapons system vulnerabilities that have not been patched. Corporate communications reveal trade secrets that are still commercially valuable.

This is the "harvest now, decrypt later" (HNDL) attack. It is not a future threat. It is a present reality.

"Harvest Now, Decrypt Later" (HNDL)
Collect encrypted data today. Store it in data centers. Wait for quantum computers to mature. Decrypt everything retroactively. The cost of storage is negligible compared to the intelligence value of the decrypted data.

Who Is Doing This?

Any organization with both the technical capability to intercept internet traffic and the storage capacity to keep it is a potential HNDL actor. In practice, this means nation-state intelligence agencies.

The NSA's activities in this area were partially disclosed through the Snowden revelations in 2013, which documented programs for mass collection of encrypted internet traffic and phone metadata. The Utah Data Center in Bluffdale, which became operational in 2014, was built with storage capacity estimated in the exabyte to yottabyte range. The stated purpose: to store and process signals intelligence.

But the United States is not alone. China, Russia, the United Kingdom, France, Israel, and other nations operate signals intelligence programs with similar capabilities. China in particular has invested heavily in both quantum computing research (the University of Science and Technology of China has published significant results in quantum supremacy demonstrations) and submarine cable tapping capabilities. In 2023, researchers from the Chinese Academy of Sciences published a paper claiming progress toward breaking RSA with quantum annealing techniques, though the claims were met with skepticism by Western cryptographers.

Non-state actors are also relevant. Organized cybercrime groups may not have the resources for mass traffic interception, but they can target specific high-value individuals or organizations and store encrypted data from targeted attacks.

What Types of Data Are Being Targeted?

Storage costs have plummeted. A petabyte of hard drive storage costs under $20,000 at current prices. For a national intelligence agency with a multi-billion-dollar budget, storing years of intercepted traffic is a rounding error. The types of data most valuable in an HNDL context include:

Diplomatic communications: Negotiating positions, alliance discussions, intelligence assessments. These can remain sensitive for decades. Knowing what one country's diplomats said privately 15 years ago can provide enormous leverage in current negotiations.
Military and defense communications: Weapons system specifications, deployment plans, intelligence reports. Classified information can remain sensitive for 25 to 75 years depending on classification level.
Corporate intellectual property: Trade secrets, pharmaceutical research data, semiconductor designs, merger/acquisition plans. Industrial espionage has direct economic value, and some trade secrets remain valuable indefinitely (the formula for Coca-Cola has been a trade secret for over 130 years).
Healthcare data: Patient records, genetic information, mental health records. Under HIPAA, protected health information must remain confidential for the patient's lifetime. Genetic data is sensitive across generations.
Legal communications: Attorney-client privileged communications, litigation strategy, regulatory compliance discussions. Exposure of these could compromise ongoing legal proceedings or enable extortion.
Financial data: High-value transaction details, trading strategies, account information. While individual credit card numbers expire, patterns of financial behavior and institutional trading strategies have longer-term value.
Personal communications of public figures: Politicians, journalists, activists, religious leaders. Private conversations from years ago can be weaponized for political manipulation or blackmail.

The Quantum Threat Timeline

The critical question for HNDL is not "will quantum computers break encryption" (they will) but "when." Several organizations have published estimates:

Source	Estimate	Context
Global Risk Institute (2023 survey)	50% probability by 2033	Survey of 37 quantum computing experts
NIST (2016)	15-20 years from 2016, so 2031-2036	Rationale for beginning PQC standardization
NSA CNSA 2.0 (2022)	Mandated PQC transition by 2035	All National Security Systems must migrate
Google Quantum AI (2024)	Willow chip: 105 qubits with error correction below threshold	Key milestone toward fault-tolerant quantum computing

The honest answer is that nobody knows exactly when. Quantum computing has had false starts and unexpected breakthroughs. But the consensus is that the window is somewhere between 2030 and 2040, and the consequences of being wrong on the optimistic side are catastrophic and irreversible. Once data has been decrypted, you cannot un-decrypt it.

Mosca's Theorem: A Framework for Urgency

In 2015, Dr. Michele Mosca of the University of Waterloo's Institute for Quantum Computing proposed a simple framework for evaluating the urgency of post-quantum migration. It is sometimes called "Mosca's inequality" or "Mosca's theorem," and it uses three variables:

X = the number of years the data must remain secure (its "shelf life")
Y = the number of years it will take to fully migrate your systems to post-quantum cryptography
Z = the number of years until a cryptographically relevant quantum computer (CRQC) exists

The rule is straightforward: if X + Y > Z, you should have already started migrating.

Let us work through a concrete example. A hospital encrypts patient records that must remain confidential for 50 years (X = 50). Migrating all their systems to post-quantum cryptography will take 5 years (Y = 5). If a quantum computer arrives in 15 years (Z = 15), then X + Y = 55, which is far greater than Z = 15. The hospital needed to start migrating decades ago. Even if the quantum computer is 30 years away, 50 + 5 = 55 is still greater than 30.

For a technology company with trade secrets that need 10 years of protection (X = 10), a 2-year migration timeline (Y = 2), and a quantum computer arriving in 15 years (Z = 15), X + Y = 12, which is less than 15. They have a bit of breathing room, but not much. And if Z turns out to be 10 instead of 15, they are already too late.

The key insight of Mosca's theorem is that the migration timeline Y is the variable most under your control. You cannot speed up or slow down quantum computing research. You cannot reduce how long your data needs protection. But you can start migrating earlier, which reduces Y from your total risk equation.

Why Current Encryption Cannot Be Saved

A common question is: "Can we just use bigger RSA keys?" The answer is no. Shor's algorithm breaks RSA in polynomial time, meaning the attack scales efficiently with key size. Doubling the RSA key size does not double the time to break it. It merely adds a modest amount to the quantum computation. No practical RSA key size can withstand Shor's algorithm.

The same applies to elliptic curve cryptography (ECDH, ECDSA, Ed25519, X25519). Shor's algorithm for discrete logarithms breaks all elliptic curve key sizes. There is no "quantum-resistant curve." The mathematical structure that makes elliptic curves efficient for cryptography is the same structure that makes them vulnerable to quantum attack.

Symmetric encryption (AES) is a different story. AES-256 remains secure against quantum computers. Grover's algorithm provides only a quadratic speedup, reducing AES-256 to an effective security level equivalent to AES-128. This is still more than sufficient. The weak link is the key exchange that establishes the AES session key. If the key exchange uses RSA or ECDH, an attacker who records the exchange can later use a quantum computer to extract the AES key and decrypt everything.

This is precisely why HNDL is such a potent strategy. The attacker does not need to break AES. They need to break the key exchange. And every key exchange recorded today using RSA or ECDH is a future target.

The Signal Protocol: A Case Study in Proactive Defense

Signal Messenger, used by journalists, activists, and millions of privacy-conscious individuals worldwide, provides an instructive example of how seriously the HNDL threat is taken.

In 2023, Signal updated its protocol to include post-quantum key exchange (PQXDH). The protocol combines X25519 (classical) with a post-quantum key encapsulation mechanism. Signal's engineering team acknowledged that encrypted messages sent today could be recorded by adversaries and decrypted in the future. By adding post-quantum protection now, Signal ensures that messages exchanged from this point forward are protected against both current and future threats.

The key insight from Signal's decision: they did not wait for quantum computers to exist. They did not wait for a confirmed HNDL attack. They looked at the mathematics, looked at the threat model, and acted preemptively. Signal's user base includes dissidents, whistleblowers, and journalists whose communications could be sensitive for decades. Waiting would have been irresponsible.

Google Chrome took a similar approach, deploying hybrid ML-KEM + X25519 key exchange in TLS 1.3 connections. When you visit a website using Chrome, your browser now establishes a post-quantum-protected connection by default. The decision was driven by the same HNDL logic: TLS traffic recorded today could be decrypted when quantum computers arrive, so the protection needs to be in place before that happens.

How Long Does Data Actually Need Protection?

Most people underestimate the sensitivity lifetime of their data. Consider these real-world requirements:

HIPAA (US health data): Covered entities must protect individually identifiable health information for the life of the patient plus additional years. For a 25-year-old, that could mean 70+ years.
GDPR (EU personal data): Personal data must be protected for as long as it can identify a living individual. There is no fixed time limit.
US government classified information: Automatic declassification occurs at 25 years for most documents, but Restricted Data (nuclear weapons), intelligence sources and methods, and certain categories can be classified for 50 to 75 years or indefinitely.
Attorney-client privilege: Survives the death of the client and has no expiration date in most jurisdictions.
Trade secrets: Protected as long as the information remains secret and provides competitive advantage. Can be indefinite.

For most sensitive data, the protection lifetime exceeds the expected arrival of quantum computers. This means HNDL is not a theoretical risk. It is an active, measurable gap in current security postures.

The Economics of HNDL: Why Storage Costs Make It Inevitable

One reason HNDL is so dangerous is that the economics overwhelmingly favor the attacker. Consider the cost equation:

A petabyte (one million gigabytes) of hard drive storage costs roughly custom pricing to $20,000 at enterprise pricing. For a nation-state intelligence agency with a budget measured in billions of dollars, this is insignificant. The entire annual internet traffic of a medium-sized country could be stored for a few million dollars, which is a rounding error in an intelligence budget.

Meanwhile, the value of the decrypted data is enormous. Diplomatic cables can shift geopolitical negotiations. Military communications can expose vulnerabilities in weapons systems. Corporate communications can reveal trade secrets worth billions. A single intercepted merger/acquisition negotiation could be worth more than the entire storage infrastructure.

The cost-benefit analysis is simple: storage is cheap, data is priceless, and patience is free. Any rational actor with the capability to intercept encrypted traffic has a strong incentive to do so, even if they cannot decrypt it for another decade.

This asymmetry is what makes HNDL fundamentally different from other security threats. Most attacks require breaking in now, and the defender's job is to make that prohibitively expensive or difficult. With HNDL, the attacker only needs to collect and wait. The defender's job is to ensure that waiting does not help, and the only way to do that is to use encryption that quantum computers cannot break.

What You Can Do About It

The good news: the solution already exists. NIST standardized ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) specifically to address the quantum threat. These algorithms use mathematical problems (lattice problems, hash functions) that quantum computers cannot solve efficiently.

For Data at Rest (Files on Disk)

Identify files with long sensitivity lifetimes. Medical records, legal documents, financial records, personal archives, trade secrets.
Re-encrypt using quantum-safe algorithms. Files encrypted with GPG (RSA), VeraCrypt, or other classical tools should be re-encrypted. QNSQY uses ML-KEM + X25519 hybrid encryption, protecting against both classical and quantum threats.
Encrypt before uploading to cloud storage. Do not rely on the cloud provider's encryption. Encrypt locally with quantum-safe tools first, then upload the encrypted file. Even if the provider is compromised, the file remains protected.

For Data in Transit (Network Communications)

Adopt TLS 1.3 with post-quantum key exchange. Google Chrome and Cloudflare have already deployed ML-KEM in TLS. As browser and server support expands, data in transit will be protected.
Minimize sensitive data transmission. If data does not need to cross a network, do not send it. Process sensitive data locally whenever possible.
Use post-quantum VPN configurations. Some VPN providers are beginning to offer post-quantum key exchange. Evaluate your VPN provider's cryptographic roadmap.

For Archived Data

Audit existing encrypted archives. Any backup or archive encrypted with RSA or ECDH key exchange is vulnerable to HNDL. Create an inventory.
Re-encrypt archives with post-quantum algorithms. This is the most labor-intensive step but also the most critical. Every day an RSA-encrypted archive remains accessible to an adversary is another day it could be harvested.

The Irreversibility Problem

What makes HNDL uniquely dangerous, compared to other security threats, is its irreversibility. Most cyberattacks can be mitigated after the fact. If a hacker steals your password, you change it. If malware infects your computer, you can reformat and restore from backup. If a database is breached, the organization can issue new credentials.

HNDL offers no such remediation. Once encrypted data has been recorded by an adversary, there is no way to "un-record" it. Even if you switch to quantum-safe encryption tomorrow, every byte of classically encrypted data that has already been transmitted and captured remains vulnerable. The encryption was applied at the time of transmission, and it cannot be retroactively strengthened.

This creates a permanent, growing stockpile of potentially decryptable data. Every day that passes without quantum-safe encryption adds to that stockpile. Every email sent with classical TLS, every file transferred over a classical VPN, every backup uploaded with RSA-based encryption becomes another entry in the adversary's collection.

The only defense against HNDL is prevention. Use quantum-safe encryption before the data is transmitted. Once it is in transit with classical protection, the window for protection has closed. This is the fundamental reason that every major security organization urges immediate action rather than a wait-and-see approach.

Sources

Protect Your Data Before It's Too Late

QNSQY's quantum-safe encryption ensures your files stay private, even decades from now.

Originally published at quantumsequrity.com.

Forem: Quantum Sequrity

Post-Quantum Encryption for Healthcare and HIPAA

Post-Quantum Encryption for Healthcare and HIPAA

Post-Quantum Encryption for Healthcare and HIPAA

Healthcare Data: A High-Value, Long-Lived Target

HIPAA Encryption Requirements: What the Law Says

Why Healthcare Is Uniquely Vulnerable to Quantum Threats

Extended Retention Periods

Lifetime Relevance of Patient Data

Interconnected Systems and Data Sharing

Current State: What Most Healthcare Organizations Use

The NIST Post-Quantum Solution: ML-KEM + AES-256-GCM

How QNSQY Addresses Healthcare Encryption Needs

Air-Gapped Encryption

Audit Logging

Hybrid Post-Quantum Encryption by Default

Memory Protection

Compliance Framework Alignment

NIST SP 800-66 (HIPAA Security Rule Implementation)

NIST Cybersecurity Framework (CSF)

HHS Enforcement and Breach Notification

Migration Steps for Healthcare Organizations

The Cost of Waiting

The Bottom Line

Related Articles

Protect Patient Data Against Quantum Threats

Sources

AES-256-GCM: Quantum-Safe Encryption

AES-256-GCM: Quantum-Safe Encryption

AES-256-GCM: Why 256-Bit Encryption Survives Quantum Computers

The Padlock on Everything You Do Online

Breaking Down the Name: AES, 256, and GCM

Symmetric Encryption: One Key, Two Jobs

How AES Actually Scrambles Your Data

Why 256 Bits? The Quantum Computer Question

What GCM Does (And Why It Is Non-Negotiable)

The Nonce: GCM's One Critical Rule

Performance: Why AES-256-GCM Is Practically Free

Where You Already Use AES-256-GCM (Without Knowing It)

AES-256-GCM in QNSQY

A 25-Year Track Record

Sources

Related Articles

Quantum-Safe Symmetric Encryption

Protect Data from Quantum Computers

Protect Data from Quantum Computers

How to Protect Your Data from Quantum Computers

The Quantum Threat Is Not Hypothetical

What Data Is Actually at Risk?

Vulnerable to Quantum Attack

Safe from Quantum Attack

Which Files Need Protection?

Why AES-256 Survives but RSA Does Not

Practical Steps: What You Can Do Right Now

For Individuals

For Organizations

Understanding the Protection Layers

The Harvest Now, Decrypt Later Problem

The Real Quantum Threat Timeline

What the Transition Looks Like for Different Users

Individual Users

Small and Medium Businesses

Large Enterprises and Government

Common Questions

Is AES-256 enough on its own?

Is the free version of QNSQY actually secure?

Can I decrypt files on another computer?

What happens if I forget my password?

Why Act Now Rather Than Later

Sources

Related Articles

Why Hybrid Encryption Matters Blog

Why Hybrid Encryption Matters

Why Use Two Locks When One Should Be Enough?

The Honest Reason We Need Both

If ML-KEM Has an Unforeseen Classical Weakness

If a Quantum Computer Breaks X25519

How Hybrid Key Combination Actually Works

The AND Construction vs. the OR Construction

What the Major Security Organizations Say