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]> 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]>
> 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]
>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
