Nick Sullivan wrote: >The MAC is literally KMAC for SHAKE in order to simplify analysis drop-in >analysis and leverage existing secure implementations. As Thom noted, >TurboKMAC doesn’t exist outside of this document, but given the similarity >of TurboSHAKE and SHAKE, it shouldn’t be too problematic to re-analyze the >same KMAC shape with fewer rounds underneath. This could be wishful >thinking on my part.
Might be worth syncing with other TurboSHAKE-based MACs in the IETF. https://datatracker.ietf.org/doc/draft-bormann-cose-turbo-kanga-kmac/ https://mailarchive.ietf.org/arch/msg/ipsec/BGk6ySpCJv8BzjVIQXaROzjQwGQ/ Cheers, John Preuß Mattsson From: Nick Sullivan <[email protected]> Date: Wednesday, 8 July 2026 at 17:52 To: Ilari Liusvaara <[email protected]> Cc: <[email protected]> Subject: [TLS] Re: New Version Notification for draft-sullivan-tls-xof-ciphers-00.txt Cheers, John Preuß Mattsson On Wed, Jul 8, 2026 at 11:33 AM Ilari Liusvaara <[email protected]<mailto:[email protected]>> wrote: On Wed, Jul 08, 2026 at 11:04:40AM +0200, Thom Wiggers wrote: > Hi Nick, all, > > - Ilari’s construction, from a high level, looks like a re-invention > of the Deck construction. Nick already provided a performance > comparison, but I feel that re-inventing this wheel is a bad road > to go down and that we should instead stick to (well-analyzed) > primitives. I did not set out to re-invent deck construction, but to optimize the existing TLS 1.3 key schedule assuming XOF with wide enough blocks (like (Turbo)Shake256). It is definitely not intended to be clever. Heck, it still has the third handshake rachet, which so far does not seem to do anything useful. > On the draft: > > - The draft spends a lot of time talking about how all of the hash > computations are updated. I have a very hard time getting through > all of that. I also had very hard time following all the key schedule stuff. Which was a big reason for me to develop something that seemed much simpler. > - Additionally, I feel that all sections not specific to instantiation > profiles should be generic — the MAC section hardcodes it to KMAC’s > design. Yeah, the TLS 1.3 design seems just odd there. There might be a good reason, like getting the proofs to go through with HKDF/SHA-2, or it might just be cargo-culted. Some quick motivation on this part of the design: There are effectively three types of derivations in TLS 1.3: derive key, advance schedule, and generate authentication tag. This design attempts to be conservative by only relying on the new deck function construction (point taken on defying this sooner) for the schedule, and re-using existing analyzed designs for derive key and authentication tag. The MAC is literally KMAC for SHAKE in order to simplify analysis drop-in analysis and leverage existing secure implementations. As Thom noted, TurboKMAC doesn’t exist outside of this document, but given the similarity of TurboSHAKE and SHAKE, it shouldn’t be too problematic to re-analyze the same KMAC shape with fewer rounds underneath. This could be wishful thinking on my part. > - Section 15.7.2.2 uses capital-MUST for things that are not > interoperability hazards. The erasure requirements look like trouble for pretty much any higher level language, not just the ones with GC. Compilers like to spill values to stack, and those are pretty much impossible to erase, as there is no way to target the location. -Ilari _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
