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] <mailto:[email protected]>> >> >> >> On Tue, Jul 7, 2026 at 2:34 AM Nick Sullivan <[email protected] >> <mailto:[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] >>> <mailto:[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] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> >> >> _______________________________________________ >> TLS mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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]
