On Tue, Jul 14, 2026 at 01:08:43PM +0200, Joan Daemen 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.

One issue is that most hardware does not have any hardware acceleration
for Keccak, and very high speed software-only versions are expensive.


> # 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.

I think the only place that needs to be ratchet is (Extended) Key Update
updating the keys (since those keys can be intermediate-duration and it
must not be possible to backtrack).

Then TLS 1.3 key schedule is a bit whacky: There can be multiple PSKs,
each with its own binder, traffic secret and exporter secret, or there
might not be PSK at all. The key schedule continues from the option
chosen by the server. To do that efficiently pretty much requires
forking the state somehow.




-Ilari

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to