Is AES-256 quantum safe? What Grover’s algorithm changes

Asking whether AES-256 is quantum safe means asking whether the Advanced Encryption Standard with a 256-bit key, defined in FIPS 197, can still protect data once large fault-tolerant quantum computers exist. The short answer is yes. AES-256 is still considered quantum safe. For connections between sites, clouds and remote users, the quantum risk sits somewhere else.

Operators of OT and critical infrastructure keep links in service for years and sometimes decades, so this distinction matters. It tells you where to spend migration effort and where a configuration change is enough.

Is AES-256 quantum safe?

Yes. No known quantum algorithm breaks AES-256 in any practical sense, and NIST uses AES-256 as the benchmark for its highest post-quantum security category.

NIST’s position is unusually direct. In its post-quantum cryptography FAQ, the institute concludes that current applications can keep using AES with 128, 192 or 256-bit keys. On AES-128, NIST writes that “AES 128 will remain secure for decades to come.” It expects AES-192 and AES-256 to stay safe for a very long time even if quantum computers turn out cheaper than anticipated, because Grover’s algorithm is hard to parallelize.

The transition report NIST IR 8547 follows the same line. It lists RSA, (EC) Diffie-Hellman, ECDSA and EdDSA as quantum-vulnerable. NIST-approved symmetric primitives with at least 128 bits of classical security stay approved.

Does Grover’s algorithm break AES-128 or AES-256?

No. Grover’s algorithm speeds up brute-force key search but doesn’t break AES. On paper it halves the effective key length, which leaves AES-256 with a very large margin and AES-128 with a reduced but still substantial one.

• Statistic: Grover’s algorithm gives a quadratic (square-root) speedup over classical brute-force key search. Source: NIST CSRC Post-Quantum Cryptography FAQs (2026).
• Statistic: NIST sets the cost of key search on AES-128, its category 1 benchmark, at 2^170/MAXDEPTH quantum gates or 2^143 classical gates. Source: NIST CSRC, PQC Security Evaluation Criteria (2016).

The rule of thumb is that AES-128 offers about 64 bits of security against an idealized Grover attack and AES-256 about 128 bits. That is why many guidance documents present AES-256 as the conservative quantum-resistant choice.

Why the square-root speedup overstates the practical risk

The square-root figure assumes one long, error-free quantum computation. In reality Grover’s algorithm is largely sequential, so splitting the search across many machines gives much less benefit than splitting a classical search. Each step also has to run AES as a reversible quantum circuit, which adds a lot of qubit and gate overhead. NIST builds this into its cost model with the MAXDEPTH parameter, which caps how deep a quantum circuit can realistically run.

NIST cryptographers Dustin Moody and Angela Robinson summarize the result in their paper on standards in a post-quantum era: “doubling the length of the secret key used for AES should provide sufficient protection.”

Why do quantum computers threaten RSA and ECC far more than symmetric encryption?

Shor’s algorithm solves the mathematical problems behind RSA and elliptic-curve cryptography in polynomial time, which breaks them completely. Grover’s algorithm only shaves a square root off a brute-force search. One gives an attacker the key; the other only makes the search somewhat cheaper.

Estimates of the hardware needed to break RSA have fallen quickly:

• Statistic: A 2021 study estimated that RSA-2048 could be factored in about 8 hours using 20 million noisy qubits. Source: Gidney and Ekerå, Quantum 5, 433 (2021).
• Statistic: A 2025 follow-up cut the expected qubit count for breaking RSA-2048 from 20 million to about 1 million. Source: Craig Gidney, arXiv 2505.15917 (May 2025).

Gidney still supports NIST’s proposed deadlines. He explains that this isn’t because he expects such machines by 2030, but because “I prefer security to not be contingent on progress being slow.”

For network links this creates the “harvest now, decrypt later” problem. Encrypted traffic recorded today can be stored. Once the RSA or ECDH key exchange that protected the session keys can be broken, every recorded session becomes readable, no matter how strong the AES layer was. OT telemetry, engineering access sessions and control-system configurations often stay sensitive for years, so they are exposed to exactly this risk.

• Statistic: Under the NIST IR 8547 draft, quantum-vulnerable public-key algorithms at 112-bit security strength would be deprecated after 2030 and disallowed after 2035. Source: NIST IR 8547 Initial Public Draft (November 2024).

Should VPN and IPsec tunnels switch from AES-128 to AES-256 for quantum resistance?

Switching to AES-256 is sensible and usually costs little, but it doesn’t make a tunnel quantum resistant on its own. The step that actually matters is replacing or supplementing the classical key exchange in IKEv2 or TLS with a post-quantum mechanism.

Many organizations treat “upgrade to AES-256” as their quantum plan, and that is a mistake. If an IPsec tunnel negotiates ESP with AES-256-GCM but derives its keys from an ECDH group in IKEv2, a future quantum adversary attacks the ECDH exchange, not AES. NIST names VPN and TLS among the systems with long-term confidentiality needs that should migrate first.

What to check in an OT site-to-site or remote-access tunnel

• Key exchange: Find out whether IKEv2 or TLS supports additional key exchanges (IETF RFC 9370) or post-quantum preshared keys (RFC 8784). The NSA’s draft CNSA 2.0 IPsec profile refers to RFC 8784.
• Rekey intervals: Short rekey intervals limit how much traffic a single compromised session key exposes.
• Cipher mode: If you use AES-GCM, follow NIST SP 800-38D. Never reuse a nonce under the same key, and keep the full 16-octet authentication tag.
• Hardware headroom: Older OT gateways and embedded routers may lack AES hardware acceleration. AES-256 runs 14 rounds instead of 10, so test throughput on the actual devices.
• Crypto agility: Check whether the post-quantum algorithm can be swapped later without replacing the hardware.

Some quantum-safe gateways take a different approach to the same problem. Quantum Network’s QPN, for example, combines a classical and an ML-KEM (FIPS 203) key agreement into one hybrid session key, renews both handshakes every two minutes, and encrypts the payload with ChaCha20-Poly1305 rather than AES. Here too, the quantum resistance comes mainly from the hybrid key establishment, not from the choice of symmetric cipher.

Are SHA-256 and HMAC still safe against quantum computers?

Yes, for most uses. SHA-256 (FIPS 180-4) and HMAC-SHA-256 lose only part of their security margin to quantum attacks. CNSA 2.0 still requires the larger SHA-384 or SHA-512 for national security systems.

Moody and Robinson note that hash functions aren’t considered broken by quantum computers. They recommend a hash output length of twice the target security level to account for Grover’s algorithm. NIST itself defines post-quantum security category 2 by the cost of collision search on SHA-256, so it treats SHA-256 as a meaningful quantum-era benchmark rather than a weak point.

HMAC is in an even better position because its security rests on a secret key. A forger would need to recover or guess a 256-bit key, which again only meets a square-root speedup. In practice the bigger risks to HMAC in OT networks are short or reused keys, and keys distributed over a quantum-vulnerable channel.

What symmetric key sizes does CNSA 2.0 require for network encryption?

CNSA 2.0 requires AES with 256-bit keys for all symmetric encryption, and SHA-384 or SHA-512 for hashing. AES-128 and SHA-256 are not permitted under it.

The NSA published CNSA 2.0 in September 2022 and updated its FAQ in December 2024. The suite consists of ML-KEM-1024 for key establishment, ML-DSA-87 for signatures, AES-256, SHA-384 or SHA-512, and LMS or XMSS for firmware signing. The NSA is turning these choices into protocol profiles through IETF drafts:

CNSA 2.0 is mandatory only for US National Security Systems. Even so, its symmetric choices make a useful reference for critical infrastructure operators who want one conservative baseline across all their links. This comparison describes algorithm choices only; matching them doesn’t amount to any formal approval.

What should OT and critical infrastructure operators change first?

Start with key establishment on long-lived links, then standardize on 256-bit symmetric keys and SHA-384 where devices allow. Cipher upgrades without post-quantum key exchange leave the main exposure untouched.

Here is a practical order of work:

1. Build a cryptographic inventory of every tunnel between sites, to cloud environments and for remote users. For each one, record the key exchange, cipher, hash and rekey settings.
2. Rank links by how long their data stays sensitive. Process data, safety-system configurations and engineering sessions usually come first.
3. Introduce hybrid or post-quantum key establishment on the top-ranked links. Hybrid modes keep classical protection in place while the post-quantum algorithms mature in the field.
4. Move from AES-128 to AES-256 and from SHA-256 to SHA-384 wherever devices support it, and use the hardware refresh cycle for the rest.
5. Choose equipment and software that let you change algorithms later, because NIST IR 8547 makes clear the timeline is measured in years, not decades.