[TLS] Re: [Ssh] A new AI-discovered attack on 7-round AES (commentaries by Orr Dunkelman and D. J. Bernstein)

[Ken Kubota <[e-mail]>]

"But on a related note, photonic quantum computers promise low nanosecond gate speed rates, and if that happens, AES-128 theoretically can be solved in hours to weeks if you can also get the rest of the CRQC puzzle to where it needs to be."

Some AI calculation:

Assumptions (Hypothetical best-case scenario):
- Fault-tolerant photonic quantum ASICs
- 1 ns per logical T-gate
- Optimized Grover implementation
- Known quantum algorithms only (no unknown cryptanalytic breakthroughs)
- Comparison based on 100 million specialized quantum chips

AES-128: Months
AES-256: 10^18 years


The core conclusion is that, while technical progress cannot be ruled out that could break AES-128 within the next two to three decades, AES-256 will likely remain secure provided that no fundamental weaknesses in the algorithm are discovered, which seems unlikely.


By the way, the German Scientific Working Group of the National Cybersecurity Council also recommends switching to 256 bit. [1]

Another paper: "So it seems prudent to move away from 128-bit keys when expecting the availability of at least a moderate size quantum computer." [2]

In summary: https://mailarchive.ietf.org/arch/msg/ssh/47mIx2MIjUYpn45EBysgmCHy5_4/


Kind regards,

Ken Kubota

____________________________________________________

Ken Kubota
https://doi.org/10.4444/100



[1] https://www.forschung-it-sicherheit-kommunikationssysteme.de/dateien/forschung/2024-03-impulspapier-quanten-cybersicherheit.pdf, p. 1
"Solange der Algorithmus von Grover
der einzige Angriff auf ein Verschlüsselungsverfahren ist,
sollte eine Anpassung der Schlüssellänge auf 256 Bit als Ge-
genmaßnahme genügen."

[2] https://arxiv.org/pdf/1512.04965v1, p. 11



> Am 30.07.2026 um 15:04 schrieb Roger Grimes <[e-mail]>:

> > Not much new thinking
>  Well, true. I should have phrased it better by saying that the “new, growing consensus is that AES-128 is secure.”  Even NIST said AES-128 was still good and originally recommended AES-192 as the recommended min. size before they started recommending 256-bit. 
>  I’ve been writing on the post-quantum subject since 2018 and not only did all of my own writing recommend that people move to AES-256, but 99% of the literature I was reading, including from national post-quantum committees and agencies. There were few authoritative groups saying to stay at AES-128 bit. 
>  It’s only in the last few years that we have had more cryptographic experts not only speak up in support of AES-128, but offer up the math supporting it. Until recently, we didn’t really have any real-world quantum gate and circuit speeds to speak to as evidence. It was all mostly theory. It’s only recently that we’ve got real working quantum computers with any scale of gate or circuit and real-world measurements of gate and circuit speed (which are currently in the microsecond category) to put into that math to show that Grover’s, for sure, was not going to threaten AES-128 (even as gate fidelity and coherence improve) anytime soon. 
>  But on a related note, photonic quantum computers promise low nanosecond gate speed rates, and if that happens, AES-128 theoretically can be solved in hours to weeks if you can also get the rest of the CRQC puzzle to where it needs to be.
>   From: John Mattsson <john.mattsson=[e-mail]> 
> Sent: Thursday, July 30, 2026 8:38 AM
> To: Roger Grimes <[e-mail]>; Soatok Dreamseeker <[e-mail]>; Ken Kubota <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [TLS] Re: [Ssh] A new AI-discovered attack on 7-round AES (commentaries by Orr Dunkelman and D. J. Bernstein)
>   Here is a good summary that IETF sent to ETSI in 2024.
> https://datatracker.ietf.org/liaison/1942/
>  >So, new thinking is that you don’t have to immediately rush to upgrade your AES-128 keys to something longer. But if gate operations get into the low nanoseconds (which seems likely in the future) or if someone figures out a way to parallel-attack a symmetric key better than Grover’s algorithm, then the immediate threat would be back.
>  Not much new thinking, that AES-128 and SHA-256 can continue to be used has been well known for a decade. And Grover’s algorithm is optimal for blackbox attacks. But do support 256 bit in new non-constrained systems, 128 bit keys only have some decades left.
>  Cheers,
> John Preuß Mattsson
>   From: Roger Grimes <roger=[e-mail]>
> Date: Thursday, 30 July 2026 at 14:23
> To: Soatok Dreamseeker <[e-mail]>; Ken Kubota <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Subject: [TLS] Re: [Ssh] A new AI-discovered attack on 7-round AES (commentaries by Orr Dunkelman and D. J. Bernstein)
> You don't often get email from roger=[e-mail]. Learn why this is important
> The short version of why AES-128 is not threatened in the immediate future is:
> • Grover’s algorithm does not parallelize well
> • To break an AES-128 bit key would take a nonillion (number followed by 30 zeros) quantum gates
> • Each quantum gate operation today takes in the microseconds
> • Adding the two figures together means it would take hundreds of millions of years for Grover’s to break AES-128
>  So, new thinking is that you don’t have to immediately rush to upgrade your AES-128 keys to something longer. But if gate operations get into the low nanoseconds (which seems likely in the future) or if someone figures out a way to parallel-attack a symmetric key better than Grover’s algorithm, then the immediate threat would be back.
>   From: Soatok Dreamseeker <[e-mail]>
> Sent: Wednesday, July 29, 2026 7:11 PM
> To: Ken Kubota <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: [TLS] Re: [Ssh] A new AI-discovered attack on 7-round AES (commentaries by Orr Dunkelman and D. J. Bernstein)
>   With Grover's algorithm in quantum computing that in the future might halve the effective security, theoretically symmetric key lengths of 512 bits could be necessary.
>  I do not think Grover's is a meaningful risk to any system in the foreseeable future. See https://words.filippo.io/128-bits/ for a longer treatment on the topic.
>   On Wed, Jul 29, 2026 at 2:10 PM Ken Kubota <[e-mail]> wrote:
> The catastrophic failure of NIST PQC finalists is not a new phenomenon.
> The situation is basically a mess.
> Consequently, hybrid solutions remain the only viable option, while any non-hybrid (or "solo") approach represents a significant security risk.
> 
> What is new here is the emergence of a paradigm in which numerous new cryptographic researchers appear via AI models that also generate novel attacks, as evidenced in first-rate research papers.
> 
> Perhaps the accelerated pace of cryptographic research enabled by AI (e.g., where the scientific progress of next year might correspond to a decade's worth of past advancements) will mitigate the quantum threat, either by having AI identify weak PQC algorithms or by creating new, stronger ones.
> 
> Kind regards,
> 
> Ken Kubota
> 
> ____________________________________________________
> 
> Ken Kubota
> https://doi.org/10.4444/100
> 
> 
> 
> > Am 29.07.2026 um 15:08 schrieb Jan Schermer <[e-mail]>:
> >
> > Isn't this a red herring? You completely missed the part where they attacked HAWK (PQC finalist), _THAT_ is what illustrates the point. Nobody cares about 7-round AES.
> >
> > Jan
> >
> >
> >> On 29. 7. 2026, at 14:58, Ken Kubota <[e-mail]> wrote:
> >>
> >> On both Orr Dunkelman's [1] (TLS list) and D. J. Bernstein's commentary [2] (SSH list) regarding the new AI-generated attack on 7-round AES [3, 4, 5]:
> >>
> >>
> >> "While this is the first improvement in attacking 7-round AES in the last
> >> decade, if you were not worried by the series of papers that reduced the
> >> security of 5-round AES from 2^32 to 2^16, or the somewhat improved attacks
> >> on 6-round AES, then you should not really worry now [t]o start a procedure
> >> for changing 10-round AES (for 128-bit key) for something else, when there
> >> are no attacks on 8-round AES-128." [1]
> >>
> >> This overlooks the very point that Anthropic researchers emphasize themselves:
> >>
> >> "And in the case of AES, our attack extends a long line of work that had previously succeeded at attacking reduced-round variants. But we should not assume that language model capabilities will plateau at this level. In just one year, language models have gone from being unable to perform cryptanalysis of even the most basic ciphers to being capable of finding flaws in cryptographic designs that have escaped discovery despite years of human expert review." [3]
> >> "But as we develop increasingly powerful cryptanalytic results, it would be prudent to consider how researchers should react if a language model were to discover vulnerabilities in cryptosystems where attacks do have an immediate real-world impact." [3]
> >>
> >> The point is not the new attack on 7-round AES, but the very fact that the new attack was AI-generated, and the speed of such developments might increase.
> >> While this is probably the first such groundbreaking research result created by AI, in half a year there might be 10 such papers, and in another half a year 100 papers, etc., in other words, a qualitatively _new paradigm_ of scientific progress, which is not addressed by focusing on the number of rounds.
> >>
> >> Brian Berletic predicted AI development with _exponentially_ growing speed already about half a year ago:
> >>
> >> "There are people that don't even want to acknowledge that AI is a real thing that exists and is speeding forward. And it's not just speeding forward in a linear way. It is exponentially increasing. You can see it. Before it was leaps and bounds year to year. Now it is leaps and bounds month to month even sometimes week to week." [6]
> >>
> >>
> >> "Given this risk, it's particularly dangerous if we allow the pursuit of
> >> every last bit of performance to strip cryptography down to the bare
> >> minimum that resists attack demos. It's much safer to include defense in
> >> depth: for example, 256-bit cipher keys, many more cipher rounds than we
> >> know how to break (the classic recommendation from Anderson, Biham, and
> >> Knudsen is twice as many rounds), and continuing to sign with ECC when
> >> we add PQ signatures." [2]
> >>
> >> While
> >> - twice as many rounds
> >> - hybrid approach (e.g., double encryption)
> >> are obvious conclusions,
> >> "256-bit cipher keys" should be replaced by "256 bits of security" for long-term security.
> >>
> >> With Grover's algorithm in quantum computing that in the future might halve the effective security, theoretically symmetric key lengths of 512 bits could be necessary.
> >>
> >> For long-term security, a security margin should be added that takes into account scientific progress (e.g., new attacks), technological progress (e.g., quantum computing, artificial intelligence), the interaction between both (possibly exponentially increasing scientific progress due to AI) as well as potential weaknesses in the original algorithm.
> >>
> >> Considering that secret (nation-state) quantum attacks may already happen in 2029 [7, 8], for a pragmatic ad-hoc hybrid solution focusing on asymmetric methods might be sufficient (German BSI: "it is advisable to use a key length of 256 bits for the symmetric encryption methods" [9]).
> >>
> >> For developing new algorithms, however, 512-bit keys should be envisioned for the symmetric encryption methods.
> >>
> >> The historical analogy lies in the NSA and Curve 25519.
> >> The NSA in 2005 decided to internally use 256 bits of security for long-term security [10] (e.g., Curve P-521 [11]).
> >> In my opinion, this was the correct decision, and a wise decision.
> >>
> >> While Curve 25519 has done a good job, I always regretted it only offered 128 bits of security.
> >> This level of 128 bits of security was deprecated by the NSA more than a decade ago [12].
> >>
> >> One should keep in mind that long-term security means more than holding a few decades.
> >> The pediatric records of a seven-year-old child shouldn't be available on the internet if the person is 37, 47, or 57 years old, with full name, birthday, maybe even place of birth (which would allow identity theft), but also diagnoses that may still be relevant then.
> >>
> >>
> >> Kind regards,
> >>
> >> Ken Kubota
> >>
> >> ____________________________________________________
> >>
> >> Ken Kubota
> >> https://doi.org/10.4444/100
> >>
> >>
> >>
> >> [1] https://mailarchive.ietf.org/arch/msg/tls/QusthRp6zRAxCvImiLLQ0SQLtME/
> >>
> >> [2] https://mailarchive.ietf.org/arch/msg/ssh/HGT2mTKC7vi9lHPdpBtQEwt57SQ/
> >>
> >> [3] https://www.anthropic.com/research/discovering-cryptographic-weaknesses
> >>
> >> [4] https://anthropic.com/document/aes_mobius_bridge.pdf
> >>
> >> [5] https://anthropic.com/document/aes_mobius_bridge_cot.pdf
> >>
> >> [6] https://youtu.be/tbjsagsiWls?t=2582
> >>
> >> [7] https://cr.yp.to/talks/2023.06.15/slides-djb-20230615-pqrisk-4x3.pdf, p. 6
> >>
> >> [8] https://youtu.be/qPhoJQtvgUo?t=740
> >>
> >> [9] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=14, p. 40
> >> "The development of fault-tolerant quantum computers has a much less severe impact on the
> >> security of symmetric mechanisms than on the security of asymmetric mechanisms. The use of
> >> Grover’s algorithm [61] could theoretically accelerate the search of the key space of symmetric
> >> mechanisms quadratically. Whether an acceleration compared to a classic exhaustive search of the
> >> key space can also be achieved in practice is the subject of current research, see e.g. [76]. Never-
> >> theless, especially for applications with high or long-term protection requirements or long-living
> >> systems it is advisable to use a key length of 256 bits for the symmetric encryption methods
> >> recommended below."
> >>
> >> [10] https://mailarchive.ietf.org/arch/msg/tls/lnSPh3Wr6vgdjivHGj1mxCun3Rs/
> >>
> >> [11] https://mailarchive.ietf.org/arch/msg/ssh/ONXLAO9CR9w6tUhwE3ag9CB14tE/
> >>
> >> [12] https://mailarchive.ietf.org/arch/msg/ssh/47mIx2MIjUYpn45EBysgmCHy5_4/
> >>
> >> _______________________________________________
> >> Ssh mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
> >
> > _______________________________________________
> > Ssh mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> 
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]