up:: In the Protocols MOC
KEMTLS
KEMTLS is a research proposal to authenticate a TLS handshake using key-encapsulation mechanisms in place of digital signatures, published by Peter Schwabe, Douglas Stebila, and Thom Wiggers at ACM CCS 2020. Its motivation is a size problem specific to post-quantum cryptography: the post-quantum KEMs like ML-KEM are small, while the post-quantum signatures like ML-DSA are large, so a handshake that authenticates the server by signing is heavier than one that authenticates by decapsulating. KEMTLS replaces the server’s handshake signature with a KEM operation, so the server proves its identity by decrypting rather than by signing. It is a design paper rather than a shipped protocol, and the mainstream migration deploys hybrid signatures in a standard TLS 1.3 handshake, but the idea names the exact tension that makes post-quantum authentication expensive.
Source: P. Schwabe, D. Stebila, T. Wiggers, “Post-Quantum TLS Without Handshake Signatures,” ACM CCS 2020, ePrint 2020/534, eprint.iacr.org/2020/534.
The short version:
- KEMTLS authenticates the TLS server with a KEM instead of a signature. The server’s certificate carries a KEM public key, the client encapsulates to it, and only the real server can decapsulate, which proves its identity implicitly.
- The reason to bother is size. Among post-quantum candidates, KEM public keys and ciphertexts are much smaller than signature public keys and signatures, so authenticating with a KEM sends far fewer bytes.
- The paper reports a size-optimized KEMTLS handshake at “less than half the bandwidth” of a size-optimized post-quantum TLS 1.3, and about “90%” fewer server CPU cycles, because the server never computes a signature.
- KEMTLS is implicitly authenticated. The server is not verified by a signature check but by the fact that the handshake only completes if the server could decapsulate, which is a different trust structure from classic TLS.
- It is a research proposal, not a standard. The IETF has not adopted it, and the deployed post-quantum authentication path is post-quantum and hybrid signatures inside an ordinary TLS 1.3 handshake, so KEMTLS is a lens on the tradeoffs rather than a thing you turn on.
Picture proving you hold the key to a specific mailbox. One way is to sign a note and let anyone check your signature against a public record, which is how TLS authenticates today, and it works but the post-quantum version of that signature is bulky. The other way is for the challenger to drop a sealed message into your mailbox and ask you to read back what was inside. Only the real keyholder can open the box and recover the contents, so a correct reply proves possession without any signature at all. KEMTLS is the second approach applied to a server’s identity: the client seals a secret to the server’s published key, and the server’s ability to unseal it is the proof. The bytes saved are the whole reason the idea exists.
What is KEMTLS?
KEMTLS is a redesign of the TLS 1.3 authenticated handshake that removes the server’s handshake signature and authenticates the server through a key-encapsulation mechanism instead. The paper’s title states the goal plainly, “Post-Quantum TLS Without Handshake Signatures,” and the abstract describes the core substitution as using “key-encapsulation mechanisms (KEMs) instead of signatures for server authentication.” In a normal TLS 1.3 handshake the server presents a certificate and then signs the transcript to prove it holds the certificate’s private key. KEMTLS keeps the certificate but changes what is inside it and what the server does with it.
The design rests on putting a long-term KEM public key in the server’s certificate rather than a signature-verification key. The client, having received the certificate, encapsulates a secret to that KEM public key. Only a server holding the matching KEM private key can decapsulate and recover the secret, so the handshake keys derived from that secret only agree if the server is genuine. The server authenticates itself by successfully decapsulating, which the paper builds into a handshake that is proven secure as a whole. The certificate itself is still issued and signed by a certificate authority in the usual way, so the classical or post-quantum signature moves out of the live handshake and up into the certificate chain, where it is computed once at issuance rather than on every connection.
Source: P. Schwabe, D. Stebila, T. Wiggers, “Post-Quantum TLS Without Handshake Signatures,” ACM CCS 2020, ePrint 2020/534, eprint.iacr.org/2020/534.
Why authenticate with a KEM instead of a signature?
The answer is byte counts under post-quantum parameters, and it is the single fact that motivates the whole proposal. When cryptography moves to post-quantum algorithms, the signatures grow far more than the KEMs. The paper states the asymmetry directly: “Among existing post-quantum candidates, signature schemes generally have larger public key/signature sizes compared to the public key/ciphertext sizes of KEMs.” A TLS handshake that authenticates the server by signing therefore carries a large post-quantum signature on every connection, while a handshake that authenticates by encapsulation carries only a compact KEM ciphertext.
Concretely, the difference shows up in two places a network engineer cares about:
- Handshake size. The paper reports that a size-optimized post-quantum KEMTLS handshake “requires less than half the bandwidth of a size-optimized post-quantum instantiation of TLS 1.3.” Fewer bytes in the handshake is exactly the pressure point that makes post-quantum TLS fragile, because oversized handshakes cross the boundaries old middleboxes assumed.
- Server computation. Signing is more expensive than decapsulating for the schemes in play, and the paper measures KEMTLS reducing “the amount of server CPU cycles by almost 90% compared to TLS 1.3,” because the server does a KEM decapsulation rather than a signature generation on each handshake.
Source: P. Schwabe, D. Stebila, T. Wiggers, “Post-Quantum TLS Without Handshake Signatures,” ACM CCS 2020, ePrint 2020/534, eprint.iacr.org/2020/534.
How does implicit authentication change the handshake?
KEMTLS trades explicit authentication for implicit authentication, and that difference is the conceptual heart of the design. In standard TLS 1.3, authentication is explicit: the server sends a signature, and the client runs a signature-verification check that either passes or fails on the spot. In KEMTLS there is no such signature to check. Instead, the client encapsulates a secret to the server’s KEM public key, and the session keys that the client and server derive only match if the server was able to decapsulate that secret with the correct private key. Authentication is a property of the derived keys rather than a discrete verification step.
The practical consequence is a slightly different handshake flow. The client can begin sending data implicitly authenticated to the server after receiving the server’s KEM material, without waiting for a separate signature-and-verify exchange, so KEMTLS keeps the handshake compact without adding a full extra round trip for authentication. The certificate authorities that vouch for the leaf certificate still use signatures, so the trust chain is unchanged above the leaf, and only the server’s own per-handshake proof moves from signing to decapsulating. That relocation is why the expensive post-quantum signature is paid once at certificate issuance instead of on every connection to the server.
Source: P. Schwabe, D. Stebila, T. Wiggers, “Post-Quantum TLS Without Handshake Signatures,” ACM CCS 2020, ePrint 2020/534, eprint.iacr.org/2020/534.
Is KEMTLS a standard, and how does it compare to deployed PQC TLS?
KEMTLS is a research proposal, published and peer-reviewed at a major academic venue but not adopted as an IETF standard, and it is not what production systems deploy today. The deployed post-quantum authentication path keeps the ordinary TLS 1.3 handshake and re-signs certificates with post-quantum or hybrid signatures such as ML-DSA, while KEMTLS changes the handshake’s structure itself. Both aim at the same problem, that post-quantum authentication is byte-heavy, and they answer it in opposite directions.
| Deployed PQC TLS 1.3 | KEMTLS | |
|---|---|---|
| Server authentication | Post-quantum or hybrid signature in the handshake | KEM encapsulation to a KEM key in the certificate |
| What the server does per handshake | Signs the transcript | Decapsulates a client ciphertext |
| Authentication style | Explicit, verify a signature | Implicit, derived keys only agree if the server decapsulates |
| Standardization | Standardized handshake, PQC signatures via composite certificates and PQC signature RFCs | Research proposal, not an IETF standard |
| Main win | Reuses the existing TLS 1.3 handshake unchanged | Cuts handshake bytes and server work |
The reason the ecosystem went with signatures despite KEMTLS’s byte savings is compatibility: keeping the standard TLS 1.3 handshake and only swapping the signature algorithm is a smaller change to a protocol the entire internet already speaks, so it deploys through the machinery covered in TLS 1.3 Hybrid Key Exchange and Composite Certificates. KEMTLS remains valuable as the clearest statement of the tradeoff, and as a design worth revisiting for constrained settings where the handshake byte count dominates everything else.
Source: P. Schwabe, D. Stebila, T. Wiggers, “Post-Quantum TLS Without Handshake Signatures,” ACM CCS 2020, ePrint 2020/534, eprint.iacr.org/2020/534.
Common misconceptions
- “KEMTLS is a version of TLS you can enable.” It is a research proposal from ACM CCS 2020, not an IETF standard. Production post-quantum TLS keeps the standard 1.3 handshake and swaps in post-quantum signatures instead.
- “KEMTLS removes signatures entirely.” It removes the server’s per-handshake signature. The certificate authorities that sign the leaf certificate still use signatures, so the trust chain above the leaf is unchanged; only the live handshake stops signing.
- “Authenticating with a KEM is less secure than a signature.” KEMTLS is proven secure as a handshake. The authentication is implicit rather than explicit, meaning the server is authenticated by being able to decapsulate, and the paper’s analysis covers that structure.
- “The point of KEMTLS is speed on the wire.” The point is byte count under post-quantum parameters, where signatures are much larger than KEM ciphertexts. The server-CPU saving is a second benefit, since decapsulating is cheaper than signing.
- “KEMTLS competes with hybrid key exchange.” They address different halves. Hybrid key exchange is about confidentiality of the session key, and KEMTLS is about authentication of the server. KEMTLS still needs a key exchange; it changes how the server proves who it is.
Questions people ask
What is KEMTLS? It is a research proposal by Schwabe, Stebila, and Wiggers to authenticate the TLS server with a key-encapsulation mechanism instead of a handshake signature, presented at ACM CCS 2020.
Why would you authenticate TLS with a KEM instead of a signature? Because under post-quantum parameters the KEMs are much smaller than the signatures, so authenticating by encapsulation sends far fewer bytes and costs the server far less computation than authenticating by signing.
Does KEMTLS get rid of certificates? No. The server still has a certificate, but it carries a KEM public key instead of a signature key, and a certificate authority still signs that certificate. Only the server’s own per-handshake proof changes from signing to decapsulating.
Is KEMTLS deployed anywhere? It is a peer-reviewed research design, not an IETF standard, and production systems do not run it. Deployed post-quantum TLS keeps the standard 1.3 handshake and uses post-quantum or hybrid signatures such as ML-DSA.
How much smaller is a KEMTLS handshake? The paper reports a size-optimized KEMTLS handshake at less than half the bandwidth of a size-optimized post-quantum TLS 1.3 handshake, and about 90% fewer server CPU cycles.
What is implicit authentication in KEMTLS? The server is authenticated not by a signature the client verifies, but by the fact that the derived session keys only agree if the server could decapsulate the client’s ciphertext with the right private key. Successful decapsulation is the proof.
Everything here is the map, given freely. When your team needs its own TLS termination points, certificate chains, and authentication surfaces assessed for a post-quantum path, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.