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]
