[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt
Joan Daemen <[email protected]> Mon, 27 Jul 2026 11:47:00 +0200
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============3144322560876444796== Content-Type: multipart/alternative; boundary="------------ZfGU1IUK1WpDw0E0eMgkfeJw" Content-Language: en-US This is a multi-part message in MIME format. --------------ZfGU1IUK1WpDw0E0eMgkfeJw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear John et al., Thanks for your mail. Op 24-07-2026 om 21:44 schreef John Mattsson: > Nick Sullivan wrote: > >On the AEAD: I agree it is worth having, and it is a follow-on rather > than part of this document, which is about the key schedule. Perhaps > bringing the AEAD itself to CFRG is a route forward. > > I would support such work in CFRG. The lack of a standardized > Keccak-based AEAD is, in my view, a major gap in the cryptographic > portfolio. Keccak has been standardized for hash functions, XOFs, > MACs, KDFs, DRBGs, KEMs, and signatures, but not for encryption. A > TurboSHAKE-based AEAD could offer excellent performance and strong > security while providing significant practical value by enabling a > single cryptographic primitive to support all major cryptographic > functions. > > In my view, two things would be particularly valuable: > > 1. A fast TurboSHAKE-based AEAD, such as the construction described > in: https://eprint.iacr.org/2024/1618.pdf We are actually working on FlightDeck, a parallelizable variant of Upperdeck defined in https://eprint.iacr.org/2024/1618.pdf <https://eprint.iacr.org/2024/1618.pdf>to get a performance similar to that of KangarooTwelve, and also security-reducible to (Turbo)SHAKE128/256. We hope to come out with that in the coming weeks/months. > > 2. A TurboSHAKE-based Accordion for use with the Accordion-derived > functions NIST is planning to standardize. > https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8552.pdf In our paper "Jammin' on the deck" https://eprint.iacr.org/2022/531 we defined a mode called JAMBOREE that builds a wide tweakable block cipher on top of a deck function. Instantiating that on top of Flightdeck on top of TurboSHAKE would to exactly that. Kind regards, Joan and Gilles on behalf of the Keccak team > > Cheers, > John Preuß Mattsson > > *From: *Nick Sullivan <[email protected]> > *Date: *Friday, 24 July 2026 at 15:34 > *To: *Joan Daemen <[email protected]> > *Cc: *[email protected] <[email protected]>; Keccak Team <[email protected]>; > Mella, S. (Silvia) <[email protected]> > *Subject: *[TLS] Re: New Version Notification for > draft-sullivan-tls-xof-ciphers-00.txt > > Joan and the Keccak team, > > Thank you for the review. Both of your suggestions were more useful > than a first read of my reply might suggest, and I want to be clear > that neither is closed. > > On overwrite-duplex for the derivation: I have not taken it into this > revision, but that is a statement about what I have been able to work > out so far, not a judgement on the idea. Two things stopped me. The > recursion in Lemma 2 appears to break the One-Shot Equivalence the > design relies on, and the construction needs raw Keccak-p, which > common libraries do not expose, plus a |K| <= rho bound on the input. > I would rather have your reading than my own here: if the equivalence > can be recovered, or if the bound is looser than I have assumed, I > would like to see it. On your ground, so I expect I am the one who is > wrong, and I may well be leaving performance on the table. What I > would most value is your view on whether a duplex derivation is > feasible here at all, and what it would look like. > > On the round count: the draft offers both 12-round TurboSHAKE256 and > 24-round SHAKE256 and deliberately leaves the choice open, with > neither named as the default. You called 12 rounds a comfortable > margin. Would you frame the margin any differently for this use: an > unkeyed sponge, injective framing, indifferentiable up to 2^256? > > On the AEAD: I agree it is worth having, and it is a follow-on rather > than part of this document, which is about the key schedule. Perhaps > bringing the AEAD itself to CFRG is a route forward. > > Thanks for taking the time to review my rough -00 draft. Hopefully the > new draft is closer to a feasible secure design. > > Nick > > On Tue, Jul 14, 2026 at 1:09 PM Joan Daemen > <[email protected]> wrote: > > Dear all, > > We are enthusiastic about Nick Sullivan's announcement of his RFC > draft for a TLS 1.3 key schedule based on Keccak and happy with > the many reactions on the mailing list, so we thought it would be > good to give you our 2 cents. > > # Including a Keccak-based AEAD option > > In Table 1, the draft proposes AES-GCM and ChaCha20-Poly1305 as > AEAD schemes, but no Keccak-based scheme. As suggested by other > participants, it would be nice to also offer the option of a > Keccak-based AEAD scheme. This would allow one to potentially > reduce the code size (or area) and trust surface even further. > > We did the exercise recently in our paper "Shaking up > authenticated encryption" presented at EuroS&P > (https://eprint.iacr.org/2024/1618). It defines two fully > committing AEAD schemes, both with security provably reducible to > (Turbo)SHAKE128/256. > > > # Instantiating the key derivation > > The EuroS&P paper also defines a duplex object and a deck > function, both also reducing to the security of > (Turbo)SHAKE128/256. Thanks to this reduction, the former could be > used as primitives in the key derivation, solving much of the > domain separation. The use of "trailer" bytes that accumulate all > domain separation bits the final functions are very simple to > implement. Moreover, by overwriting input blocks (instead of > XORing them in), they have a nice property that each call to the > underlying permutation can be a ratchet: the only requirement is > that at least 128/256 bits of the output shall not be returned. > > > # Kravatte vs (Turbo)SHAKE > > Kravatte is a very fast primitive that could be used for AEAD. > However, it needs a secret key upon initialization and is > therefore not suited for key derivation. > > Kravatte is a deck function obtained by applying the Farfalle > construction with Keccak-p[6 rounds] and two rolling functions. It > is **not** built on top of Keccak and therefore it security cannot > be reduced to that of (Turbo)SHAKE. Actually, its security cannot > be reduced to a simpler primitive, so the security of Kravatte > must be established by the cryptanalysis of Kravatte itself. > > > # On the number of rounds > > MarsupilamiFourteen (M14) was given as an example of a function > calling Keccak-p with a number of rounds that is not a multiple of 6. > > M14 dates back from 2018 as a 256-bit version of (now called) > KT128. The reasoning for adding two rounds was to allow for extra > safety margin while giving more budget to the adversary. Since > then, we have seen the number of rounds that can be attacked under > cryptanalysis slow down, and now we think that 12 rounds provides > a comfortable safety margin for Keccak, even when targeting > 256-bit security with a capacity of 512 bits. So, RFC 9861 > proposes TurboSHAKE256 and KT256 on top of Keccak-p[12 rounds] and > not 14 rounds. > > Note by Joan: I answered Markku indeed that I could not think of > any proposal where the round count would not be a multiple of 6, > thereby dismissing MarsipulamiFourteen but also our CAESAR AEAD > candidate Ketje that does single-round calls in the encryption > phase. My mindset was that both were proposals for which we think > we have more interesting alternatives. > > > Kind regards, > > The Keccak team > Guido Bertoni, Joan Daemen, Seth Hoffert, Silvia Mella, Michaël > Peeters, Gilles Van Assche and Ronny Van Keer > > Op 08-07-2026 om 18:01 schreef Nick Sullivan: > > Hi Hannes, > > As Thom noted below in the chain, the motivation is to > modernize the key schedule, which has two main advantages: > > 1. Efficiency gains: As the analysis on-list spells out, it’s > a dramatic improvement to the number of hashes/permutations > needed. But as you noted, is not the hot path at all. > 2. Removing a hard dependency on SHA-2 from future designs, as > Thom noted. This gain isn’t immediate, but it clears the way > for future configurations that don’t rely on SHA-2 for the > CertificateVerify to drop SHA-2 completely from the code base. > > Nick > > On Wed, Jul 8, 2026 at 3:58 PM Thom Wiggers > <[email protected]> wrote: > > Hi Hannes, > > I don’t think runtime performance is an issue, but rather > code size (or area), by getting rid of SHA2. (Of course, > this is long into the future). The sponge-based > constructions also have theoretical benefits. > > Cheers, > > Thom > > > Op 8 jul 2026, om 13:47 heeft Hannes Tschofenig > <[email protected]> het > volgende geschreven: > > Hi Markku, Hi Nick! > > I will certainly look closer into the details but it > appears that you are optimizing TLS in the wrong > place. The key derivation is the least expensive part > in TLS and spending time optimizing it will bring > little benefit. I am saying this because I have for > years been looking at optimizing different parts of > the TLS protocol with constrained IoT in mind. > > This brings me to the core question: What is the > problem you are trying to solve in the first place? I > do not recall that anyone has voiced performance > problems with the key derivation in TLS before this > draft was published. > > Ciao > Hannes > > > Am 08.07.2026 um 12:16 schrieb Markku-Juhani O. Saarinen: > > Hi, > > Thanks for this. I quickly put together an > implementation of > draft-sullivan-tls-xof-ciphers-00.txt around > Rustls to do some measurements: > > https://github.com/mjosaarinen/altkdf-rs > > ( Editorial comments in > https://github.com/mjosaarinen/altkdf-rs/blob/main/FINDINGS.md ) > > The theoretical side of the design seems very > defensible -- clean proof target. In terms of > concrete security, the Keccak variants have a much > larger security margin than the SHA-2 family. > > Given how much work we put into reducing the > number of permutation calls with ML-KEM and Hybrid > combiners -- carefully debating and analyzing each > permutation -- this one yields a staggering > reduction, making the key schedule much faster > (and the handshake probably too.) > > For the representative full handshake: PSK + > (EC)DHE + 0-RTT leaves + NewSessionTicket + one > KeyUpdate each direction + one exporter, the > per-endpoint counts over 24-round Keccak-f[1600] are: > > 41 * f1600: Deck implementation, measured stateful > 46 * f1600: Deck implementation, measured recompute > 52 * f1600: Section A.1 in > draft-sullivan-tls-xof-ciphers-00 > 156 * f1600: HKDF-SHA3-256 / RFC 8446 baseline > 117 * f1600: Appendix D "FIPS" KMAC256 schedule > > So 41 vs 156 permutations by my count. > > ( Note: The draft slightly overcounts permutations > in its estimates. ) > > It's a quick prototype built with extensive AI > assistance, but it includes basic correctness > measures: primitive KATs (RFC 9861 TurboSHAKE256, > FIPS 202 SHAKE256, SP 800-185 KMAC256, including > multi-block and long-output), 73 self-generated > Appendix C/D vectors, and byte-for-byte > reproduction of all of them by an independent > Python implementation written from the draft alone. > > - Keccak-p[1600,nr] permutation and the > rate-136/capacity-512 sponge > - Five framed deck operations > (Init/Absorb/Fork/Squeeze/Ratchet) > - KMAC-layout MAC > - Three-stage E/H/T schedule with its two ratchets > - Section 5 derivations (record keys, Finished/PSK > binders, exporters, resumption and key-update, and > the §10 external-PSK importer with > ImportedIdentityV2). > - All five cipher suites (0xFF01–0xFF05, both > profiles, three AEADs) > > Plus for comparisons: > > - Appendix D FIPS-component schedule (RFC 8446 > with KMAC256 as the PRF) > - a permutation-count benchmark reproducing §A.1, > live-secret zeroization (§15.7.2.2) > > Cheers, > -markku > > Dr. Markku-Juhani O. Saarinen <[email protected]> > > > On Tue, Jul 7, 2026 at 2:34 AM Nick Sullivan > <[email protected]> wrote: > > Dear TLS, > > I'm sharing a draft for the group's consideration. > draft-sullivan-tls-xof-ciphers-00 runs the > entire TLS 1.3 key schedule > on a single Keccak permutation, instead of > HKDF built on HMAC built on > the cipher suite's hash, which today is always > SHA-2. This is newly > practical because deployments using SHA-3, > ML-KEM, or ML-DSA already > carry a Keccak permutation, so the primitive > is already in the stack. > > Each derived value comes out in one pass, so a > full handshake costs > about a third of the permutation calls an HKDF > schedule over the same > permutation would spend. > > A cipher suite names an AEAD plus a schedule > profile, and nothing else > changes. There is no new extension, and the > state machine, record > layer, and wire format are untouched. Two > profiles are defined, one on > the standard SHA-3 function and one on a > faster reduced-round variant. > Test vectors are pinned to cipher-suite > values, so the final vectors > will follow the code point assignment. > > https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/ > > This is a big change to the key schedule, and > the draft is very > preliminary. Feedback on the approach, or > interest in implementing it, > would help a lot. > > Best, > Nick > > On Mon, Jul 6, 2026 at 7:03 PM > <[email protected]> wrote: > > > > A new version of Internet-Draft > draft-sullivan-tls-xof-ciphers-00.txt has been > > successfully submitted by Nick Sullivan and > posted to the > > IETF repository. > > > > Name: draft-sullivan-tls-xof-ciphers > > Revision: 00 > > Title: TLS 1.3 Cipher Suites with > Alternative Key-Schedule Profiles > > Date: 2026-07-06 > > Group: Individual Submission > > Pages: 46 > > URL: > https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/ > > HTML: > https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.html > > HTMLized: > https://datatracker.ietf.org/doc/html/draft-sullivan-tls-xof-ciphers > > > > > > Abstract: > > > > TLS 1.3 builds its key schedule on HKDF > over the cipher suite's hash. > > This document defines TLS 1.3 cipher > suites that build it on a deck > > function over a single permutation > instead, the one a deployment > > already carries when it uses SHA-3, > ML-KEM, or ML-DSA. One > > permutation then runs the whole schedule, > and a full handshake takes > > about a third of the permutation calls an > HKDF schedule over that > > permutation would. Such a cipher suite > names an AEAD algorithm > > together with a schedule profile that > defines every key-schedule > > function the connection uses. The > profile follows from the > > negotiated cipher suite alone, so no new > extension is defined and the > > TLS 1.3 state machine and wire format are > unchanged. Two profiles > > are defined, one on the standard SHA-3 > function and one on a faster > > reduced-round variant of it. > > > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > TLS mailing list -- [email protected] To unsubscribe > send an email to [email protected] > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > > _______________________________________________ TLS mailing > list -- [email protected] To unsubscribe send an email to > [email protected] > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > _______________________________________________ > TLS mailing list [email protected] > To unsubscribe send an email [email protected] --------------ZfGU1IUK1WpDw0E0eMgkfeJw Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <p>Dear John et al.,</p> <p>Thanks for your mail.</p> <div class="moz-cite-prefix">Op 24-07-2026 om 21:44 schreef John Mattsson:<br> </div> <blockquote type="cite" cite="mid:AS4PR07MB8825CDDF1BEE6E4E3A55350F89CF2@AS4PR07MB8825.eurprd07.prod.outlook.com"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <div style="direction: ltr; font-family: Aptos; font-size: 12pt; color: black;">Nick Sullivan wrote:</div> <div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> >On the AEAD: I agree it is worth having, and it is a follow-on rather than part of this document, which is about the key schedule. Perhaps bringing the AEAD itself to CFRG is a route forward.</div> <div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> I would support such work in CFRG. The lack of a standardized Keccak-based AEAD is, in my view, a major gap in the cryptographic portfolio. Keccak has been standardized for hash functions, XOFs, MACs, KDFs, DRBGs, KEMs, and signatures, but not for encryption. A TurboSHAKE-based AEAD could offer excellent performance and strong security while providing significant practical value by enabling a single cryptographic primitive to support all major cryptographic functions.</div> <div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> In my view, two things would be particularly valuable:</div> <div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> 1. A fast TurboSHAKE-based AEAD, such as the construction described in: <a href="https://eprint.iacr.org/2024/1618.pdf" data-outlook-id="dc0f3570-0ea2-4e79-8cee-57f6e255fe3d" moz-do-not-send="true" class="moz-txt-link-freetext"> https://eprint.iacr.org/2024/1618.pdf</a></div> </blockquote> <p>We are actually working on FlightDeck, a parallelizable variant of Upperdeck defined in <a href="https://eprint.iacr.org/2024/1618.pdf" data-outlook-id="dc0f3570-0ea2-4e79-8cee-57f6e255fe3d"> https://eprint.iacr.org/2024/1618.pdf </a>to get a performance similar to that of KangarooTwelve, and also security-reducible to (Turbo)SHAKE128/256. We hope to come out with that in the coming weeks/months.</p> <blockquote type="cite" cite="mid:AS4PR07MB8825CDDF1BEE6E4E3A55350F89CF2@AS4PR07MB8825.eurprd07.prod.outlook.com"> <div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> 2. A TurboSHAKE-based Accordion for use with the Accordion-derived functions NIST is planning to standardize.</div> <div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <a href="https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8552.pdf" data-outlook-id="bb4bdcdb-6c6d-433b-800d-0e423cdf3314" moz-do-not-send="true" class="moz-txt-link-freetext">https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8552.pdf</a></div> </blockquote> <p>In our paper "Jammin' on the deck" <a class="moz-txt-link-freetext" href="https://eprint.iacr.org/2022/531">https://eprint.iacr.org/2022/531</a> we defined a mode called JAMBOREE that builds a wide tweakable block cipher on top of a deck function. Instantiating that on top of Flightdeck on top of TurboSHAKE would to exactly that.</p> <p>Kind regards,</p> <p>Joan and Gilles on behalf of the Keccak team</p> <blockquote type="cite" cite="mid:AS4PR07MB8825CDDF1BEE6E4E3A55350F89CF2@AS4PR07MB8825.eurprd07.prod.outlook.com"> <div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Cheers,</div> <div style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> John Preuß Mattsson</div> <div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div id="mail-editor-reference-message-container"> <div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr;"> </div> <div style="padding: 3pt 0in 0in; border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor;"> <div class="ms-outlook-mobile-reference-message skipProofing" style="text-align: left; font-family: Aptos; font-size: 12pt; color: black;"> <b>From: </b>Nick Sullivan <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Date: </b>Friday, 24 July 2026 at 15:34<br> <b>To: </b>Joan Daemen <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Cc: </b><a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>; Keccak Team <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>; Mella, S. (Silvia) <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a><br> <b>Subject: </b>[TLS] Re: New Version Notification for draft-sullivan-tls-xof-ciphers-00.txt<br> <br> </div> </div> <div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr;"> Joan and the Keccak team,<br> <br> Thank you for the review. Both of your suggestions were more useful than a first read of my reply might suggest, and I want to be clear that neither is closed.<br> <br> On overwrite-duplex for the derivation: I have not taken it into this revision, but that is a statement about what I have been able to work out so far, not a judgement on the idea. Two things stopped me. The recursion in Lemma 2 appears to break the One-Shot Equivalence the design relies on, and the construction needs raw Keccak-p, which common libraries do not expose, plus a |K| <= rho bound on the input. I would rather have your reading than my own here: if the equivalence can be recovered, or if the bound is looser than I have assumed, I would like to see it. On your ground, so I expect I am the one who is wrong, and I may well be leaving performance on the table. What I would most value is your view on whether a duplex derivation is feasible here at all, and what it would look like.<br> <br> On the round count: the draft offers both 12-round TurboSHAKE256 and 24-round SHAKE256 and deliberately leaves the choice open, with neither named as the default. You called 12 rounds a comfortable margin. Would you frame the margin any differently for this use: an unkeyed sponge, injective framing, indifferentiable up to 2^256?<br> <br> On the AEAD: I agree it is worth having, and it is a follow-on rather than part of this document, which is about the key schedule. Perhaps bringing the AEAD itself to CFRG is a route forward.<br> <br> Thanks for taking the time to review my rough -00 draft. Hopefully the new draft is closer to a feasible secure design.<br> <br> Nick</div> <div class="ms-outlook-mobile-reference-message skipProofing" style="direction: ltr;"> <br> </div> <div class="gmail_attr" style="direction: ltr;">On Tue, Jul 14, 2026 at 1:09 PM Joan Daemen <jda=<a href="mailto:[email protected]" data-outlook-id="0360390e-538f-464b-9cbe-46c7f804c11d" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:</div> <blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);"> <p class="gmail_quote">Dear all,<br> <br> We are enthusiastic about Nick Sullivan's announcement of his RFC draft for a TLS 1.3 key schedule based on Keccak and happy with the many reactions on the mailing list, so we thought it would be good to give you our 2 cents.<br> <br> # Including a Keccak-based AEAD option<br> <br> In Table 1, the draft proposes AES-GCM and ChaCha20-Poly1305 as AEAD schemes, but no Keccak-based scheme. As suggested by other participants, it would be nice to also offer the option of a Keccak-based AEAD scheme. This would allow one to potentially reduce the code size (or area) and trust surface even further.<br> <br> We did the exercise recently in our paper "Shaking up authenticated encryption" presented at EuroS&P (<a href="https://eprint.iacr.org/2024/1618" target="_blank" originalsrc="https://eprint.iacr.org/2024/1618" data-outlook-id="ff879923-1890-4a02-969b-bcf7cee9c988" style="margin-top: 0px; margin-bottom: 0px;" moz-do-not-send="true" class="moz-txt-link-freetext">https://eprint.iacr.org/2024/1618</a>). It defines two fully committing AEAD schemes, both with security provably reducible to (Turbo)SHAKE128/256.<br> <br> <br> # Instantiating the key derivation<br> <br> The EuroS&P paper also defines a duplex object and a deck function, both also reducing to the security of (Turbo)SHAKE128/256. Thanks to this reduction, the former could be used as primitives in the key derivation, solving much of the domain separation. The use of "trailer" bytes that accumulate all domain separation bits the final functions are very simple to implement. Moreover, by overwriting input blocks (instead of XORing them in), they have a nice property that each call to the underlying permutation can be a ratchet: the only requirement is that at least 128/256 bits of the output shall not be returned.<br> <br> <br> # Kravatte vs (Turbo)SHAKE<br> <br> Kravatte is a very fast primitive that could be used for AEAD. However, it needs a secret key upon initialization and is therefore not suited for key derivation.<br> <br> Kravatte is a deck function obtained by applying the Farfalle construction with Keccak-p[6 rounds] and two rolling functions. It is <b>*not*</b> built on top of Keccak and therefore it security cannot be reduced to that of (Turbo)SHAKE. Actually, its security cannot be reduced to a simpler primitive, so the security of Kravatte must be established by the cryptanalysis of Kravatte itself.<br> <br> <br> # On the number of rounds<br> <br> MarsupilamiFourteen (M14) was given as an example of a function calling Keccak-p with a number of rounds that is not a multiple of 6.<br> <br> M14 dates back from 2018 as a 256-bit version of (now called) KT128. The reasoning for adding two rounds was to allow for extra safety margin while giving more budget to the adversary. Since then, we have seen the number of rounds that can be attacked under cryptanalysis slow down, and now we think that 12 rounds provides a comfortable safety margin for Keccak, even when targeting 256-bit security with a capacity of 512 bits. So, RFC 9861 proposes TurboSHAKE256 and KT256 on top of Keccak-p[12 rounds] and not 14 rounds.<br> <br> Note by Joan: I answered Markku indeed that I could not think of any proposal where the round count would not be a multiple of 6, thereby dismissing MarsipulamiFourteen but also our CAESAR AEAD candidate Ketje that does single-round calls in the encryption phase. My mindset was that both were proposals for which we think we have more interesting alternatives.<br> <br> <br> Kind regards,<br> <br> The Keccak team<br> Guido Bertoni, Joan Daemen, Seth Hoffert, Silvia Mella, Michaël Peeters, Gilles Van Assche and Ronny Van Keer<br> <br> </p> <div class="gmail_quote">Op 08-07-2026 om 18:01 schreef Nick Sullivan:</div> <blockquote> <div class="gmail_quote" style="direction: ltr; text-indent: 0px; text-transform: none; font-family: -apple-system, sans-serif; color: rgb(0, 0, 0);"> Hi Hannes,</div> <div class="gmail_quote" style="direction: ltr; text-indent: 0px; text-transform: none; font-family: -apple-system, sans-serif; color: rgb(0, 0, 0);"> <br> </div> <div class="gmail_quote" style="direction: ltr; text-indent: 0px; text-transform: none; font-family: -apple-system, sans-serif; color: rgb(0, 0, 0);"> As Thom noted below in the chain, the motivation is to modernize the key schedule, which has two main advantages:</div> <div class="gmail_quote" style="direction: ltr; text-indent: 0px; text-transform: none; font-family: -apple-system, sans-serif; color: rgb(0, 0, 0);"> <br> </div> <div class="gmail_quote" style="direction: ltr; text-indent: 0px; text-transform: none; font-family: -apple-system, sans-serif; color: rgb(0, 0, 0);"> 1. Efficiency gains: As the analysis on-list spells out, it’s a dramatic improvement to the number of hashes/permutations needed. But as you noted, is not the hot path at all.</div> <div class="gmail_quote" style="direction: ltr; text-indent: 0px; text-transform: none; font-family: -apple-system, sans-serif; color: rgb(0, 0, 0);"> 2. Removing a hard dependency on SHA-2 from future designs, as Thom noted. This gain isn’t immediate, but it clears the way for future configurations that don’t rely on SHA-2 for the CertificateVerify to drop SHA-2 completely from the code base.</div> <div class="gmail_quote" style="direction: ltr; text-indent: 0px; text-transform: none; font-family: -apple-system, sans-serif; color: rgb(0, 0, 0);"> <br> </div> <div class="gmail_quote" style="direction: ltr; text-indent: 0px; text-transform: none; font-family: -apple-system, sans-serif; color: rgb(0, 0, 0);"> Nick</div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_attr" style="direction: ltr;">On Wed, Jul 8, 2026 at 3:58 PM Thom Wiggers <<a href="mailto:[email protected]" target="_blank" data-outlook-id="007fb886-7142-454c-b359-ba7ceafa3e15" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:</div> <blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);"> <div class="gmail_quote">Hi Hannes,</div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_quote">I don’t think runtime performance is an issue, but rather code size (or area), by getting rid of SHA2. (Of course, this is long into the future). The sponge-based constructions also have theoretical benefits.</div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_quote">Cheers,</div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_quote">Thom</div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <blockquote> <div class="gmail_quote">Op 8 jul 2026, om 13:47 heeft Hannes Tschofenig <hannes.tschofenig=<a href="mailto:[email protected]" target="_blank" data-outlook-id="bc8b9b79-13cf-449e-9999-41832d809752" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> het volgende geschreven:</div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <p class="gmail_quote">Hi Markku, Hi Nick!</p> <p class="gmail_quote">I will certainly look closer into the details but it appears that you are optimizing TLS in the wrong place. The key derivation is the least expensive part in TLS and spending time optimizing it will bring little benefit. I am saying this because I have for years been looking at optimizing different parts of the TLS protocol with constrained IoT in mind.</p> <p class="gmail_quote">This brings me to the core question: What is the problem you are trying to solve in the first place? I do not recall that anyone has voiced performance problems with the key derivation in TLS before this draft was published. </p> <p class="gmail_quote">Ciao<br> Hannes</p> <p class="gmail_quote"><br> </p> <div class="gmail_quote">Am 08.07.2026 um 12:16 schrieb Markku-Juhani O. Saarinen:</div> <blockquote> <div class="gmail_quote" style="direction: ltr;">Hi,<br> <br> Thanks for this. I quickly put together an implementation of draft-sullivan-tls-xof-ciphers-00.txt around Rustls to do some measurements: </div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_quote" style="direction: ltr;"><a href="https://github.com/mjosaarinen/altkdf-rs" target="_blank" originalsrc="https://github.com/mjosaarinen/altkdf-rs" data-outlook-id="279c250c-50dc-469a-87b6-04c3fb886188" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/mjosaarinen/altkdf-rs</a> </div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_quote" style="direction: ltr;">( Editorial comments in <a href="https://github.com/mjosaarinen/altkdf-rs/blob/main/FINDINGS.md" target="_blank" originalsrc="https://github.com/mjosaarinen/altkdf-rs/blob/main/FINDINGS.md" data-outlook-id="7f1211cd-9bd3-4d90-b806-d3baddd9eebb" moz-do-not-send="true" class="moz-txt-link-freetext"> https://github.com/mjosaarinen/altkdf-rs/blob/main/FINDINGS.md</a> )<br> <br> The theoretical side of the design seems very defensible -- clean proof target. In terms of concrete security, the Keccak variants have a much larger security margin than the SHA-2 family.<br> <br> Given how much work we put into reducing the number of permutation calls with ML-KEM and Hybrid combiners -- carefully debating and analyzing each permutation -- this one yields a staggering reduction, making the key schedule much faster (and the handshake probably too.)<br> <br> For the representative full handshake: PSK + (EC)DHE + 0-RTT leaves + NewSessionTicket + one KeyUpdate each direction + one exporter, the per-endpoint counts over 24-round Keccak-f[1600] are:<br> <br> 41 * f1600: Deck implementation, measured stateful<br> 46 * f1600: Deck implementation, measured recompute<br> 52 * f1600: Section A.1 in draft-sullivan-tls-xof-ciphers-00<br> 156 * f1600: HKDF-SHA3-256 / RFC 8446 baseline<br> 117 * f1600: Appendix D "FIPS" KMAC256 schedule<br> <br> So 41 vs 156 permutations by my count.<br> <br> ( Note: The draft slightly overcounts permutations in its estimates. )<br> <br> It's a quick prototype built with extensive AI assistance, but it includes basic correctness measures: primitive KATs (RFC 9861 TurboSHAKE256, FIPS 202 SHAKE256, SP 800-185 KMAC256, including multi-block and long-output), 73 self-generated Appendix C/D vectors, and byte-for-byte reproduction of all of them by an independent Python implementation written from the draft alone.<br> <br> - Keccak-p[1600,nr] permutation and the rate-136/capacity-512 sponge<br> - Five framed deck operations (Init/Absorb/Fork/Squeeze/Ratchet)<br> - KMAC-layout MAC<br> - Three-stage E/H/T schedule with its two ratchets<br> - Section 5 derivations (record keys, Finished/PSK binders, exporters, resumption and key-update, and the §10 external-PSK importer with ImportedIdentityV2).<br> - All five cipher suites (0xFF01–0xFF05, both profiles, three AEADs)<br> <br> </div> <div class="gmail_quote" style="direction: ltr;">Plus for comparisons:<br> <br> - Appendix D FIPS-component schedule (RFC 8446 with KMAC256 as the PRF)<br> - a permutation-count benchmark reproducing §A.1, live-secret zeroization (§15.7.2.2)<br> <br> Cheers,<br> -markku</div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_signature" style="direction: ltr;">Dr. Markku-Juhani O. Saarinen <<a href="mailto:[email protected]" target="_blank" data-outlook-id="6e82fcb1-10ea-40da-9566-9023f70c8227" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>></div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_quote" style="direction: ltr;"><br> </div> <div class="gmail_attr" style="direction: ltr;">On Tue, Jul 7, 2026 at 2:34 AM Nick Sullivan <<a href="mailto:[email protected]" target="_blank" data-outlook-id="7b499101-824b-4112-94c4-b33ff53abd97" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:</div> <blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);"> <div class="gmail_quote">Dear TLS,<br> <br> I'm sharing a draft for the group's consideration.<br> draft-sullivan-tls-xof-ciphers-00 runs the entire TLS 1.3 key schedule<br> on a single Keccak permutation, instead of HKDF built on HMAC built on<br> the cipher suite's hash, which today is always SHA-2. This is newly<br> practical because deployments using SHA-3, ML-KEM, or ML-DSA already<br> carry a Keccak permutation, so the primitive is already in the stack.<br> <br> Each derived value comes out in one pass, so a full handshake costs<br> about a third of the permutation calls an HKDF schedule over the same<br> permutation would spend.<br> <br> A cipher suite names an AEAD plus a schedule profile, and nothing else<br> changes. There is no new extension, and the state machine, record<br> layer, and wire format are untouched. Two profiles are defined, one on<br> the standard SHA-3 function and one on a faster reduced-round variant.<br> Test vectors are pinned to cipher-suite values, so the final vectors<br> will follow the code point assignment.<br> <br> <a href="https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/" target="_blank" rel="noreferrer" originalsrc="https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/" data-outlook-id="a9b6b643-fb9c-484f-9594-42fea96ad4dc" moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/</a><br> <br> This is a big change to the key schedule, and the draft is very<br> preliminary. Feedback on the approach, or interest in implementing it,<br> would help a lot.<br> <br> Best,<br> Nick<br> <br> On Mon, Jul 6, 2026 at 7:03 PM <<a href="mailto:[email protected]" target="_blank" data-outlook-id="077d413a-36df-49b1-9df5-bcb5ffc34ad7" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>> wrote:<br> ><br> > A new version of Internet-Draft draft-sullivan-tls-xof-ciphers-00.txt has been<br> > successfully submitted by Nick Sullivan and posted to the<br> > IETF repository.<br> ><br> > Name: draft-sullivan-tls-xof-ciphers<br> > Revision: 00<br> > Title: TLS 1.3 Cipher Suites with Alternative Key-Schedule Profiles<br> > Date: 2026-07-06<br> > Group: Individual Submission<br> > Pages: 46<br> > URL: <a href="https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.txt" target="_blank" rel="noreferrer" originalsrc="https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.txt" data-outlook-id="acae76fa-5d37-4be7-9afb-09b35f349e3c" moz-do-not-send="true" class="moz-txt-link-freetext"> https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.txt</a><br> > Status: <a href="https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/" target="_blank" rel="noreferrer" originalsrc="https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/" data-outlook-id="707d7f5f-b489-4ed6-9607-60a767210566" moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/draft-sullivan-tls-xof-ciphers/</a><br> > HTML: <a href="https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.html" target="_blank" rel="noreferrer" originalsrc="https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.html" data-outlook-id="10fca570-bc63-4e1f-bad6-9a58189d4460" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ietf.org/archive/id/draft-sullivan-tls-xof-ciphers-00.html</a><br> > HTMLized: <a href="https://datatracker.ietf.org/doc/html/draft-sullivan-tls-xof-ciphers" target="_blank" rel="noreferrer" originalsrc="https://datatracker.ietf.org/doc/html/draft-sullivan-tls-xof-ciphers" data-outlook-id="14c4c217-7e11-41fa-9f20-3b3437556852" moz-do-not-send="true" class="moz-txt-link-freetext"> https://datatracker.ietf.org/doc/html/draft-sullivan-tls-xof-ciphers</a><br> ><br> ><br> > Abstract:<br> ><br> > TLS 1.3 builds its key schedule on HKDF over the cipher suite's hash.<br> > This document defines TLS 1.3 cipher suites that build it on a deck<br> > function over a single permutation instead, the one a deployment<br> > already carries when it uses SHA-3, ML-KEM, or ML-DSA. One<br> > permutation then runs the whole schedule, and a full handshake takes<br> > about a third of the permutation calls an HKDF schedule over that<br> > permutation would. Such a cipher suite names an AEAD algorithm<br> > together with a schedule profile that defines every key-schedule<br> > function the connection uses. The profile follows from the<br> > negotiated cipher suite alone, so no new extension is defined and the<br> > TLS 1.3 state machine and wire format are unchanged. Two profiles<br> > are defined, one on the standard SHA-3 function and one on a faster<br> > reduced-round variant of it.<br> ><br> ><br> ><br> > The IETF Secretariat<br> ><br> ><br> <br> _______________________________________________<br> TLS mailing list -- <a href="mailto:[email protected]" target="_blank" data-outlook-id="dd7b547c-7fbe-4825-b306-a989096ef007" moz-do-not-send="true" class="moz-txt-link-freetext"> [email protected]</a><br> To unsubscribe send an email to <a href="mailto:[email protected]" target="_blank" data-outlook-id="22e3d760-1b68-44e9-a038-01cfb0ad19a3" moz-do-not-send="true" class="moz-txt-link-freetext"> [email protected]</a></div> </blockquote> <div class="gmail_quote" style="direction: ltr;"><br> </div> <pre><div class="gmail_quote">_______________________________________________ TLS mailing list -- <a href="mailto:[email protected]" target="_blank" data-outlook-id="7d4b7704-2e98-4749-88fe-beb74b11cb6a" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a> To unsubscribe send an email to <a href="mailto:[email protected]" target="_blank" data-outlook-id="a51523fd-b267-48dd-b845-516afab4a7f2" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a> </div></pre> </blockquote> <div class="gmail_quote">_______________________________________________<br> TLS mailing list -- <a href="mailto:[email protected]" target="_blank" data-outlook-id="2d1c0f45-578b-42ce-9db5-465da609c7ce" moz-do-not-send="true" class="moz-txt-link-freetext"> [email protected]</a><br> To unsubscribe send an email to <a href="mailto:[email protected]" target="_blank" data-outlook-id="c08e955a-1cd8-46e9-9df7-aca7af3cbd3d" moz-do-not-send="true" class="moz-txt-link-freetext"> [email protected]</a></div> </blockquote> <div class="gmail_quote" style="direction: ltr;"><br> </div> </blockquote> <div class="gmail_quote" style="direction: ltr;"><br> </div> <pre><div class="gmail_quote">_______________________________________________ TLS mailing list -- <a href="mailto:[email protected]" target="_blank" data-outlook-id="872dd108-42ea-47a8-a9cd-9cbe865e9405" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a> To unsubscribe send an email to <a href="mailto:[email protected]" target="_blank" data-outlook-id="e9f9eee0-fcb4-4542-be3d-c6bed1261adf" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a> </div></pre> </blockquote> <div class="gmail_quote">_______________________________________________<br> TLS mailing list -- <a href="mailto:[email protected]" target="_blank" data-outlook-id="517ee97f-b758-499b-9d67-9a8c6580eb38" moz-do-not-send="true" class="moz-txt-link-freetext"> [email protected]</a><br> To unsubscribe send an email to <a href="mailto:[email protected]" target="_blank" data-outlook-id="a8562535-d307-45ac-b9df-f5fca216ad9c" moz-do-not-send="true" class="moz-txt-link-freetext"> [email protected]</a></div> </blockquote> </div> <br> <fieldset class="moz-mime-attachment-header"></fieldset> <pre wrap="" class="moz-quote-pre">_______________________________________________ TLS mailing list -- <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> To unsubscribe send an email to <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> </pre> </blockquote> </body> </html> --------------ZfGU1IUK1WpDw0E0eMgkfeJw-- --===============3144322560876444796== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============3144322560876444796==--