On Wed, Jul 8, 2026 at 5:07 PM Ilari Liusvaara <[email protected]> wrote:
> 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, Ah! Joan couldn't have forgotten that, so I probably wasn't very clear with my question. Anyway, I hope we can make it at least an even number. Double rounds in hardware could be something someone might want, and the extra mux in the middle would be very annoying if there is no real-world use case for it. With such an instruction, the number of rounds doesn't really affect the overall speed of a high-level protocol/algorithm; Keccak is negligble in either case. Roughly: Getting words from the VRF to the 1600-bit permutation holding register and back can take more time than the permutation itself. One "fast" CPU design had 42 cycles for the 24-round permutation (18 cycles of overhead for VRF access + 24 cycles rrounds), Karu (the lowest-end implementation imaginable) is somewhere around 100 cycles right now. In both cases, there's about a ~ 100x speedup over a software implementation on the same core. Cheers, -markku > -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]
