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

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]