Using Identity-Based KEMs in TLS

Estimating Sizes

Alexandre Augusto Giron, Thiago Astrizi

João Pedro Adami do Nascimento, Victor Valle, Ismael Heinzelmann
Jean Everson Martina, Ricardo Custódio

Laboratório de Segurança em Computação

Universidade Federal de Santa Catarina

12/09/2022
Single Round-Trip: Is it possible?

2/13
 Can we avoid certificates?

• SERVER: - We’ll use IBE. Using central authority A’s master public key.
• CLIENT: - How can I trust and authenticate this choice?

• SERVER: - My secret key was compromised. How can I revoke it?

3/13
But IBE is useful and has interesting properties

4/13
Classical Algorithms: (IBE, PKI) × (Computation, Communication)

5/13
Post-Quantum Algorithms: (IBE, PKI) × (Computation, Communication)

6/13
 Key Exchange: First Message

Client computes ephemeral keys:

(pk, sk) ← KEM.KeyGen()

And sends pk to the server.

If we use Kyber-512, pk has 800 bytes.

TOTAL: 800 bytes

7/13
 Key Exchange: Second Message

Server uses ephemeral key pk to encapsulate a secret:

(ct, kt) ← KEM.Encaps(pk)

And sends ct to the client. It also sends a classical certificate with a classical public
key. The certificate also indicates which KDC we will use for IBE.
If we use Kyber-512, ct has 768 bytes. According with our previous measures, a P256
certificate including PKI components (OCSP, SCT logs) has 1626 bytes.

TOTAL: 800 + (768+1626) = 3194 bytes

8/13
 Key Exchange: Third Message

Client uses server’s public key pks , its identity and the KDC information to encapsulate
in a hybrid scheme:

((c1 , c2 ), k) ← HybridKEM.Encaps(mpk, pks , IDs )

And sends (c1 , c2 ) to the server.
If we use an elliptic curve classical KEM (HPKE-KEM-P256-HKDF-SHA256), c1 has
48 bytes.
If we use a post-quantum KEM based on DLP-IBE, c2 will have 3744 bytes.

TOTAL: 800 + (768+1626) + (48+3744) = 6986 bytes

9/13
• + Algorithms + Metadata + KDC
• mpk is 2944 bytes but probably will not be included

10/13
Previous Measures

11/13
Previous Measures

12/13
 Remarks

• The sizes are competitive.

• We will not have the classical IBE problems (revocation, key escrow)
• Easier transition (we use existing PKI structure)

13/13