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]
