[TLS] Re: Aes cipher
John Mattsson <[email protected]> Wed, 29 Jul 2026 09:08:19 +0000
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <AS4PR07MB8825ADD5D8775005A8F6E61489CA2@AS4PR07MB8825.eurprd07.prod.outlook.com> |
--===============7931523986920753124== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_AS4PR07MB8825ADD5D8775005A8F6E61489CA2AS4PR07MB8825eurp_" --_000_AS4PR07MB8825ADD5D8775005A8F6E61489CA2AS4PR07MB8825eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Loganaden, I think there is a significant difference between non-standardized asymmetr= ic cryptography based on new hardness assumptions such as LIP and widely-de= ployed standardized symmetric cryptography. So far, AI has broken HAWK, but= that is not more impressive than the human attacks on SIKE, Rainbow, and t= he Hedge attacks on multivariate quadratic (MQ) schemes, etc. Of course, th= is could change in the future as AI capabilities improve. For encryption, TLS 1.3 already supports AES- and ChaCha20-based cipher sui= tes, which rely on quite different constructions. The main concern with TLS= 1.3 is that it (ignoring regional algorithms) relies entirely on SHA-2 for= its key schedule. This will hopefully be addressed by standardizing a way = for TLS 1.3 to use a Keccak-based deck function instead of SHA-2/HMAC/HKDF.= I think this should be a priority. In the future I also think that Keccak = based cipher suites should be added. For key exchange, the only standardized quantum-resistant algorithm current= ly available is ML-KEM. I think TLS 1.3 should standardize support for HQC-= KEM as soon as possible, but this will need to wait until the publication o= f FIPS 207. Other structured lattice algorithms like NTRU, NTRU+, NTRU Prim= e, Saber, Dawn, Bat does not add much diversity, but Dawn/Bat could be usef= ul as more lightweight algorithms. Cheers, John Preu=DF Mattsson From: Loganaden Velvindron <[email protected]> Date: Wednesday, 29 July 2026 at 10:42 To: <[email protected]> Subject: [TLS] Aes cipher After reading https://www.anthropic.com/research/discovering-cryptographic-= weaknesses, I would like to know whether we should look at having more diversity for tl= s 1.3 ciphers ? --_000_AS4PR07MB8825ADD5D8775005A8F6E61489CA2AS4PR07MB8825eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> </head> <body> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> Hi Loganaden,</div> <p class=3D"isSelectedEnd" style=3D"direction: ltr; text-align: left; text-= indent: 0px; text-transform: none;"> <span style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size:= 12pt; color: rgb(0, 0, 0);">I think there is a significant difference betw= een non-standardized asymmetric cryptography based on new hardness assumpti= ons such as LIP and widely-deployed standardized symmetric cryptography. So far, AI has broken HAWK, but that = is not more impressive than the human attacks on SIKE, Rainbow, and the Hed= ge attacks on multivariate quadratic (MQ) schemes, etc. Of course, this cou= ld change in the future as AI capabilities improve.</span></p> <p class=3D"isSelectedEnd" style=3D"text-align: left; text-indent: 0px;"><s= pan style=3D"font-size: 16px;">For encryption, TLS 1.3 already supports AES= - and ChaCha20-based cipher suites, which rely on quite different construct= ions. The main concern with TLS 1.3 is that it (ignoring regional algorithms) relies entirely on SHA-2 for its ke= y schedule. This will hopefully be addressed by standardizing a way for TLS= 1.3 to use a Keccak-based deck function instead of SHA-2/HMAC/HKDF. I thin= k this should be a priority. In the future I also </span>think<span style=3D"font-size: 16px;"> that = Keccak based cipher suites should be added.</span></p> <p class=3D"isSelectedEnd" style=3D"text-align: left; text-indent: 0px;"><s= pan style=3D"font-size: 16px;">For key exchange, the only standardized quan= tum-resistant algorithm currently available is ML-KEM. I think TLS 1.3 shou= ld standardize support for HQC-KEM as soon as possible, but this will need to wait until the publication of FIPS= 207. Other structured lattice algorithms like NTRU, NTRU+, NTRU Prime, Sab= er, </span>Dawn, Bat does not add much diversity, but Dawn/Bat could be us= eful as more lightweight algorithms.</p> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> Cheers,</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> John Preu=DF Mattsson</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style=3D"padding: 3pt 0in 0in; border-width: 1pt medium medium; border= -style: solid none none; border-color: rgb(181, 196, 223) currentcolor curr= entcolor;"> <div style=3D"text-align: left; font-family: Aptos; font-size: 12pt; color:= black;"> <b>From: </b>Loganaden Velvindron <[email protected]><br> <b>Date: </b>Wednesday, 29 July 2026 at 10:42<br> <b>To: </b> <[email protected]> <div style=3D"text-align: left;"><[email protected]><br> <b>Subject: </b>[TLS] Aes cipher<br> <br> </div> </[email protected]></div> </div> <div id=3D"mail-editor-reference-message-container"> <div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"di= rection: ltr;"> After reading <a href=3D"https://www.anthropic.com/research/discovering-cry= ptographic-weaknesses" rel=3D"noreferrer" data-outlook-id=3D"c233e364-d09a-= 49e1-a33b-550359236fb7"> https://www.anthropic.com/research/discovering-cryptographic-weaknesses</a>= , </div> <div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"di= rection: ltr;"> <br> </div> <div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"di= rection: ltr;"> I would like to know whether we should look at having more diversity for tl= s 1.3 ciphers ?</div> <div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"di= rection: ltr;"> <br> </div> <div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"di= rection: ltr;"> <br> </div> </div> </body> </html> --_000_AS4PR07MB8825ADD5D8775005A8F6E61489CA2AS4PR07MB8825eurp_-- --===============7931523986920753124== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============7931523986920753124==--