[TLS] Re: [EXT] What about AuthKEM? / Online-Offline signature split

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

There’s a similar protocol submission at IPSECME, and I did some quantitative analysis, which I’ll post there later. Here’s its TL;DR:


This analysis quantifies the performance, bandwidth, memory, and round-trip trade-offs between two approaches to post-quantum mutual authentication in IKEv2:

* Traditional (Explicit): Ephemeral KEM + digital signatures (current IETF trajectory, RFC 9370 + RFC 8784 extensions)
* Proposed (Implicit): Dual KEM authentication (draft-wang-ipsecme-kem-auth-ikev2-03, MQV/HMQV family)
Two variants of the implicit approach are analyzed:

* Proposed-A: ML-KEM-768 for both ephemeral and authentication KEM
* Proposed-B: ML-KEM-768 ephemeral + Classic McEliece (preloaded keys) for authentication
Bottom line: the proposed approach cuts per-peer CPU time by 85–95%, reduces wire bytes by 50–78%, and — with preloaded keys — reduces message count from 4 to 3. It does this without weakening security; the protocol security rests on HMQV-style proofs and dual-KEM assumptions.
You get similar advantages with ML-KEM-1024 and ML-DSA-87.


--
V/R,
Uri

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
C. A. R. Hoare


From: Joshua <joshua=[e-mail]>
Date: Thursday, April 2, 2026 at 18:30
To: [e-mail] <[e-mail]>
Subject: [EXT] [TLS] What about AuthKEM? / Online-Offline signature split


While the horticulturalists over at PLANTS has been working on some really cool stuff regarding tree signatures,
I wanted to revive an idea that’s been toyed with in the past: what if we move away from signature suites for
handshaking, and move to exclusively AuthKEM-based handshakes?

AuthKEM has some advantages over “normal” Signatures. Chiefly, we are using signature algorithms designed to be
provable to anyone, anywhere, and using them in cases where only one person will ever need to verify them. This
has real impacts on the attack surface; non-constant-time signature generation can lead to key recovery attacks,
implementation errors can lead to key recovery attacks, implementations can potentially be tricked into signing
maliciously crafted plaintexts, etc. On the contrary, AuthKEM "proofs" are very localized; an AuthKEM "signature"
can't easily be passed on and verified by third parties.

Overall, 3DH-esque authentication schemes are simpler, faster, and smaller than their comparative signature-based
authentication schemes. (Kyber512 is used to illustrate, but I do not recommend it's adoption)
- Dilithium2 requires 3,700 bytes to communicate a pk/sig pair, whereas AuthKEM-Kyber512 requires less than half
at 1,500 bytes;
- Dilithium2 requires about 300kilocycles to generate a proof, whereas decapsulating a AuthKEM-Kyber512 secret
can go as low as ~30kilocycles;
- Dilithium2 requires both a correct constant-time PQ KEM and a correct constant-time PQ signature algorithm,
whereas AuthKEM-Kyber requires only a correct constant-time PQ KEM.

For example, consider the issues with Ed25519, generally considered one of the more bulletproof signature schemes
available/widely deployed today:
- Despite having constant-time point addition, a constant-time scalarmult ladder is required to avoid side-channels;
- A single bit-flip during signing exposes the private key immediately, and implementation errors compound this problem;
- This also occurs when signing with a mismatched private/public keypair (which some implementations used to allow)

These benefits* have, of course, already been enumerated in the AuthKEM I-D, available here:
https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/ <8d3ef7ce-3599-4055-a346-31b9817c1f6a>

* Debatably “benefits” based on your use case, hence why I’m writing this email.

That's not to say that lattice-based signature schemes are a bad idea; on the contrary, I think saying "we should
only use AuthKEM for authentication" frees us to consider more optimal signature schemes for each step in the chain.
For example, FN-DSA is a perfect fit for chain signatures (especially since we don't need to worry about side-channel
resistance), and more exotic algorithms like SQIsign might even enter the fray. And of course, we have the eternally-cool
merkle trees for root certificates. We won't need to worry about, eg, SQIsign being (mis)used for handshakes, and a side-
channel key recovery attack breaking a significant portion of the encrypted internet.

So, I want to pose a few questions to the mailing list:

1. Should we only consider the AuthKEM family of handshake algorithms for use within PQ CertificateVerify messages?
(In other words, forbid "real" signature algorithms for use within the handshake process)

2. Should we segment handshake schemes into different use cases based on their side channel resistance?
(eg, allowing FN-DSA for offline signatures, but forbidding them for online/handshake signatures)

3. Are experimental post-quantum handshakes ready to go into TLS without the seatbelt?
Personally, I’d say yes: if an attack is found, loss-of-confidentiality is limited to active attacks, and
clients can be updated to reject the insecure algorithm, which allows us to contain the blast radius.
(This is in contrast to eg. Standalone ML-KEM, where compromise means years of retroactive confidentiality loss)


Best,
Joshua Nabors


P.S. This has nothing to do with the dilithium2 draft published recently; if it means anything, I support its publication.

P.P.S. I would like to add “Futureproofing (the) Internet’s Secure Handshaking” (FISH) to the backronyms bucket.
“Marine Biologists” has a nice ring to it :^)