[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt
Joan Daemen <[email protected]> Mon, 27 Jul 2026 11:46:55 +0200
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============8614911984417213368==
Content-Type: multipart/alternative;
boundary="------------ZzGEhGMstqsx2FL00ItieHhZ"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------ZzGEhGMstqsx2FL00ItieHhZ
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Dear Nick,
Thanks for your mail.
Op 24-07-2026 om 15:30 schreef Nick Sullivan:
> 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,
Indeed, Lemma 2 is there to show that you can reduce an attack on OD to
an attack the underlying XOF ( (Turbo)SHAKE128/256) and therefore that
the security of OD is covered by the cryptanalysis of the underlying
XOF. For the (standard) duplex (as introduced in our paper Duplexing the
sponge: single-pass authenticated encryption and other applications
https://eprint.iacr.org/2011/499), this reduction is much simpler.
The main reason for using OD instead of standard duplex is that in
between duplex calls OD has a much smaller state, e.g. for
(Turbo)SHAKE128 the state of duplex is 200 bytes and that of OD is only
40 bytes. Our modes on top of keyed OD, UpperDeck/Deck-BO and DWrap do
quite some cloning and that is of course lighter with a small state. An
additional benefit is that duplexing in OD where the adversary does not
get the full output gives forward secrecy: to recover the previous
state, the missing part of the output must be guessed. But I guess
forward secrecy is not essential during the key derivation phase. If it
is, it can be realized by duplex too by feeding part of the output of a
duplex call back to the next duplex call input, effective zeroizing part
of the state.
> and the construction needs raw Keccak-p, which common libraries do not
> expose,
Access to raw Keccak-p would certainly result in the most efficient
code. But if a library exposes only the sponge interface the duplex may
also be inefficient. Namely sponge first does absorb, then switches to
the squeezing phase and does not allow returning to the absorbing phase.
You could still do it but for every duplexing call you would have start
a new sponge instance and feed it with all the duplexing call inputs up
to that point (see Figure 3 in https://eprint.iacr.org/2011/499). If the
library already exposes the duplex interface, then building OD on top of
that could be done by forming the input to a duplexing call as the XOR
of the output of the previous duplexing call plus the OD input. But this
would just complicate things and then it would be better to go for
duplex. But in the long run, if a useful/popular mechanism is defined
for TLS, then the libraries can be expected to follow.
> plus a |K| <= rho bound on the input.
This limit comes from the fact that we see keyed OD as a keyed primitive
that takes a key with high entropy per bit, while this is not
necessarily the case for in key derivation. So what you would use is
unkeyed OD or duplex and feed it with the secret that can be long and/or
have low entropy per bit. As this may require multiple blocks, it is
important to not give access to intermediate duplexing call outputs to
the adversary as this may allow him to do a divide and conquer attack on
the long secret. This can all be specified but in our paper we did not
want to go into that. So you can absorb secrets of any length as long as
you don't expose intermediate duplexing call outputs to the adversary.
> 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?
Indifferentiability is not a property of a XOF or a hash function, it is
a property of a construction to build a XOF or a hash function, as it
assumes an ideal underlying function. So differentiating the sponge
construction with a random permutation from a random oracle has
advantage at most N^2/2^{c+1} with N the number of calls to the random
permutation by the adversary and c the capacity. As soon as you replace
the random permutation by a concrete permutation you can no longer speak
of indifferentiability.
This being said, also for this use we think 12 rounds offers a
comfortable margin based on published third-party cryptanalysis. A lot
of that is listed at https://keccak.team/third_party.html
>
> 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.
Indeed, that is separate thing.
Kind regards,
Joan and Gilles on behalf of the Keccak team
>
> 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 [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]
> _______________________________________________
> TLS mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
--------------ZzGEhGMstqsx2FL00ItieHhZ
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 Nick,</p>
<p>Thanks for your mail.</p>
<div class="moz-cite-prefix">Op 24-07-2026 om 15:30 schreef Nick
Sullivan:<br>
</div>
<blockquote type="cite"
cite="mid:CAOjisRy6J++zozS77=6Rx=zbwPhzxpHSd=4Y9XXmdQB3A5w2OA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="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, </div>
</blockquote>
<p>Indeed, Lemma 2 is there to show that you can reduce an attack on
OD to an attack the underlying XOF ( (Turbo)SHAKE128/256) and
therefore that the security of OD is covered by the cryptanalysis
of the underlying XOF. For the (standard) duplex (as introduced in
our paper Duplexing the sponge: single-pass authenticated
encryption and other applications
<a class="moz-txt-link-freetext" href="https://eprint.iacr.org/2011/499">https://eprint.iacr.org/2011/499</a>), this reduction is much
simpler. </p>
<p>The main reason for using OD instead of standard duplex is that
in between duplex calls OD has a much smaller state, e.g. for
(Turbo)SHAKE128 the state of duplex is 200 bytes and that of OD is
only 40 bytes. Our modes on top of keyed OD, UpperDeck/Deck-BO and
DWrap do quite some cloning and that is of course lighter with a
small state. An additional benefit is that duplexing in OD where
the adversary does not get the full output gives forward secrecy:
to recover the previous state, the missing part of the output must
be guessed. But I guess forward secrecy is not essential during
the key derivation phase. If it is, it can be realized by duplex
too by feeding part of the output of a duplex call back to the
next duplex call input, effective zeroizing part of the state.</p>
<blockquote type="cite"
cite="mid:CAOjisRy6J++zozS77=6Rx=zbwPhzxpHSd=4Y9XXmdQB3A5w2OA@mail.gmail.com">
<div dir="ltr">and the construction needs raw Keccak-p, which
common libraries do not expose, </div>
</blockquote>
<p>Access to raw Keccak-p would certainly result in the most
efficient code. But if a library exposes only the sponge interface
the duplex may also be inefficient. Namely sponge first does
absorb, then switches to the squeezing phase and does not allow
returning to the absorbing phase. You could still do it but for
every duplexing call you would have start a new sponge instance
and feed it with all the duplexing call inputs up to that point
(see Figure 3 in <a class="moz-txt-link-freetext" href="https://eprint.iacr.org/2011/499">https://eprint.iacr.org/2011/499</a>). If the
library already exposes the duplex interface, then building OD on
top of that could be done by forming the input to a duplexing call
as the XOR of the output of the previous duplexing call plus the
OD input. But this would just complicate things and then it would
be better to go for duplex. But in the long run, if a
useful/popular mechanism is defined for TLS, then the libraries
can be expected to follow.</p>
<blockquote type="cite"
cite="mid:CAOjisRy6J++zozS77=6Rx=zbwPhzxpHSd=4Y9XXmdQB3A5w2OA@mail.gmail.com">
<div dir="ltr">plus a |K| <= rho bound on the input.</div>
</blockquote>
This limit comes from the fact that we see keyed OD as a keyed
primitive that takes a key with high entropy per bit, while this is
not necessarily the case for in key derivation. So what you would
use is unkeyed OD or duplex and feed it with the secret that can be
long and/or have low entropy per bit. As this may require multiple
blocks, it is important to not give access to intermediate duplexing
call outputs to the adversary as this may allow him to do a divide
and conquer attack on the long secret. This can all be specified but
in our paper we did not want to go into that. So you can absorb
secrets of any length as long as you don't expose intermediate
duplexing call outputs to the adversary.
<blockquote type="cite"
cite="mid:CAOjisRy6J++zozS77=6Rx=zbwPhzxpHSd=4Y9XXmdQB3A5w2OA@mail.gmail.com">
<div dir="ltr"> </div>
</blockquote>
<blockquote type="cite"
cite="mid:CAOjisRy6J++zozS77=6Rx=zbwPhzxpHSd=4Y9XXmdQB3A5w2OA@mail.gmail.com">
<div dir="ltr">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>
</div>
</blockquote>
<p>Indifferentiability is not a property of a XOF or a hash
function, it is a property of a construction to build a XOF or a
hash function, as it assumes an ideal underlying function. So
differentiating the sponge construction with a random permutation
from a random oracle has advantage at most N^2/2^{c+1} with N the
number of calls to the random permutation by the adversary and c
the capacity. As soon as you replace the random permutation by a
concrete permutation you can no longer speak of
indifferentiability. </p>
<p>This being said, also for this use we think 12 rounds offers a
comfortable margin based on published third-party cryptanalysis. A
lot of that is listed at <a class="moz-txt-link-freetext" href="https://keccak.team/third_party.html">https://keccak.team/third_party.html</a></p>
<blockquote type="cite"
cite="mid:CAOjisRy6J++zozS77=6Rx=zbwPhzxpHSd=4Y9XXmdQB3A5w2OA@mail.gmail.com">
<div dir="ltr"><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>
</div>
</blockquote>
<p>Indeed, that is separate thing. </p>
<p>Kind regards,</p>
<p>Joan and Gilles on behalf of the Keccak team</p>
<blockquote type="cite"
cite="mid:CAOjisRy6J++zozS77=6Rx=zbwPhzxpHSd=4Y9XXmdQB3A5w2OA@mail.gmail.com">
<div dir="ltr"><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>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Tue, Jul 14, 2026 at
1:09 PM Joan Daemen <jda=<a
href="mailto:[email protected]"
moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>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"
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><span>*</span>not<span>*</span></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>Op 08-07-2026 om 18:01 schreef Nick Sullivan:<br>
</div>
<blockquote type="cite">
<div>
<div style="font-size:inherit">
<div dir="auto"
style="color:rgb(0,0,0);font-family:-apple-system,sans-serif;font-size:inherit;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Hi
Hannes,</div>
<div dir="auto"
style="color:rgb(0,0,0);font-family:-apple-system,sans-serif;font-size:inherit;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>
</div>
<div dir="auto"
style="color:rgb(0,0,0);font-family:-apple-system,sans-serif;font-size:inherit;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">As
Thom noted below in the chain, the motivation is to
modernize the key schedule, which has two main
advantages:</div>
<div dir="auto"
style="color:rgb(0,0,0);font-family:-apple-system,sans-serif;font-size:inherit;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>
</div>
<div dir="auto"
style="color:rgb(0,0,0);font-family:-apple-system,sans-serif;font-size:inherit;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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 dir="auto"
style="color:rgb(0,0,0);font-family:-apple-system,sans-serif;font-size:inherit;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">2.
R<span style="font-family:-apple-system,sans-serif">emoving
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.</span></div>
<div dir="auto"
style="color:rgb(0,0,0);font-family:-apple-system,sans-serif;font-size:inherit;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>
</div>
<div dir="auto"
style="color:rgb(0,0,0);font-family:-apple-system,sans-serif;font-size:inherit;font-style:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Nick</div>
</div>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jul 8, 2026
at 3:58 PM Thom Wiggers <<a
href="mailto:[email protected]" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">[email protected]</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Hi Hannes,
<div><br>
</div>
<div>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><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>Thom</div>
</div>
<div>
<div><br>
<div>
<div><br>
<blockquote type="cite">
<div>Op 8 jul 2026, om 13:47 heeft Hannes
Tschofenig <hannes.tschofenig=<a
href="mailto:[email protected]"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">[email protected]</a>>
het volgende geschreven:</div>
<br>
<div>
<div>
<p>Hi Markku, Hi Nick!</p>
<p>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>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>Ciao<br>
Hannes</p>
<p><br>
</p>
<div>Am 08.07.2026 um 12:16 schrieb
Markku-Juhani O. Saarinen:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>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><br>
</div>
<div><a
href="https://github.com/mjosaarinen/altkdf-rs" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/mjosaarinen/altkdf-rs</a> </div>
<div><br>
</div>
<div>( Editorial comments in <a
href="https://github.com/mjosaarinen/altkdf-rs/blob/main/FINDINGS.md"
target="_blank"
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>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><br>
</div>
<div>
<div dir="ltr"
class="gmail_signature">Dr.
Markku-Juhani O. Saarinen
<<a
href="mailto:[email protected]"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">[email protected]</a>></div>
</div>
</div>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On
Tue, Jul 7, 2026 at 2:34 AM Nick
Sullivan <<a
href="mailto:[email protected]" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">[email protected]</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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/"
rel="noreferrer"
target="_blank"
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"
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"
rel="noreferrer"
target="_blank"
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/"
rel="noreferrer"
target="_blank"
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"
rel="noreferrer"
target="_blank"
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"
rel="noreferrer"
target="_blank"
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"
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" moz-do-not-send="true"
class="moz-txt-link-freetext">[email protected]</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
TLS mailing list -- <a href="mailto:[email protected]" target="_blank"
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"
moz-do-not-send="true"
class="moz-txt-link-freetext">[email protected]</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
TLS mailing list -- <a
href="mailto:[email protected]"
target="_blank" 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" moz-do-not-send="true"
class="moz-txt-link-freetext">[email protected]</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
TLS mailing list -- <a href="mailto:[email protected]" target="_blank"
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" moz-do-not-send="true"
class="moz-txt-link-freetext">[email protected]</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
TLS mailing list -- <a href="mailto:[email protected]"
target="_blank" 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"
moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>
--------------ZzGEhGMstqsx2FL00ItieHhZ--
--===============8614911984417213368==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp
bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0
bHMtbGVhdmVAaWV0Zi5vcmcK
--===============8614911984417213368==--