{“lastseen”:”2026-04-20T18:05:08″,”description”:”The advancing threat of cryptographically-relevant quantum computers has made it urgent to replace currently-deployed asymmetric cryptography primitives\u2014key exchange (ECDH) and digital signatures (RSA, ECDSA, EdDSA)\u2014which are vulnerable to Shor\u2019s quantum algorithm. It does not, however, impact existing symmetric cryptography algorithms (AES, SHA-2, SHA-3) or their key sizes.\\n\\nThere\u2019s a common misconception that quantum computers will \u201chalve\u201d 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\u2019s 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\u2019s.\\n\\n**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.\\n\\n## The Grover speedup\\n\\nGrover\u2019s is a quantum algorithm that allows searching an input space of size _N_ of an unstructured function _f_ for the \u201cright answer\u201d in \u03c0\/4\u00d7N\\\\pi \/ 4 \\\\times \\\\sqrt{N} invocations of _f_.\\n\\nThis is commonly interpreted to mean that Grover\u2019s algorithm can find an AES-128 key in 2642^{64} \u201ctime.\u201d 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.\\n\\nA few important things to understand about Grover\u2019s algorithm:\\n\\n * the function oracle _f_ must be implemented as part of the quantum circuit;\\n * the oracle invocations have to happen one after the other in series;\\n * importantly, there is no better way to parallelize the attack than to partition the search space (Zalka, 1997).\\n\\n\\n\\nWhy does the last point matter? Because unlike regular bruteforce attacks, which are \u201cembarrassingly parallel,\u201d partitioning the search space degrades the Grover quadratic speedup.\\n\\nConsider 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\\n\\n264\u00d75 ns\u22483,000 years. 2^{64} \\\\times 5 \\\\text{ ns} \\\\approx 3{,}000 \\\\text{ years}.\\n\\nSo we parallelize it across \\n\\n216=65,536 CPUs 2^{16} = 65{,}536 \\\\text{ CPUs}\\n\\neach exploring\\n\\n2(64\u221216)=248 keys 2^{(64 – 16)} = 2^{48} \\\\text{ keys}\\n\\nin a little over \\n\\n248\u00d75 ns\u224816 days. 2^{48} \\\\times 5 \\\\text{ ns} \\\\approx 16 \\\\text{ days}.\\n\\nNote how the total amount of work done across the system\\n\\n216\u00d7248=264 2^{16} \\\\times 2^{48} = 2^{64}\\n\\nhas not changed.\\n\\nThis 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\\n\\nLet\u2019s try the same with a Grover attack on 128-bit keys. Again, running\\n\\n2128=264 \\\\sqrt{2^{128}} = 2^{64}\\n\\noperations in a row is infeasible, so we again parallelize the attack across 2162^{16} quantum computers, each exploring\\n\\n2(128\u221216)=2112 keys. 2^{(128 – 16)} = 2^{112} \\\\text{ keys}.\\n\\nEach instance will need to do\\n\\n2128\/216=256 work. \\\\sqrt{2^{128} \/ 2^{16}} = 2^{56} \\\\text{ work}.\\n\\nNotice how that\u2019s not 2482^{48}! A 2162^{16} search space reduction factor inside a square root only saves 282^{8} of work per instance, whereas classically it saves the full 2162^{16}.\\n\\nThe total amount of work across the system went _up_ from 2642^{64} to\\n\\n256\u00d7216=272 2^{56} \\\\times 2^{16} = 2^{72}\\n\\nbecause we parallelized the attack, diluting the quadratic speedup in the process.\\n\\n### Running the numbers\\n\\nThat gives us the intuition for why Grover\u2019s algorithm doesn\u2019t parallelize. To decide if it\u2019s still a threat we need to run the numbers with concrete orders of magnitude.\\n\\nFirst, we need to establish how many operations, or gates, in a row we can perform. To be conservative, let\u2019s say that we have a fast-clock quantum architecture like superconducting qubits, and that a gate takes 1 \u00b5s.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 \u201cdepth\u201d of\\n\\n10 years\/1 \u00b5s\u2248248 10 \\\\text{ years} \/ 1 \\\\text{ \u00b5s} \\\\approx 2^{48}\\n\\nNext, 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 \u201cwidth\u201d of 724, which is roughly speaking the number of logical qubits operating in parallel).\\n\\nNow we can solve for the lowest parallelization factor that will keep each instance within a maximum depth of 2482^{48} (i.e. completing in a decade on these hypothetical fast and perfect quantum computers).\\n\\n\u03c0\/4\u00d72128\/x\u00d7232=248 \\\\pi \/ 4 \\\\times \\\\sqrt{2^{128} \/ x} \\\\times 232 = 2^{48} x\u2248247 x \\\\approx 2^{47}\\n\\n**This means we\u2019ll need 140 trillion quantum circuits of 724 logical qubits each operating in parallel for 10 years to break AES-128 with Grover\u2019s.**\\n\\nAnother way to measure the cost of that attack is its _DW_ cost, the depth \u00d7 width product, roughly equivalent to discussing the product of cycles and cores for classical computation.\\n\\n\u03c0\/4\u00d72128\/247\u00d7232\u00d7724\u00d7247\u22482104.5 \\\\pi \/ 4 \\\\times \\\\sqrt{2^{128} \/ 2^{47}} \\\\times 232 \\\\times 724 \\\\times 2^{47} \\\\approx 2^{104.5}\\n\\nNote that unlike Shor\u2019s algorithm instantiations (and quantum error correction) which have been getting drastically better over the years, there aren\u2019t many terms in that formula that can improve. The only two that are open to optimization are the AES-128 Grover oracle depth (232) and width (724), but they contribute only 17 bits to the total cost, and there is probably little space left for improvement. Liao and Luo (2025) shaved 7.5 bits off the very first estimate by Grassl et al. (2015) and 1.5 bits off the earliest Grover-specific estimate of Jaques et al. (2019).\\n\\n## A comparison with Shor\u2019s\\n\\nSpeaking of Shor\u2019s, how does this compare with the recently discussed quantum attacks against 256-bit elliptic curves? After all, there are people who believe or believed those to be infeasible, too, but I\u2019ve been arguing to take them seriously.\\n\\nBabbush et al. (2026) claim a Shor\u2019s execution in\\n\\n70M\u2248226 gates 70\\\\text{M} \\\\approx 2^{26} \\\\text{ gates}\\n\\nwhich would take minutes on an architecture with \u201cfast\u201d gate time of 10 \u00b5s (which is 10 times slower than what we conservatively assumed above).\\n\\n2104.5\/226=278.5 2^{104.5} \/ 2^{26} = 2^{78.5}\\n\\n**Breaking AES-128 with Grover is 430,000,000,000,000,000,000,000 times more expensive than breaking 256-bit elliptic curves with Shor\u2019s.**\\n\\n## NIST agrees\\n\\nThe U.S. National Institute of Standards and Technology (NIST) is the standardization body that ran the international competition for post-quantum cryptography and wrote the ML-KEM and ML-DSA specification documents.\\n\\nNIST not only considers AES-128 to be safe, but made it _the benchmark_ for the security of post-quantum primitives. AES-128 is by definition a Category 13 post-quantum algorithm.\\n\\nIn justifying the use of AES-128, NIST refers to the same observations we explained above, and introduces the concept of _MAXDEPTH_ which is exactly the maximum serial computation that forces parallelization and limits Grover\u2019s quadratic speedup.\\n\\n\\u003e It is worth noting that the security categories based on these reference primitives provide substantially more quantum security than a na\u00efve analysis might suggest. For example, categories 1, 3 and 5 are defined in terms of block ciphers, which can be broken using Grover\u2019s algorithm, with a quadratic quantum speedup. But Grover\u2019s algorithm requires a long-running serial computation, which is difficult to implement in practice. In a realistic attack, one has to run many smaller instances of the algorithm in parallel, which makes the quantum speedup less dramati[c].\\n\\nNIST\u2019s calculation uses less optimized (and hence less conservative) AES quantum circuits (from Grassl et al. (2015) instead of Liao and Luo (2025)), but faster (and hence more conservative) logical gate speed. Nonetheless, it lands in the same ballpark and comes to the same conclusion.\\n\\nFurther proof, NIST IR 8547 ipd, _Transition to Post-Quantum Cryptography Standards_ , disallows all quantum-vulnerable algorithms from 2035. However, it reiterates that all AES key sizes remain allowed in Section 4.1.3.\\n\\n\\u003e NIST\u2019s existing standards in symmetric cryptography \u2014 including hash functions, XOFs, block ciphers, KDFs, and DRBGs \u2014 are significantly less vulnerable to known quantum attacks than the public-key cryptography standards in SP 800-56A, SP 800-56B, and FIPS 186. In particular, all NIST-approved symmetric primitives that provide at least 128 bits of classical security are believed to meet the requirements of at least Category 1 security within the system of five security strength categories for evaluating parameter sets in the NIST PQC standardization process (see Table 1). \\n\\nFinally, in the Post-Quantum Cryptography FAQs, there is an explicit answer to \u201cshould we double AES key sizes.\u201d (Emphasis mine.)\\n\\n\\u003e To protect against the threat of quantum computers, should we double the key length for AES now? (added 11\/18\/18)\\n\\u003e \\n\\u003e Grover\u2019s algorithm allows a quantum computer to perform a brute force key search using quadratically fewer steps than would be required classically. Taken at face value, this suggests that an attacker with access to a quantum computer might be able to attack a symmetric cipher with a key up to twice as long as could be attacked by an attacker with access only to classical computers. However there are a number of mitigating factors suggesting that Grover\u2019s algorithm will not speed up brute force key search as dramatically as one might suspect from this result. First of all, quantum computing hardware will likely be more expensive to build and use than classical hardware. Additionally, it was proven by Zalka in 1997 that in order to obtain the full quadratic speedup, all the steps of Grover\u2019s algorithm must be performed in series. In the real world, where attacks on cryptography use massively parallel processing, the advantage of Grover\u2019s algorithm will be smaller.\\n\\u003e \\n\\u003e Taking these mitigating factors into account, **it is quite likely that Grover\u2019s algorithm will provide little or no advantage in attacking AES, and AES 128 will remain secure for decades to come**. Furthermore, even if quantum computers turn out to be much less expensive than anticipated, the known difficulty of parallelizing Grover\u2019s algorithm suggests that both AES 192 and AES 256 will still be safe for a very long time. This of course assumes that no new cryptographic weaknesses, either with respect to classical or quantum cryptanalysis, are found in AES.\\n\\u003e \\n\\u003e Based on such understanding, **current applications can continue to use AES with key sizes 128, 192, or 256 bits**. NIST will issue guidance regarding any transitions of symmetric key algorithms and hash functions to protect against threats from quantum computers when we can foresee a transition need. Until then, users should follow the recommendations and guidelines NIST has already issued. In particular, anything with less than 112 bits of classical security should not be used.\\n\\nNIST is not equivocating about this at all: 128-bit keys are fine.\\n\\n## BSI agrees\\n\\nWhat about other standards bodies? The German Federal Office for Information Security recently published BSI TR-02102-1 _Cryptographic Mechanisms: Recommendations and Key Lengths_ with \u201cupdates in the area of PQ cryptography.\u201d\\n\\nIn it, they mention Grover\u2019s in passing and with less conclusiveness than NIST, but come to the same conclusion:\\n\\n\\u003e The following block ciphers are recommended for use in new cryptographic systems:\\n\\u003e \\n\\u003e AES-128, AES-192, AES-256\\n\\nIn the same publication, they recommend transitioning off quantum-vulnerable primitives (which notably does not include AES-128) even sooner than NIST:\\n\\n\\u003e The sole use of classic key agreement mechanisms is only recommended until the end of 2031, see also Section 2.3. \\n\\n## Samuel Jaques agrees\\n\\nSamuel Jaques is an assistant professor in the Department of Combinatorics and Optimization at the University of Waterloo, specializing in cryptography and quantum computing. You might be familiar with his Landscape of Quantum Computing.\\n\\nI found this 2024 slide deck after having run all the numbers above, and I felt a bit silly having essentially re-done the same work two years later and with less domain expertise, but it\u2019s actually encouraging how closely the conclusions match: the margin is wide enough and the relevance of guessing and optimization small enough, that we\u2019re all repeatedly coming to equivalent conclusions.\\n\\n\\n\\n\\n\\nHe talks about how hard it is to build even a single logical qubit, which I am ignoring above because we are assuming a world where scalable quantum error correction _does_ happen, or we wouldn\u2019t be worried about asymmetric cryptography either.\\n\\nHe also talks about decoherence, which I only hinted at by mentioning how unlikely it is that a quantum computer can _actually_ operate for a decade uninterrupted, like we are conservatively assuming.\\n\\nHe makes the excellent point that the right metric to optimize Grover oracle circuits against is depth\u00b2 \u00d7 width, because depth contributes both to cost and to hitting the maximum depth. This suggests the Liao and Luo (2025) circuit might not be optimal, and he uses one from Jang et al. (2022) instead, but again comes to a very similar result.\\n\\nFinally, he points out that each logical T-gate in a surface code architecture requires 2162^{16} physical operations, so there are still terms missing in the formula before reaching a practical resource estimate.\\n\\n## Why not switch anyway, you know, to be safe?\\n\\nThe whole post-quantum transition is about mitigating speculative risk, so why not be \u201csafe\u201d with symmetric keys, too? Because resources are finite, churn has a cost, and coordination is important.\\n\\nThe field is rushing to deploy post-quantum cryptography because experts are telling us there is a concrete danger to asymmetric cryptography. Conversely, _the same experts_ are telling us that there is _not_ any danger to symmetric cryptography.\\n\\nSymmetric encryption is separate enough from asymmetric encryption that we usually don\u2019t get to switch both at the same time for minimal marginal cost. For example, changing the negotiated TLS key exchange and PKI signature algorithms has little to do with changing supported cipher suites.\\n\\n**Conflating necessary and unnecessary changes will cause needless churn and take resources away from the urgent updates.** We\u2019re lucky we can leave the symmetric cryptography (sub-)systems untouched; we should take that blessing and focus on the work that actually needs doing, _which is plenty_.\\n\\nThere is also a complexity and coordination angle: transitioning any open ecosystem like TLS or anything that\u2019s implemented across different libraries and programming languages requires agreeing on the target. It\u2019s a lot easier to agree on something that\u2019s technically accurate: we can either converge spontaneously or convince each other with technical arguments. Aiming for unnecessary and underspecified targets, instead, breeds interoperability issues and requires supporting multiple different idiosyncratic opinions, which introduces complexity.\\n\\n## What about CNSA 2.0?\\n\\nThere is admittedly one compliance regime which requires 256-bit symmetric keys: CNSA 2.0.\\n\\nThat\u2019s not a quantum computing adjustment, though: CNSA 2.0 requires a 256-bit \u201csecurity level\u201d for everything, like its predecessor Suite B always did for the Top Secret classification, and indeed mandates ML-KEM-1024 and ML-DSA-87. As far as I can tell, its intention is to avoid the very same fragmentation introduced by \u201csecurity levels\u201d by picking one oversized primitive for all settings.\\n\\nBy accepting AES-256 (instead of a non-existing AES-512) at the 256-bit security level, CNSA 2.0 also acknowledges that Grover\u2019s algorithm doesn\u2019t halve the security of AES.\\n\\nIt\u2019s likely Go will implement CNSA 2.0 profiles, if nothing else because \u201c256-bit everything\u201d is a well-defined target that\u2019s unlikely to move. It\u2019s not the \u201csecure and reasonable\u201d target I tend to prefer, but it\u2019s something we can commit to, unlike \u201csecure and reasonable but with a partial misunderstanding of the security of some primitives\u201d which can mean different things to different people.\\n\\n## Are 256-bit keys always useless?\\n\\nI generally believe that 256-bit \u201csecurity levels\u201d are somewhere between a comfort blanket and numerology, because as a colleague put it recently \u201cwe don\u2019t believe in counting to 21282^{128},\u201d but that doesn\u2019t mean 256-bit keys (or block sizes) are always useless to achieve the 128-bit security level.\\n\\nWhen collisions are a concern and birthday bounds are in play, the security in bits really is halved, so you need e.g. a 256-bit hash output for 128 bits of collision security. (This is why SHA-128 doesn\u2019t exist.) Similarly, multi-target attacks, where the adversary\u2019s advantage is measured as the chance of breaking one of many messages\/keys, can require additional margin depending on how nonces are used.\\n\\nThese are concerns that are deep within the purview of the cryptography engineers designing the protocols, though, and not in scope for the policy-making or system administration choices. Well-designed protocols already account for all this. For example, TLS with AES-128 meets the 128-bit security level with large multi-target margins, thanks to its nonce design.\\n\\nAs a cryptography engineer, I _do_ wish all ciphers took 256-bit keys, as it would make my life easier, but\\n\\n 1. we\u2019ve already done the work of handling the 128-bit keys properly and switching now is going to be wasted effort we could instead put toward the actually urgent post-quantum transition; and\\n 2. AES-256 was unfortunately defined to perform more rounds than AES-128, making it needlessly slower.\\n\\n\\n\\nFor more wishful-vs-real PQ migration, follow me on Bluesky at @filippo.abyssdomain.expert or on Mastodon at @filippo@abyssdomain.expert.\\n\\n## The picture\\n\\nLast month I attended AtmosphereConf 2026, which was held at UBC. The campus is so beautiful, and there\u2019s a spectacular path through the forest to the beach, where you can watch the sun setting over the water.\\n\\n\\n\\nMy work is made possible by Geomys, an organization of professional Go maintainers, which is funded by Ava Labs, Teleport, Tailscale, and Sentry. Through our retainer contracts they ensure the sustainability and reliability of our open source maintenance work and get a direct line to my expertise and that of the other Geomys maintainers. (Learn more in the Geomys announcement.) Here are a few words from some of them!\\n\\nTeleport \u2014 For the past five years, attacks and compromises have been shifting from traditional malware and security breaches to identifying and compromising valid user accounts and credentials with social engineering, credential theft, or phishing. Teleport Identity is designed to eliminate weak access patterns through access monitoring, minimize attack surface with access requests, and purge unused permissions via mandatory access reviews.\\n\\nAva Labs \u2014 We at Ava Labs, maintainer of AvalancheGo (the most widely used client for interacting with the Avalanche Network), believe the sustainable maintenance and development of open source cryptographic protocols is critical to the broad adoption of blockchain technology. We are proud to support this necessary and impactful work through our ongoing sponsorship of Filippo and his team.\\n\\n* * *\\n\\n 1. There are sequential attacks which indeed were misinterpreted as more practical than they are. For example, a static Diffie-Hellman oracle attack against Curve25519 or ristretto255 requires 263.52^{63.5} oracle invocations, which sound practical, except they need to be sequential, making the attack take two centuries in extremely optimal circumstances. \u21a9\\n\\n 2. \u201cGate\u201d here means _logical_ T-gate, not physical gate. Superconducting qubits execute physical gates in ~100 ns, but a logical T-gate on an error-corrected surface-code machine is much slower. Published estimates for logical T-gate latency fall in the single-to-tens-of-microseconds range, so 1 \u00b5s sits at the conservative (for us) end. \u21a9\\n\\n 3. Is Category 1 enough? Don\u2019t we use ML-KEM-768 and ML-DSA-44 because they are Category 3 and Category 2, respectively? We do that not because Category 1 is insufficient, but because there\u2019s concern that lattice cryptanalysis might advance slightly, and move ML-KEM-768 or ML-DSA-44 down to Category 1. There is no equivalent worry around AES, which indeed was picked as the very _bar_ for Category 1. \u21a9”,”published”:”2026-04-20T15:21:12″,”modified”:”2026-04-20T15:21:12″,”type”:”filippoio”,”title”:”Quantum Computers Are Not a Threat to 128-bit Symmetric Keys”,”source”:””,”references”:””,”id”:”FILIPPOIO:A4CFF6D61CB110EED00826901925D2C7″,”bulletinFamily”:”blog”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/words.filippo.io\/128-bits\/”,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2026-04-20T18:05:08″,”description”:”The advancing threat of cryptographically-relevant quantum computers has made it urgent to replace currently-deployed asymmetric cryptography primitives\u2014key exchange (ECDH) and digital signatures (RSA, ECDSA, EdDSA)\u2014which…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,162,13,33,7,11,5],"class_list":["post-48118","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-filippoio","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n