Hybrid KEMTLS using Identity-Based KEMs

February 22, 2023

Abstract
We present a construction of an hybrid version of KEMTLS where we
combine both a post-quantum IBE and a classical PKI key enchapsulation
mechanism (KEM). Mixing both kind of primitives, we present experi-
mental results showing that this construction can achieve better network
timings when compared with other hybrid TLS constructions. Moreover,
we also can deal with problems that IBE constructions struggle with, like
how to revoke identities, and how to deal to some extend with the key
escrow problem. This is done at the coast of forsaking some properties
usually associated with IBE, like avoiding the use of certificates.

1 Introduction
The Transport Layer Security (TLS) is one of the most used cryptographic pro-
tocol designed to provide communications security over a computer network. It
is widely used over the Internet to transfer web pages and to secure connections
between machines. After the protocol is run, even over untrusted channels,
both the client and the server are able to exchange encrypted messages se-
curely. The full specification for TLS 1.3, the most recent version, is provided
in RFC8446 [10].
To use TLS, we usually require a public key infrastructure (PKI). When the
client and the server are exchanging messages following the protocol, the server
sends a certificate chain to the client containing its public key and a chain of
signed certificates where each one provides its own key for signature verification
and the last certificate is self-signed by a trusted Certificate Authority (CA).
In TLS 1.3, clients and servers can exchange a shared secret using a single
round trip based on Diffie-Hellman key agreement protocol. The previous ver-
sion, TLS 1.2 had a different authentication mechanism that required an extra
round trip. Before version 1.3, several other proposals were made trying to
improve the protocol. In [9] a proposal was made trying to use identity-based
cryptography in TLS. The paper showed that an IBE-based TLS using bilinear
pairings would require less data to be transferred over the network at the coast
of requiring more expensive computations. One of the main selling points of
identity-based encryption, which was advocated by earlier proposals was that it
did not require certificates. Instead of this, a web page URL could be used as

1
the server public key and a central authority could derive the associated secret
key and transfer it to the correct server that owns that page.
However, identity-based TLS was not sufficient attractive to be used. The
improvement in network timings for classical TLS was interesting, but the ben-
efit was not enough to justify the drawbacks and the changes in infrastructure.
Using IBE in TLS requires us to deal with the following challenges:

• Revocation: If a secret key is compromised, how can we revoke it without

revoking the identity? While efficient revocation is a well-studied problem
for PKI, there is much less studies and sollutions in the IBE case.
A simple solution for this problem would be append the current time
period to the identity string and always regenerate a new key after we are
not in that time interval as proposed in [3]. However, to minimize the
damage when a key is compromised, this would require the time period
to be very short (the original paper suggested updating the keys once per
day), which is not pratical for TLS. Instead, one could also use a random
string instead of a time interval, but this reintroduce certificates, as these
random strings needs to be authenticated.
Several other solutions were proposed ( [8], [2]), but they are not ade-
quate for TLS, either because they are not general, because they would
require too much state to be stored or because they introduce the need of
communication between servers and mediators to decrypt messages.
• Key Escrow: In an IBE scheme, the secret keys are generated by a
central authority, the Private Key Generator (PKG) that distributes them
to the correct owners based on their identity. This means that this central
authority will know all the secret keys. This is undesirable for TLS, as
compromising the PKG would compromise all communications for which
they produced the keys. Even if we try to mitigate this using hybrid
constructions to mix different IBEs produced by different PKGs, it is not
realistic to assume that corrupting more than one PKG is beyond the
powers of nation-state founded attacks.

Moreover, despite the promise that with IBE we could dismiss certificates, in
practice this is very hard to be achieved. Public keys are not the only thing that
requires certification. In an IBE-based protocol, the server would need to inform
the client about which PKG it is using. The message with this information also
should be authenticated somehow.

1.1 Post-quantum TLS

With the possible advent of a Cryptographically Relevant Quantum Computer
(CRQC), the current TLS 1.3 specification would not be secure anymore, as the
Diffie-Hellman Computational Problem can be easily broken given a sufficiently
powerful quantum computer with known algorithms. This motivates several new

2
proposals about how can we change TLS to keep it safe, even if such CRQC is
built.
The main problem of such change is that post-quantum cryptographic algo-
rithms are not so well studied and tested as the classical constructions based on
elliptic curves and RSA. Starting in 2016, NIST began a post-quantum cryptog-
raphy standardization program where a competition between several candidates
took place. Only in 2022, NIST announced five post-quantum algorithms that
could be standardized, while selecting four others to pass to another round of
tests and studies. The novelty of such algorithms makes people cautious of sim-
ply replacing what we already have, algorithms that endured decades of attacks
and scrutiny, by proposals that are so recent.
A solution for this dilemma is using hybrid schemes: a classical and a post-
quantum scheme are combined in such a way that if only one of them is secure,
the entire scheme is secure. Some papers with these proposals and their perfor-
mance results can be seen in [4].
Another problem from post-quantum algorithms is that several proposals
have bigger keys or produce bigger signatures, requiring more bandwidth to
be used. One proposal to lower the bandwidth requirement is the KEMTLS
protocol, where a post-quantum key encapsulation mechanism (KEM) instead
of post-quantum signatures [11]. This makes the gap smaller between the sizes
from classical implementations and post-quantum ones.
Finally, the possible change to post-quantum algorithms renewed the inter-
est in IBE model. In [1] new experiments showed that like in the classical model,
when considering only post-quantum constructions, IBE schemes also requires
less bandwidth, but require more computational timings. However, the sav-
ings in network timings are much bigger and the performance cost is relatively
smaller. As it is not known how to deal satisfactorily with some of the IBE
problems like the revocation in general usage, the paper suggested to use IBE
in post-quantum versions of TLS aimed at wireless sensors networks. In [12]
more experiments comparing timings from IBE and PKI constructions in the
context of IOT environments are presented. An hybrid IBE construction is also
considered.
Our proposal: We built a hybrid version of KEMTLS, but instead of
just mixing a classical and a post-quantum construction, we mix two slightly
different primitives: a classical PKI-based KEM and a post-quantum IBE KEM.
The rationale for this mix is the data from [1] that show that IBE is much more
attractive in the post-quantum scenario than in the classical one. We use IBE
construction as a way to lower badwidth requeriments in hybrid constructions.
Because of the PKI classical construction, we still require certificates. But these
certificates would not be much bigger than certificates that we already use, based
on P256 curves. Because the post-quantum part of the scheme uses IBE, we
do not neet to put their public keys in the certificate, but we still can use it to
authenticate other relevant data, like the the chosen PKG, or perhaps a random
string that should be attached to the identity. This random string could be
changed if the IBE secret key is compromised, and the revocation mechanisms
would not need to be different than what we already have.

3
2 Preliminaries
2.1 Key Enchapsulation Mechanisms (KEMs)
A Key Enchapsulation Mechanism (KEM) is a tuple of three algorithms (KEM.Keygen,
KEM.Encaps, KEM.Decaps) defined as follows:

• KEM.KeyGen(1λ ) → (pk, sk): Given the security parameter 1λ , this

probabilistic polinomially-bounded algorithm produces a secret key sk and
a public key pk.
• KEM.Encaps(pk) → (k, c): Given a public key pk, this probabilistic
polinomially-bounded algorithm produces a secret k and a ciphertext c.

• KEM.Decaps(sk, c) → k: Given a secret key sk and a ciphertext, this

deterministic polinomially-bounded algorithm produces a secret k.

It is required that if a given pair (k, c) was produced by the encapsulation

algorithm using some public-key, then passing to the decapsulation algorithm
the corresponding secret key and the ciphertext c, allows us to recover the secret
k as result. For a secure KEM, we expect that no adversary is able to distinguish
between the correct secret k associated with a known ciphertext c and a random
value k ′ taken from some distribution (IND-CPA model), except with negligible
probability. If no adversary is able to distinguish between then, even having
access to an oracle than run KEM.Decaps(sk, ·) in any data different than c,
then the KEM is secure in the IND-CCA model.
When using KEMs in the context of key exchange, we usually expect that
each user has its own pair of keys (pk, sk) and these keys were produced inde-
pendently from the user identity. Therefore, if a machine in a network claims to
be someone and present its key pk, we cannot be sure that this is true and that
this key pk indeed is the key associated with the claimed identity. To solve this
problem, we use certificates: data containing both the key pk and the identity
of its owner, all signed by some trusted authority.

2.2 Identity Based KEMs

An identity-based Key Enchapsulation Mechanism (ID-KEM) is a tuple of
FOUR algorithms (IDKEM.Keygen, IDKEM.Extract, IDKEM.Encaps,
IDKEM.Decaps) defined as follows:

• IDKEM.KeyGen(1λ ) → (mpk, msk): Given the security parameter 1λ ,

this probabilistic polinomially-bounded algorithm produces a master se-
cret key msk and a master public key mpk.
• IDKEM.Extract(msk, ID) → skID : Given the master secret key msk
and a string ID, this probabilistic polinomially-bounded algorithm pro-
duces a secret key skID associated with identity ID.

4
 • IDKEM.Encaps(mpk, ID) → (k, c): Given the master public key mpk
and an identity string ID, this probabilistic polinomially-bounded algo-
rithm produces a secret k and a ciphertext c.
• IDKEM.Decaps(skID , c) → k: Given a secret key skID associated with
identity ID and a ciphertext, this deterministic polinomially-bounded al-
gorithm produces a secret k.

It is required that if a given pair (k, c) was produced by the encapsulation al-
gorithm using a given mpk and identity ID, then passing to the decapsulation al-
gorithm the corresponding secret key produced by IDKEM.Extract(msk, ID)
and the ciphertext c, allows us to recover the secret k as result. For a secure
ID-KEM, we expect that no adversary is able to distinguish between the correct
secret k associated with a known ciphertext c and a random value k ′ taken from
some distribution (IND-CPA model) for any identity ID chosen by the adver-
sary, except with negligible probability. The adversary is always able to query
an oracle that computes IDKEM.Extract(msk, ·) for any identity, except the
chosen one. If the scheme keeps this property even if the attacker is also able
to query another oracle that runs IDKEM.Decaps(skID , ·) for the chosen ID,
except that it cannot query de decapsulation of c, then the ID-KEM is also
secure in the IND-CCA model.

2.3 Combiners and Hybrid Constructions

A KEM combiner is a construction of a new KEM combining two other KEMs.
The security property expected from a combiner is that the produced KEM must
remain secure even if one of the original KEMs is insecure. Combiners are used
to produce hybrid schemes that mix classical and post-quantum algorithms.
A study of several KEM combiners and their security definition can be found
in [7]. We test in our proposal two of the proposed combiners for KEMs: the
Dual-PRF combiner and the Xor-then-MAC combiner.

2.4 The KEMTLS Protocol

3 Our Hybrid KEMTL Proposal

3.1 The Proposed Hybrid KEM Scheme
Both PKI-based KEMs and identity-based KEMs are slightly different crypto-
graphic primitives. Therefore, mixing the two produces another scheme with
properties from both. The resulting scheme is a tuple composed by five algo-
rithms: (HKEM.M asterKeyGen, HKEM.LocalKeyGen, HKEM.Extract,
HKEM.Encaps, HKEM.Decaps). Assuming that the hybrid scheme was built
from a PKI-based KEM and an identity-based IDKEM , the algorithms are
defined as below:

5
 • HKEM.M asterKeyGen(1λ ) → (mpk, msk): The key generation algo-
rithm that produces the master public key and master secret key. It is
identical to the IDKEM.KeyGen algorithm.
• HKEM.LocalKeyGen(1λ ) → (pk, sk): The key generation that will be
run locally for each user. This algorithm is identical to the KEM.KeyGen
algorithm.
• HKEM.Extract(msk, ID) → skID : Given the master secret key and an
identity, generates a secret key corresponding to the identity. It is identical
to the IDKEM.Extract algorithm.
• HKEM.Encaps(mpk, pk, ID) → (k, c): This polinomially-bounded prob-
abilistic algorithm, given the master public key mpk, a public key pk and
an identity string ID produces a secret k and a ciphertext c that encap-
sulates securely the given secret.
• KEM.Decaps(skID , sk, c) → k: This polinomially-bounded deterministic
algorithm, given the secret key associated with identity ID, a second
secret key sk and a ciphertext c, returns the secret k encapsulated in the
ciphertext.

As the first three algorithms are the same than algorithms already present
in the KEM and IDKEM schemes, we just need to define how to build the
encapsulation and decapsulation algorithms. Adapting the Xor-then-MAC con-
struction from [7], we can define them as:

• HKEM.Encaps(mpk, pk, ID) :

1. (c1 , k1a ||k1b ) ← KEM.Encaps(pk)
2. (c2 , k2a ||k2b ) ← IDKEM.Encaps(mpk, ID)
3. kkem ← k1a ⊕ k2a
4. kmac ← k1b ||k2b
5. c ← (c1 , c2 )
6. t ← M ACkmac (c)
7. return ((c, t), kkem )

• HKEM.Decaps(skiID , sk, (c, t)) :

1. (c1 , c2 ) ← c
2. k1a ||k1b ← KEM.Decaps(sk, c1 )
3. k2a ||k2b ← IDKEM.Decaps(skID , c2 )
4. kkem ← k1a ⊕ k2a
5. kmac ← k1b ||k2b
6. if t ̸= M ACkmac (c):

6
 7. return ⊥
8. else:
9. return kkem

A second option is use the Dual-PRF combiner, also described in [7]. In

this construction we assume that we have a dual PRF, which produces a cryp-
tographically secure random value, provided that at least one of its inputs are
random. The adapted version of this combiner for our construction is given
below:

• HKEM.Encaps(mpk, pk, ID) :

1. (c1 , k1 ) ← KEM.Encaps(pk)
2. (c2 , k2 ) ← IDKEM.Encaps(mpk, ID)
3. c ← (c1 , c2 )
4. kd ← dP RF (k1 , k2 )
5. k ← P RF (kd , c)
6. return (c, k)

• HKEM.Decaps(skID , sk, c) :
1. (c1 , c2 ) ← c
2. k1 ← KEM.Decaps(sk, c1 )
3. k2 ← IDKEM.Decaps(skID , c1 )
4. kd ← dP RF (k1 , k2 )
5. return P RF (kd , c)

3.2 Using Our Hybrid KEM in Key Agreement

To use the KEMTLS protocol, we need two KEMs: one to generate a secret
using ephemeral keys and the other to compute a secret using the long-term
keys from the server (assuming that only the server will need to authenticate).
We can use any IND-CPA secure KEM for the ephemeral usage, but require
an IND-CCA security to compute secrets with the long-ter keys. Our hybrid
construction using a classical PKI-based KEM and a post-quantum IBE KEM
will be used only with long-term keys. For the ephemeral key KEM, we can use
any post-quantum KEM, like Kyber.
The key agreement protocol used by KEMTLS, and adapted to our hybrid
proposal is described below:

1. Client → Server: pkephemeral

First the Client runs KEM.KeyGen(1λ ) to generate the ephemeral key
pairs. It keeps the secret key skephemeral and send the public key pkephemeral
to the server.

7
 2. Server → Client: (cephemeral , Certif icate(pkS , P KG))
Knowing the client’s ephemeral public key pkephemeral , the server can
compute cephemeral running the encapsulation algorithm KEM.Encaps
from the ephemeral KEM. It also sends to the client its public key pkS
and it indicates which PKG will be used in the identity-based part of our
hybrid algorithms. These information are sent with a certificate chain.
3. Client → Server: c
Knowing the server identity, its public key pkS and the correct master
public key mpk, the client can run the encapsulation algorithm from our
hybrid scheme to produce a secret k and an encapsulation c. The encap-
sulation is sent to the server, which can then decapsulate it. After this
step, both the client and the server knows the secrets k and kephemeral .
Both can be hashed, which then produces the shared secret.

Here we assume that the client do not know the server public key pkS .
However, like in the usual KEMTLS, we can reduce the key agreement to a
single round trip if we assume that the client already knows the server and has
the secret key stored in the cache. In this case, the protocol runs as below:

1. Client → Server: (pkephemeral , c)

As before, the client generates new ephemeral keys and sends the ephemeral
public key to the server. But as it already knows the server public key, it
computes a ciphertext c using the hybrid KEM and sends it in the first
message.
2. Server → Client: cephemeral
As before, the server computes a secret encapsulated using the ephemeral
key. It just needs to send this information to the client. After this, both
parties will know both k and kephemeral , computing the missing part with
the decapsulation algorithm. Both secrets are combined to produce the
shared secret.

4 Experiments
To test the performance and viability of our proposal, we modified the KEMTLS
implementation from [5] to use our hybrid construction. For the identity-based
post-quantum KEM, we choosed the DLP-IBE construction proposed at [6] and
used an implementation from Libsafecrypto library after creating Go bindings
for the library. For the classical KEM, we choosed the construction based on
P256 elliptic curve from the Circl library. We also used the Kyber KEM for our
ephemeral key encapsulations, also provided by the Circl library. The combiner
and the adaptation in the KEMTLS were programmed in Go.

8
5 Conclusion
References
[1] Utsav Banerjee and Anantha P Chandrakasan. Efficient post-quantum tls
handshakes using identity-based key exchange from lattices. In ICC 2020-
2020 IEEE International Conference on Communications (ICC), pages 1–6.
IEEE, 2020.
[2] Alexandra Boldyreva, Vipul Goyal, and Virendra Kumar. Identity-based
encryption with efficient revocation. In Proceedings of the 15th ACM con-
ference on Computer and communications security, pages 417–426, 2008.
[3] Dan Boneh and Matt Franklin. Identity-based encryption from the weil
pairing. In Advances in Cryptology—CRYPTO 2001: 21st Annual Inter-
national Cryptology Conference, Santa Barbara, California, USA, August
19–23, 2001 Proceedings, pages 213–229. Springer, 2001.
[4] Joppe W Bos, Craig Costello, Michael Naehrig, and Douglas Stebila. Post-
quantum key exchange for the tls protocol from the ring learning with
errors problem. In 2015 IEEE Symposium on Security and Privacy, pages
553–570. IEEE, 2015.
[5] Sofı́a Celi, Armando Faz-Hernández, Nick Sullivan, Goutam Tamvada,
Luke Valenta, Thom Wiggers, Bas Westerbaan, and Christopher A
Wood. Implementing and measuring kemtls. In Progress in Cryptology–
LATINCRYPT 2021: 7th International Conference on Cryptology and
Information Security in Latin America, Bogotá, Colombia, October 6–8,
2021, Proceedings, pages 88–107. Springer, 2021.
[6] Léo Ducas, Vadim Lyubashevsky, and Thomas Prest. Efficient identity-
based encryption over ntru lattices. In International Conference on the
Theory and Application of Cryptology and Information Security, pages 22–
41. Springer, 2014.
[7] Federico Giacon, Felix Heuer, and Bertram Poettering. Kem combiners. In
Public-Key Cryptography–PKC 2018: 21st IACR International Conference
on Practice and Theory of Public-Key Cryptography, Rio de Janeiro, Brazil,
March 25-29, 2018, Proceedings, Part I 21, pages 190–218. Springer, 2018.
[8] Benoı̂t Libert and Jean-Jacques Quisquater. Efficient revocation and
threshold pairing based cryptosystems. In Proceedings of the twenty-second
annual symposium on Principles of distributed computing, pages 163–171,
2003.
[9] Changyan Peng, Quan Zhang, and Chaojing Tang. Improved tls hand-
shake protocols using identity-based cryptography. In 2009 International
Symposium on Information Engineering and Electronic Commerce, pages
135–139. IEEE, 2009.

9
[10] Eric Rescorla. Rfc 8446: The transport layer security (tls) protocol version
1.3, 2018.
[11] Peter Schwabe, Douglas Stebila, and Thom Wiggers. Post-quantum tls
without handshake signatures. In Proceedings of the 2020 ACM SIGSAC
Conference on Computer and Communications Security, pages 1461–1480,
2020.
[12] Michael Scott. On tls for the internet of things, in a post quantum world.
Cryptology ePrint Archive, 2023.

10