[TLS] Re: [External⚠️] [Ssh] Re: A new AI-discovered attack on 7-round AES (commentaries by Orr D unkelman and D. J. Bernstein)
Yaroslav Rosomakho <[email protected]> Wed, 29 Jul 2026 14:24:09 +0100
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <CAMtubr2ooV_WKLtX8KmY1oimZnqfV_y2jrT2y=Rh133AD5ThBw@mail.gmail.com> |
--===============4741132570891792241== Content-Type: multipart/alternative; boundary="0000000000008686960657bfdf9e" --0000000000008686960657bfdf9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ken, I am a bit confused by the choice of SSH and TLS WG mailing lists, as the concerns do not seem specific to SSH or TLS. Any vulnerabilities in AES would apply to a much wider range of IETF protocols and constructs, including (but not limited to) COSE, JOSE, IPSec, QUIC, LAKE, HPKE. Any particular reason you are focusing on SSH and TLS? Is this because conversations on these mailing lists tend to have more public resonance or is there a technical reason? If this is not a protocol-specific cryptography concern, perhaps CFRG would be a better discussion venue. -yaroslav On Wed, Jul 29, 2026 at 2:10=E2=80=AFPM Jan Schermer <[email protected]> wrot= e: > Isn't this a red herring? You completely missed the part where they > attacked HAWK (PQC finalist), _THAT_ is what illustrates the point. Nobod= y > cares about 7-round AES. > > Jan > > > > On 29. 7. 2026, at 14:58, Ken Kubota <[email protected]> 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 la= st > > decade, if you were not worried by the series of papers that reduced th= e > > 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 ha= d > previously succeeded at attacking reduced-round variants. But we should n= ot > assume that language model capabilities will plateau at this level. In ju= st > 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 woul= d > be prudent to consider how researchers should react if a language model > were to discover vulnerabilities in cryptosystems where attacks do have a= n > 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 anoth= er > half a year 100 papers, etc., in other words, a qualitatively _new > paradigm_ of scientific progress, which is not addressed by focusing on t= he > 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 o= f > > every last bit of performance to strip cryptography down to the bare > > minimum that resists attack demos. It's much safer to include defense i= n > > depth: for example, 256-bit cipher keys, many more cipher rounds than w= e > > 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 u= se > 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), b= ut > 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=3D2582 > > > > [7] https://cr.yp.to/talks/2023.06.15/slides-djb-20230615-pqrisk-4x3.pd= f, > p. 6 > > > > [8] https://youtu.be/qPhoJQtvgUo?t=3D740 > > > > [9] > https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuid= elines/TG02102/BSI-TR-02102-1.pdf?__blob=3DpublicationFile&v=3D14, > 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=E2=80=99s algorithm [61] could theoretically accelerate the sear= ch 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 -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > Ssh mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --=20 This communication (including any attachments) is intended for the sole=20 use=C2=A0of the intended recipient and may contain confidential, non-public= ,=20 and/or=C2=A0privileged material. Use, distribution, or reproduction of this= =C2=A0 communication by unintended recipients is not authorized. If you received= =C2=A0 this communication in error, please immediately notify the sender and then= =C2=A0 delete all copies of this communication from your system. --0000000000008686960657bfdf9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Ken,<div><br></div><div>I am a bit confused by the choi= ce of SSH and TLS WG mailing lists, as the concerns do not seem specific to= SSH or TLS. Any vulnerabilities in AES would apply to a much wider range o= f IETF protocols and constructs, including (but not limited to) COSE, JOSE,= IPSec, QUIC, LAKE, HPKE. Any particular reason you are focusing on SSH and= TLS? Is this because conversations on these mailing lists tend to have mor= e public resonance or is there a technical=C2=A0reason?<div><br></div><div>= If this is not a protocol-specific cryptography concern, perhaps CFRG would= be a better discussion venue.</div></div><div><br></div><div>-yaroslav</di= v></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"lt= r" class=3D"gmail_attr">On Wed, Jul 29, 2026 at 2:10=E2=80=AFPM Jan Scherme= r <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<br>= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex">Isn't this a re= d herring? You completely missed the part where they attacked HAWK (PQC fin= alist), _THAT_ is what illustrates the point. Nobody cares about 7-round AE= S.<br> <br> Jan<br> <br> <br> > On 29. 7. 2026, at 14:58, Ken Kubota <<a href=3D"mailto:ietf@kenkub= ota.de" target=3D"_blank">[email protected]</a>> wrote:<br> > <br> > On both Orr Dunkelman's [1] (TLS list) and D. J. Bernstein's c= ommentary [2] (SSH list) regarding the new AI-generated attack on 7-round A= ES [3, 4, 5]:<br> > <br> > <br> > "While this is the first improvement in attacking 7-round AES in = the last<br> > decade, if you were not worried by the series of papers that reduced t= he<br> > security of 5-round AES from 2^32 to 2^16, or the somewhat improved at= tacks<br> > on 6-round AES, then you should not really worry now [t]o start a proc= edure<br> > for changing 10-round AES (for 128-bit key) for something else, when t= here<br> > are no attacks on 8-round AES-128." [1]<br> > <br> > This overlooks the very point that Anthropic researchers emphasize the= mselves:<br> > <br> > "And in the case of AES, our attack extends a long line of work t= hat had previously succeeded at attacking reduced-round variants. But we sh= ould 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 fl= aws in cryptographic designs that have escaped discovery despite years of h= uman expert review." [3]<br> > "But as we develop increasingly powerful cryptanalytic results, i= t would be prudent to consider how researchers should react if a language m= odel were to discover vulnerabilities in cryptosystems where attacks do hav= e an immediate real-world impact." [3]<br> > <br> > 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.<br> > While this is probably the first such groundbreaking research result c= reated 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.<br> > <br> > Brian Berletic predicted AI development with _exponentially_ growing s= peed already about half a year ago:<br> > <br> > "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 bo= unds month to month even sometimes week to week." [6]<br> > <br> > <br> > "Given this risk, it's particularly dangerous if we allow the= pursuit of<br> > every last bit of performance to strip cryptography down to the bare<b= r> > minimum that resists attack demos. It's much safer to include defe= nse in<br> > depth: for example, 256-bit cipher keys, many more cipher rounds than = we<br> > know how to break (the classic recommendation from Anderson, Biham, an= d<br> > Knudsen is twice as many rounds), and continuing to sign with ECC when= <br> > we add PQ signatures." [2]<br> > <br> > While<br> > - twice as many rounds<br> > - hybrid approach (e.g., double encryption)<br> > are obvious conclusions,<br> > "256-bit cipher keys" should be replaced by "256 bits o= f security" for long-term security.<br> > <br> > With Grover's algorithm in quantum computing that in the future mi= ght halve the effective security, theoretically symmetric key lengths of 51= 2 bits could be necessary.<br> > <br> > For long-term security, a security margin should be added that takes i= nto account scientific progress (e.g., new attacks), technological progress= (e.g., quantum computing, artificial intelligence), the interaction betwee= n both (possibly exponentially increasing scientific progress due to AI) as= well as potential weaknesses in the original algorithm.<br> > <br> > Considering that secret (nation-state) quantum attacks may already hap= pen in 2029 [7, 8], for a pragmatic ad-hoc hybrid solution focusing on asym= metric methods might be sufficient (German BSI: "it is advisable to us= e a key length of 256 bits for the symmetric encryption methods" [9]).= <br> > <br> > For developing new algorithms, however, 512-bit keys should be envisio= ned for the symmetric encryption methods.<br> > <br> > The historical analogy lies in the NSA and Curve 25519.<br> > The NSA in 2005 decided to internally use 256 bits of security for lon= g-term security [10] (e.g., Curve P-521 [11]).<br> > In my opinion, this was the correct decision, and a wise decision.<br> > <br> > While Curve 25519 has done a good job, I always regretted it only offe= red 128 bits of security.<br> > This level of 128 bits of security was deprecated by the NSA more than= a decade ago [12].<br> > <br> > One should keep in mind that long-term security means more than holdin= g a few decades.<br> > The pediatric records of a seven-year-old child shouldn't be avail= able on the internet if the person is 37, 47, or 57 years old, with full na= me, birthday, maybe even place of birth (which would allow identity theft),= but also diagnoses that may still be relevant then.<br> > <br> > <br> > Kind regards,<br> > <br> > Ken Kubota<br> > <br> > ____________________________________________________<br> > <br> > Ken Kubota<br> > <a href=3D"https://doi.org/10.4444/100" rel=3D"noreferrer" target=3D"_= blank">https://doi.org/10.4444/100</a><br> > <br> > <br> > <br> > [1] <a href=3D"https://mailarchive.ietf.org/arch/msg/tls/QusthRp6zRAxC= vImiLLQ0SQLtME/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.i= etf.org/arch/msg/tls/QusthRp6zRAxCvImiLLQ0SQLtME/</a><br> > <br> > [2] <a href=3D"https://mailarchive.ietf.org/arch/msg/ssh/HGT2mTKC7vi9l= HPdpBtQEwt57SQ/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.i= etf.org/arch/msg/ssh/HGT2mTKC7vi9lHPdpBtQEwt57SQ/</a><br> > <br> > [3] <a href=3D"https://www.anthropic.com/research/discovering-cryptogr= aphic-weaknesses" rel=3D"noreferrer" target=3D"_blank">https://www.anthropi= c.com/research/discovering-cryptographic-weaknesses</a><br> > <br> > [4] <a href=3D"https://anthropic.com/document/aes_mobius_bridge.pdf" r= el=3D"noreferrer" target=3D"_blank">https://anthropic.com/document/aes_mobi= us_bridge.pdf</a><br> > <br> > [5] <a href=3D"https://anthropic.com/document/aes_mobius_bridge_cot.pd= f" rel=3D"noreferrer" target=3D"_blank">https://anthropic.com/document/aes_= mobius_bridge_cot.pdf</a><br> > <br> > [6] <a href=3D"https://youtu.be/tbjsagsiWls?t=3D2582" rel=3D"noreferre= r" target=3D"_blank">https://youtu.be/tbjsagsiWls?t=3D2582</a><br> > <br> > [7] <a href=3D"https://cr.yp.to/talks/2023.06.15/slides-djb-20230615-p= qrisk-4x3.pdf" rel=3D"noreferrer" target=3D"_blank">https://cr.yp.to/talks/= 2023.06.15/slides-djb-20230615-pqrisk-4x3.pdf</a>, p. 6<br> > <br> > [8] <a href=3D"https://youtu.be/qPhoJQtvgUo?t=3D740" rel=3D"noreferrer= " target=3D"_blank">https://youtu.be/qPhoJQtvgUo?t=3D740</a><br> > <br> > [9] <a href=3D"https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Pub= lications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=3DpublicationFil= e&v=3D14" rel=3D"noreferrer" target=3D"_blank">https://www.bsi.bund.de/= SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-0210= 2-1.pdf?__blob=3DpublicationFile&v=3D14</a>, p. 40<br> > "The development of fault-tolerant quantum computers has a much l= ess severe impact on the<br> > security of symmetric mechanisms than on the security of asymmetric me= chanisms. The use of<br> > Grover=E2=80=99s algorithm [61] could theoretically accelerate the sea= rch of the key space of symmetric<br> > mechanisms quadratically. Whether an acceleration compared to a classi= c exhaustive search of the<br> > key space can also be achieved in practice is the subject of current r= esearch, see e.g. [76]. Never-<br> > theless, especially for applications with high or long-term protection= requirements or long-living<br> > systems it is advisable to use a key length of 256 bits for the symmet= ric encryption methods<br> > recommended below."<br> > <br> > [10] <a href=3D"https://mailarchive.ietf.org/arch/msg/tls/lnSPh3Wr6vgd= jivHGj1mxCun3Rs/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.= ietf.org/arch/msg/tls/lnSPh3Wr6vgdjivHGj1mxCun3Rs/</a><br> > <br> > [11] <a href=3D"https://mailarchive.ietf.org/arch/msg/ssh/ONXLAO9CR9w6= tUhwE3ag9CB14tE/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.= ietf.org/arch/msg/ssh/ONXLAO9CR9w6tUhwE3ag9CB14tE/</a><br> > <br> > [12] <a href=3D"https://mailarchive.ietf.org/arch/msg/ssh/47mIx2MIjUYp= n45EBysgmCHy5_4/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.= ietf.org/arch/msg/ssh/47mIx2MIjUYpn45EBysgmCHy5_4/</a><br> > <br> > _______________________________________________<br> > Ssh mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a><br> > To unsubscribe send an email to <a href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a><br> <br> _______________________________________________<br> Ssh mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">ssh@i= etf.org</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" targe= t=3D"_blank">[email protected]</a><br> </blockquote></div> <br> <div><span style=3D"color:rgb(69,84,100);font-family:SourceSansPro,"He= lvetica Neue",Helvetica,Arial,sans-serif;font-size:12px"><br></span></= div><span style=3D"color:rgb(69,84,100);font-family:SourceSansPro,"Hel= vetica Neue",Helvetica,Arial,sans-serif;font-size:12px">This communica= tion (including any attachments) is intended for the sole use=C2=A0</span><= span style=3D"color:rgb(69,84,100);font-family:SourceSansPro,"Helvetic= a Neue",Helvetica,Arial,sans-serif;font-size:12px">of the intended rec= ipient and may contain confidential, non-public, and/or=C2=A0</span><span s= tyle=3D"color:rgb(69,84,100);font-family:SourceSansPro,"Helvetica Neue= ",Helvetica,Arial,sans-serif;font-size:12px">privileged material. Use,= distribution, or reproduction of this=C2=A0</span><span style=3D"color:rgb= (69,84,100);font-family:SourceSansPro,"Helvetica Neue",Helvetica,= Arial,sans-serif;font-size:12px">communication by unintended recipients is = not authorized. If you received=C2=A0</span><span style=3D"color:rgb(69,84,= 100);font-family:SourceSansPro,"Helvetica Neue",Helvetica,Arial,s= ans-serif;font-size:12px">this communication in error, please immediately n= otify the sender and then=C2=A0</span><span style=3D"color:rgb(69,84,100);f= ont-family:SourceSansPro,"Helvetica Neue",Helvetica,Arial,sans-se= rif;font-size:12px">delete all copies of this communication from your syste= m.</span> --0000000000008686960657bfdf9e-- --===============4741132570891792241== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============4741132570891792241==--