-
Notifications
You must be signed in to change notification settings - Fork 126
Integrating PQC into TLS 1.3
Although the final TLS 1.3 specification approved by the IETF doesn't support quantum-safe cryptography, it could be added with extensions thanks to TLS 1.3's modular design.
OpenSSL 1.1.1's master branch implements the TLS 1.3 protocol. Our OQS-OpenSSL_1_1_1-stable branch provides an experimental integration of quantum-safe cryptography into TLS 1.3 key, supporting post-quantum key exchange and authentication, both stand-alone and in hybrid mode (i.e., in combination with a classical scheme).
In what follows, we will be referring to the paper "Prototyping post-quantum and hybrid key exchange and authentication in TLS and SSH" as [NISTPQC:CroPaqSte19].
Sections 3.2.1, 3.2.2 and 3.2.3 of [NISTPQC:CroPaqSte19] broadly describe how post-quantum key-exchanges were integrated into TLS 1.3. Additional notes follow.
The SSL layer expects a DH-style API, and calls into the crypto layer using a DH "generate key" and "generate message" interface. Post-quantum KEMs, on the other hand, present a 3-step API, and moreover, the lower-level crypto API doesn't have the context of the SSL-level caller, so we can't know if we are being called from the client or the server side. Because of these limitations, we can't integrate our post-quantum KEMs cleanly at the crypto layer, and must instead do so at the SSL layer itself, forwarding calls to liboqs as needed. This has been done in the ssl/extensions_srvr.c and ssl/extensions_clnt.c files, where the key_share extension is processed.
ssl/ext_oqs_extra.h also contains additional logic for processing hybrid key-exchanges.
Sections 4.1.1, 4.1.2 and 4.1.3 of [NISTPQC:CroPaqSte19] broadly describe how post-quantum digital signatures were integrated into TLS 1.3. Additional notes follow.
We followed the pattern of the ED25519/ED448 to integrate liboqs's signature schemes. This results in a deeper integration into the crypto layer that allows all the functionality (signature, cert management, TLS auth) to be supported.
Hybrid authentication is also supported. In that case, a classical and a PQ signature are generated on the same data, and the resulting signatures are concatenated; the classical and PQC keys are also concatenated when serialized. The signed data is first hashed using the SHA-2 hash function matching the security level of the OQS scheme (SHA256 for L1, SHA384 for L2/L3, SHA512 for L4/L5) before being signed by the classical algorithm (which can't support arbitrarily long messages), and is passed directly to the liboqs signature API. For details, see the crypto/ec/oqs_meth.c file.
Our integration is also conformant with https://tools.ietf.org/html/draft-ietf-tls-hybrid-design-00; for the curve IDs, code-points, and OIDs we have chosen for our post-quantum algorithms, consult: https://github.com/open-quantum-safe/openssl/blob/OQS-OpenSSL_1_1_1-stable/oqs-template/oqs-kem-info.md and https://github.com/open-quantum-safe/openssl/blob/OQS-OpenSSL_1_1_1-stable/oqs-template/oqs-sig-info.md