Yep,
For many years Keccak/SHA3 has had this chicken-and-egg problem wrt AES & GCM, and SHA-2 too. While Keccak is faster in actual hardware, current processors allocate a lot of real estate to the AES S-Boxes and carryless multipliers, and hardly anything to Keccak. As a result, software engineers keep using AES & GCM even more, not SHA3 at all -> processor makers invest even more gates on AES & GCM and still hardly anything in SHA3. With ML-KEM and ML-DSA making heavy use of Keccak, we may finally break this cycle of doing 90s crypto forever -- and finally get full-round Keccak vector instructions (that compute the entire f1600 in a few dozen cycles) on more processors. This is "full keccak" approach substantially faster than the partial SHA3 instructions available in, say, ARMv9. Such a Keccak engine would, of course, make Duplex AEADs competitive or faster than AES & GCM. At the RISC-V PQC TG, the official full Keccak instruction has a ratification plan targeting early next year. So, at present it is restricted to experimental CPUs like the KaruCore processor we use as an HW PoC (but it boots Linux and runs stock OpenSSL benchmarks!) Here's a silly blog I wrote about running PQC benchmarks on it: https://karucore.com/posts/pqc-and-keccak-on-karu/ *"TL;DR: The Keccak instruction vkeccak.vi <http://vkeccak.vi> proposed in the PQC TG of RISC-V International is implemented in our karu64 core and makes standard lattice-based PQC algorithms go 50% faster. The more you optimize the rest, the bigger the Keccak share becomes and the greater the relative benefit of having Keccak."* I want "nice things" ! When building clean-slate things (brand-new CPUs and brand-new TLS handshakes), we don't always have to consider the limitations of technologies that we fully expect to go away anyway. And in the meanwhile the older systems can happily coexist with the new. Cheers, -markku On Tue, Jul 7, 2026 at 7:54 PM Ilari Liusvaara <[email protected]> wrote: > On Tue, Jul 07, 2026 at 06:08:10AM +0000, John Mattsson wrote: > > > > This seems like a great start! > > > > Instead of performing a full permutation for the relatively infrequent > > key updates, it may be preferable to also use a lightweight "roll" > > function to support inexpensive per-message ratcheting, similar to the > > approach used by the Signal protocol. > > This seems to run into problems with reodering/loss in DTLS and AES being > slow to rekey (Chacha is much faster here). > > > > The current draft still hands off record protection to a separate AEAD, > > with the deck function merely deriving the traffic keys. In my view, > > this leaves one of the most compelling opportunities unexplored. The > > key schedule and record encryption could be integrated into a single > > running duplex object. > > Unfortunately, Keccak does not seem to be very good for this. > > I recently experimented with using Keccak for record protection. Testing > core loop (the dominant cost for long messages) of an impractical AEAD > (8-way interleaved TurboKeccak in duplex mode) gave ~6GBps on > AMD 7900X(@65W). > > -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]
