[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt

Ilari Liusvaara wrote:
>MarsupilamiFourteen (sic) has 14 rounds. Looks like TurboSHAKE security margin gets pretty thin with some 256-level stuff.

I think the old 14-round figure came from the zero-sum distinguishers on Keccak-f. You need 14 rounds for distinguishing attacks on the underlying permutation to have a complexity of at least 2^{256}. However, these are distinguishers on the permutation, not on TurboSHAKE256 itself.

https://keccak.team/files/NoteZeroSum.pdf

My understanding is that TurboSHAKE256 has significant security margins:

"there is ample evidence from third-party cryptanalysis that 12 rounds provides a comfortable safety margin. For instance, the best collision attack reaches only 6 rounds."

https://keccak.team/2025/rfc9861.html

Cheers,
John Preuß Mattsson

From: Ilari Liusvaara <[email protected]>
Date: Wednesday, 8 July 2026 at 16:06
To:
<[email protected]>
Subject: [TLS] Re: New Version Notification for draft-sullivan-tls-xof-ciphers-00.txt

On Wed, Jul 08, 2026 at 01:47:54PM +0300, Markku-Juhani O. Saarinen wrote:
> On Wed, Jul 8, 2026 at 12:07 PM Thom Wiggers <[email protected]> wrote:
> (..)
>
> > I’m not sure how the hardware implementations work but if they’re not
> > stuck to a particular number of rounds then they could perhaps easily be
> > used to accelerate things like Kravatte (or if they are stuck to a number
> > of rounds, perhaps not). This could also mean that TurboSHAKE is slower
> > than full SHAKE if there’s fixed hardware support for only 24 rounds, if i
> > understand the situation there correctly. So if vkeccak.vi only supports
> > Keccak-p[1600,24], we might be better using full SHAKE…
> >
> > @Makku, how does this situation look like from your POV?
> >
>
> Hi Thom,
>
> There are probably hardware implementations that hardcode the number of
> rounds, but at RISC-V we currently specify vkeccak.vi with the 5-bit
> immediate field directly stating the number of rounds (round constants in
> Keccak come from an LFSR, so >24 rounds is fine too).
>
> I asked Joan Daemen last year if he could think of any proposal, anywhere,
> where the round count would not be a multiple of 6, and he didn't remember
> such a case. Se we could save encoding space and have the instruction
> handle only 6, 12, 18, or 24 rounds (a 2-bit encoding of the immediate,
> with the remaining 3 bits reserved for future use). Or 12, 24, 36, 48?

MarsupilamiFourteen (sic) has 14 rounds. Looks like TurboSHAKE security
margin gets pretty thin with some 256-level stuff.




-Ilari

_______________________________________________
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]