On Sat, Jan 28, 2023 at 09:02:32AM +0000, John Mattsson wrote: > > >Well, duplex mode is a bit special-purpose thing, for cases where one > >wants to reduce number of primitives to reduce code size, or has > >hardware acceleration to make it much faster than AES-GCM. > > That is also a good idea. NIST stated a long time ago that they would > standardize an AEAD based on Keccak, but that has not happened so far.
There is paper about Keccak duplex mode by Team Keccak, which contains important information like how the mode works and what assumptions it has. And I meant using duplex mode for bulk encryption. It seems to be useful for that in both constrained and extreme-performance hardware- accelerated implementations. > I was thinking that Keccak duplex mode could be used in the key > schedule. It feels high level like a more natural construct for a key > schedule. You cen see it as a generalization of the running hash > interface. > > Running hash: > init(), update(Mi), digest = finalize() > > Duplex: > init(), digest = update(Mi, length) > > But it might too much changes and too little gain to do. That definitely seems too much change and too little gain. - Seems to be kind of change that would really mess with implementations. - Could cause problems with the way PSK binders are calculated (tapped in middle of ClientHello!). - Minimal code size benefit at most. - No performance benefit (possibly even slight performance penalty). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
