Hi Nick, all, I think that this is a great idea. HKDF has been great, but we’ve got fancier and better primitives now (that we have stronger proofs for). I have a few comments on the draft and a few comments on this discussion, which I’ll tackle first.
- I agree that Keccak-based-encryption may be nice. I am not a symmetric cryptography expert, but clicking around on Keccak.team suggests there are fancier/faster encryption schemes based on Keccak-p[1600], like Kravatte (Keccak-p[1600,6]), that use smaller round numbers than TurboSHAKE (Keccak-p[1600,12]) or SHA3 (Keccak-p[1600,24] = Keccak-f[1600]). But I also strongly agree that this is a ’next step’ rather than something to do in this draft. 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? - 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. On the draft: - The introduction introduces a Deck function but provides no definition or forward reference. I think that it would be helpful to clarify at a high level that a Deck function allows hashing to arbitrary output lengths while also allowing incremental absorbing of inputs. - 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 feel it would be really helpful if the key schedule diagram of TLS 1.3 [1] is re-stated using the Deck function instead. The diagram in appendix A is a little bit too light on the detail for me. - Section 5.2 re-invents KMAC to avoid referencing KMAC (though, to be fair to the case of TurboSHAKE, TurboKMAC technically doesn’t exist). As someone who likes to prove protocol security: this stuff makes my life hard. It means that instead of just arguing that Deck can be used to instantiate the PRF games in the existing proofs, I will also need to prove that your custom KMAC is EUF-CMA secure. - Additionally, I feel that all sections not specific to instantiation profiles should be generic — the MAC section hardcodes it to KMAC’s design. - The security considerations contain some things that are not security considerations in my opinion, such as 15.5. - Your Git repository https://github.com/grittygrease/draft-sullivan-tls-xof-ciphers is not public. You have an implementation of this? The doc refers to test vectors. - You make many references to TLS13KS. This is the right paper to reference, but there are some warts. In particular, “multi-stage” is used a lot surrounding the references to TLS13KS. This is not a term used by TLS13KS, and in particular it is misleading as TLS13KS is not a “multi-stage security” proof as in Dowling et al.’s analysis of TLS 1.3. Section 15.7.1.5 also suggests that TLS13KS uses HMAC for transcript authentication, which it does not (it does not consider authentication). - Section 15.7.1.5, aside from the above, reaches into the Deck function (“the 512-bit capacity withheld at each squeeze”) to argue the security of the XOF key schedule. I don’t think this is appropriate and should instead be argued through the incremental security of Deck functions. - I’m going to stop proof-reading these security arguments and comparisons to other work. I think they need to be carefully rewritten and likely reorganized. - There are some weird titles ("Erasure Boundaries and One-Wayness”, "The Invertibility Hazard”) that (apologies for my directness) sound a lot like an LLM inventing “cool” colourful language. (In general there are some sections that similarly feel a bit “off”, though I appreciate that use of LLMs allows to deliver this draft this much sooner.) - Section 15.7.2.1 is implied by the primitive assumptions. - Section 15.7.2.2 uses capital-MUST for things that are not interoperability hazards. - Appendix D. I don’t think FIPS compliance is relevant to this draft. It’s obvious that SHAKE256 and KMAC are specified by NIST; but I think that FIPS 140 has a bunch of more specific language about how TLS 1.3 should be implemented and that language might change in the future anyway. I vote for deleting this. Cheers, Thom [1] https://datatracker.ietf.org/doc/html/rfc8446#section-7.1 > Op 8 jul 2026, om 01:45 heeft Nick Sullivan <[email protected]> het > volgende geschreven: > > Thanks, everyone. Let me take this person by person: restate each point so > we're on the same page, then say where I land. (forgive the formatting, > monospace was needed) > > John Mattsson > > You're suggesting the deck should do much more: fine-grained services from > one deck function instead of assembling a protocol out of separate symmetric > primitives, a lightweight roll for cheap per-message ratcheting, and the key > schedule and record encryption folded into one running duplex rather than > handed to a separate AEAD. > > We agree on the starting point: HMAC and HKDF are a poor base, and replacing > them is the whole point of the draft. Where I stop short of you is going all > the way to a duplex that does everything. It's an elegant end state, but not > this draft: I want the new surface small enough to analyze, and record > protection is throughput-bound, where a separate AEAD is the right tool for > now. Ilari pushed back on the roll and the duplex directly, so I'll pick > those up under him. > > Markku Saarinen > > You're pointing at the hardware chicken-and-egg: Keccak is fast in silicon > but gets little of it, because software keeps reaching for AES and GCM, and > you expect ML-KEM, ML-DSA, and full-round Keccak instructions to finally > break the cycle, so we should build for where the hardware is heading. > > That's the premise the draft runs on: once Keccak is already in the stack for > SHA-3, ML-KEM, or ML-DSA, the schedule reuses it for free. And when the > full-round hardware you describe arrives, a duplex record layer, the kind of > thing your BLINKER prototyped, is the natural next profile, which is exactly > the endpoint John is after. > > Ilari, on record protection > > You already made the case against John's two record-layer ideas: a > per-message roll runs into DTLS reordering and loss, and your own Keccak > duplex record experiment wasn't fast enough to replace the AEAD. > > I agree, and that's why -00 leaves record protection to the AEAD and keeps > KeyUpdate a full ratchet rather than a roll. > > Martin Thomson > > You'd keep the KDF choice off the cipher suite and negotiate it on its own, > with 0 reserved for HKDF, and you flagged the cost: until the server selects, > a client can be carrying several schedules at once, so keep the set small. > > Fair, and I'll take it. -00 bundles them today: > > -00: cipher suite = (AEAD, schedule) one code point, bundled > -01: cipher suite = AEAD > KDF extension = { 0 = HKDF, deck, ... } negotiated separately > That's a real change to how the draft frames itself, not a small edit, but > I'd rather make it than defend the coupling. On the parallel cost, the case > that bites is offering HKDF next to the deck, since that's SHA-2 against > Keccak, two different hashes to carry until the server picks, the same cost > TLS already pays for hash-agile suites. The two deck profiles aren't a second > axis: they're one design at 12 and 24 rounds, SHAKE256 being the full-round > one for FIPS conformance, so offering both is one codebase at two round > counts. Keep the offered set small and that's the whole of it. I’d prefer > TurboSHAKE if we’re selecting only one, but if FIPS is a target, people may > prefer the “too much crypto” version for compliance reasons. > > Ilari, on the schedule > > You think -00 looks complicated, and you sketched a leaner one: a two-part > [Left | Right] state, a Rachet that carries the Left half forward as the > chain, and an Output off the Right half for every derived value. Here are the > two side by side, aligned at the stage secrets the way the appendix aligns > 8446 (no PSK, matching the count below): > > deck (-00) Ilari > > PSK PSK > | absorb; Ratchet | Rachet > v v > early_secret early_secret [L|R] > | | > | absorb DHE, TH_SH | Rachet(Left, DHE) > v v > H trunk (handshake) handshake_secret [L|R] > | Fork: hs traffic | Output(R): hs traffic > | | > | Ratchet | Rachet(Left) > v v > main_secret master_secret [L|R] > | absorb TH_SF | > v | > T trunk (application) | Output(R): app traffic, > | Fork: app traffic, | exporter, > | exporter, resumption | resumption > It's essentially the same tree. The one structural difference: you keep an > explicit handshake_secret, where the deck absorbs the key-exchange secret > into a running trunk and forks from it, so the deck has two stage ratchets > where you have three. > > On cost, counted on your scenario (no PSK, transcript set aside, since that's > what your 15 covers): > > deck Ilari > stage transitions 2 3 > traffic secrets 4 4 > record keys 4 4 > Finished (client+server) 4 2 > exporter 1 1 > resumption 1 1 > total 16 15 > So 16 to your 15. The single extra call is the separate MAC key: the deck > spends two per Finished, expand finished_key then MAC, where you spend one > Output, so plus two across the two Finisheds, minus one because the deck > folds the handshake extract into an absorb instead of a third ratchet. One > call apart, and that call is the tradeoff. Your Finished keys off > Right(BaseKey), the traffic secret you also expand into its record keys, so a > proof has to argue that one key is safe for both; the deck derives a separate > finished_key, used for that MAC and nothing else (on SHAKE256, exactly > KMAC256). One is a call cheaper, the other easier to reason about. Both are > one XOF per derived value, which is where the saving over an HKDF schedule > comes from, for both. > > On the proof, you're right that it needs one, and -00 is no different. A > running trunk isn't the discrete extract-then-expand shape the existing TLS > 1.3 results assume, so the chaining needs fresh analysis either way. The > leaves are where the two diverge. The draft's leaves are built on analyzed > constructions: the derivation is a keyed sponge with concrete keyed-duplex > bounds, and the MAC is KMAC, whose framing gives the keyed separation and > keeps a MAC from colliding with a derivation. Rachet and Output are one bare > XOF at one domain, keyed by a prefix, so the keyed-PRF step and the > MAC-versus-derivation separation are still open. The output carries > HKDF-Expand-Label's labels. Rachet has none and leans on the chained state to > keep the stages apart. Nothing there looks unsound, just less of it already > written down and analyzed. > > -01 action items > > Pull the KDF into its own extension, 0 = HKDF; keep the separate-key MAC; > leave record protection to a later profile; and take the running-state > schedule to a real proof. > > Thanks, all! This is the read I was hoping for. Keep it coming. > > Nick > > > On Tue, Jul 07, 2026 01:49 PM, "Markku-Juhani O. Saarinen" > <[email protected] <mailto:[email protected]>> wrote: >> 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] >> <mailto:[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] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> _______________________________________________ >> 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]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
