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. > - 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] To unsubscribe send an email to [email protected]
