20 Apr 2026 Quantum Computers Are Not a Threat to 128-bit Symmetric Keys The advancing threat of cryptographically-relevant quantum computers has made it urgent to replace currently-deployed asymmetric cryptography primitives—key exchange (ECDH) and digital signatures (RSA, ECDSA, EdDSA)—which are vulnerable to Shor’s quantum algorithm . It does not, however, impact existing symmetric cryptography algorithms (AES, SHA-2, SHA-3) or their key sizes. There’s a common misconception that quantum computers will “halve” the security of symmetric keys, requiring 256-bit keys for 128 bits of security. That is not an accurate interpretation of the speedup offered by quantum algorithms, it’s not reflected in any compliance mandate, and risks diverting energy and attention from actually necessary post-quantum transition work. The misconception is usually based on a misunderstanding of the applicability of a different quantum algorithm, Grover’s . AES-128 is safe against quantum computers. SHA-256 is safe against quantum computers. No symmetric key sizes have to change as part of the post-quantum transition. This is a near-consensus opinion amongst experts and standardization bodies and it needs to propagate to the rest of the IT community. The rest of this article backs up this claim both technically and with references to relevant authorities. The Grover speedup Grover’s is a quantum algorithm that allows searching an input space of size N of an unstructured function f for the “right answer” in π / 4 × N \pi / 4 \times \sqrt{N} invocations of f . This is commonly interpreted to mean that Grover’s algorithm can find an AES-128 key in 2 64 2^{64} “time.” That is not the case in practice, because running such an attack as a single sequential thread would take hundreds of thousands of years, and parallelizing it makes its total cost grow. A few important things to understand about Grover’s algorithm: the function oracle f must be implemented as part of the quantum circuit; the oracle invocations have to happen one after the other in series; importantly, there is no better way to parallelize the attack than to partition the search space ( Zalka, 1997 ). Why does the last point matter? Because unlike regular bruteforce attacks, which are “embarrassingly parallel,” partitioning the search space degrades the Grover quadratic speedup. Consider a classical bruteforce of a 64-bit key, where each attempt takes 5 ns (~ 16 cycles at 3 GHz). Running that on a single CPU would take nearly 2 64 × 5 ns ≈ 3,000 years. 2^{64} \times 5 \text{ ns} \approx 3{,}000 \text{ years}. So we parallelize it across 2 16 = 65,536 CPUs 2^{16} = 65{,}536 \text{ CPUs} each exploring 2 ( 64 − 16 ) = 2 48 keys 2^{(64 - 16)} = 2^{48} \text{ keys} in a little over 2 48 × 5 ns ≈ 16 days. 2^{48} \times 5 \text{ ns} \approx 16 \text{ days}. Note how the total amount of work done across the system 2 16 × 2 48 = 2 64 2^{16} \times 2^{48} = 2^{64} has not changed. This is why we consider 64-bit keys weak: because they can be searched in parallel efficiently. If the attack had to be sequential, there would be no risk. 1 Let’s try the same with a Grover attack on 128-bit keys. Again, running 2 128 = 2 64 \sqrt{2^{128}} = 2^{64} operations in a row is infeasible, so we again parallelize the attack across 2 16 2^{16} quantum computers, each exploring 2 ( 128 − 16 ) = 2 112 keys. 2^{(128 - 16)} = 2^{112} \text{ keys}. Each instance will need to do 2 128 / 2 16 = 2 56 work. \sqrt{2^{128} / 2^{16}} = 2^{56} \text{ work}. Notice how that’s not 2 48 2^{48} ! A 2 16 2^{16} search space reduction factor inside a square root only saves 2 8 2^{8} of work per instance, whereas classically it saves the full 2 16 2^{16} . The total amount of work across the system went up from 2 64 2^{64} to 2 56 × 2 16 = 2 72 2^{56} \times 2^{16} = 2^{72} because we parallelized the attack, diluting the quadratic speedup in the process. Running the numbers That gives us the intuition for why Grover’s algorithm doesn’t parallelize. To decide if it’s still a threat we need to run the numbers with concrete orders of magnitude. First, we need to establish how many operations, or gates, in a row we can perform. To be conservative, let’s say that we have a fast-clock quantum architecture like superconducting qubits, and that a gate takes 1 µs. 2 If we are willing to keep the attack running (with no power outage or loss of fidelity!) for a decade, that gives us a maximum sequence of gates or “depth” of 10 years / 1 µs ≈ 2 48 10 \text{ years} / 1 \text{ µs} \approx 2^{48} Next, we need to know how many sequential gates it takes to compute AES-128 inside the quantum circuit. Liao and Luo (2025) provide a highly optimized Grover oracle for AES-128 with a depth of 232 T-gates (and a circuit “width” of 724, which is roughly speaking the number of logical qubits operating in parallel). Now we can solve for the lowest parallelization factor that will keep each instance within a maximum depth of 2 48 2^{48} (...