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). The debatable question is whether this is too much freedom. Allowing an odd number of rounds limits hardware implementations that would like to do double-rounds per cycle (the permutation is so fast that one can even do triple-rounds and still meet GHz-level clock frequencies -- have 24 rounds of the 1600-bit permutation crunch through in 12 or 8 cycles). 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? Advertising this silly blog post again: https://karucore.com/posts/pqc-and-keccak-on-karu/ Cheers, -markku Dr. Markku-Juhani O. Saarinen <[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
