Post-quantum Hybrid ECDHE-SCloud+ Key Exchange for TLS 1.3

Cryptographically-relevant quantum computers (CRQCs) pose a threat to cryptographically protected data. In particular, the so-called harvest-now-and-decrypt-later (HNDL) attack is considered as an imminent threat. As post-quantum (PQ) algorithms are still relatively new, it is more conservative to mitigate the quantum threat via hybrid approach. This is in particular the case for key exchange. As introduced in , PQ and traditional hybrid key encapsulation mechanisms (KEMs) have been proposed to achieve secure key exchange if at least one of the KEMs is still secure. For Transport Layer Security (TLS) protocol version 1.3 (TLS 1.3), Hybrid Key Exchange in TLS 1.3 specifies the framework of hybrid key exchange in TLS 1.3 via concatenation-based approach. Namely, each combination of hybrid key exchange is viewed as a single new key exchange method, negotiated and transmitted using the existing TLS 1.3 mechanisms. This approach no only achieves the primary security goal of hyrid key exchange mentioned in the above, but also has the benefits of backwards compatibility, high performance, low latency, and no extra round trips (refer to Section 1.5 of ). Following the approach, two specifications are proposed to instantiate the combinations of ECDHE with ML-KEM, and SM2 with ML-KEM: Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 and Hybrid Post-quantum Key Exchange SM2-MLKEM for TLSv1.3 . This draft specifies how to instantiate hybrid key exchage framework in TLS 1.3 by concatenating traditional ECDHE and PQ Scloud+ KEM. Scloud+ is an unstructured lattice based KEM with post-quantum security. An early version of SCloud+ is available at , while the previous algorithm called SCloud is available at . Scloud+ (and also its previous version SCloud) is based on unstructured-LWE problem (i.e., without algebraic structures such as rings or modules). A notable advantage of the unstructured-LWE problem is its resistance to potential attacks exploiting algebraic structures, which makes it a conservative choice for constructing high-security schemes. However, a key disadvantage of such schemes is their limited computational and communication efficiency. Compared to Scloud , Scloud+ employs ternary secrets and lattice coding to enhance performance. In more detail, Scloud+ utilizes ternary secrets and BW32 lattice codes to enhance noise control and ensure robust error correction during decryption, enabling smaller parameters while maintaining low decryption failure probabilities. Equipped with these techniques, Scloud+ exhibits a significant improvement in efficiency. When compared with FrodoKEM for parameter sets targeting 128, 192, and 256 bits of security respectively, Scloud+ achieves better performance by reducing the size of public key and ciphertext from 17.5 to 34.5 percent. The encapsulation plus decapsulation time is reduced about 24 percent.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Key encapsulation mechanism (KEM) is a kind of key exchange, which allows one entity to encapsulate a secret key under a (long-term or ephemeral) public key of another entity. A KEM consists of three algorithms:

KeyGen(k) -> (pk, sk): A probabilistic key generation algorithm, which generates a public encapsulation key pk and a secret decapsulation key sk, when a security parameter k is given.
Encaps(pk) -> (ct, ss): A probabilistic encapsulation algorithm, which takes as input a public encapsulation key pk and outputs a ciphertext ct and a shared secret ss.
Decaps(sk, ct) -> ss: A decapsulation algorithm, which takes as input a secret decapsulation key sk and ciphertext ct and outputs a shared secret ss.

Among the post-quantum KEM schemes, those based on the learning with errors (LWE) problem have gained particularly prevalent. It has been proven that the LWE problem is at least as hard as the approximate shortest vector problem (SVP) and the shortest independent vectors problem (SIVP) on lattices, which remain difficult even in the sense of quantum computing. This reduction also establishes the average-case hardness of LWE, making it a strong candidate for cryptographic constructions. These schemes can be broadly divided into two categories, depending on whether they introduce algebraic structure into the LWE problem. The first category includes schemes built on variants of the LWE problem that incorporate algebraic structures (referred to as structured-LWE or structured lattices), such as the Ring-LWE problem and the Module-LWE problem. The most well known scheme in this category is the NIST standard algorithm ML-KEM , whic was originally called Kyber. It is a Module-Lattice based Key-Encapsulation Mechanism, so called ML-KEM. The second category includes KEMs that base their security purely on the hardness of the LWE problem without any additional algebraic structure (referred to as unstructured-LWE or unstructured lattices). These schemes, such as FrodoKEM , are considered to offer conservative security, as explained below. The primary benefit of introducing algebraic structure is that it enable to construct more compact LWE-based schemes, i.e., more efficient in terms of computation and communication complexity. However, the algebraic structure also complicates the ability to reduce the hardness of the structured-LWE problems to the hardness of random lattice problems (which lack such structure), such as the approximate SVP and SIVP. Recent research results demonstrate efficient quantum algorithms for the approximate Ideal-SVP, which is related to strucured lattice schemes. Although it seems unlikely that these approaches can be directly extended to address the approximate Module-SVP or the Ring-LWE/Module-LWE problems, it remains unclear about the impact of algebraic structure on the security of structured-LWE KEMs（Section 1 of ).

Now, FrodoKEM is one of three KEMs in the process of ISO standardization . Its security is based on a well-studied LWE hard problem in unstructured lattices. The algorithm details of FrodoKEM are also specified as an Internet draft in CFRG by . German BSI considers FrodoKEM to be 'suitable for protecting confidential information over the long term'，while French ANSSI 'encourages including FrodoKEM as a valid and conservative option for high-security applications.' FrodoKEM is built on the plain LWE encryption framework. Specifically, FrodoKEM operates with matrix-matrix multiplication modulo a power-of-2 q. In its key generation and encryption, S, U, and E are set to be matrices so that a ciphertext can pack more message bits. Additionally, FrodoKEM uses rounded Gaussian error sampling, which adheres to the plain LWE problem. This is implemented by constructing a table to store the cumulative distribution function and performing error sampling via table lookup.

As discussed in , unstructured-LWE based KEMs offer conservative security, compared with structured-LWE based KEMs. However, a key disadvantage of such schemes is that their computation and communication efficiency is much worse than that of structured-LWE-based schemes, posing a major obstacle to their deployment in practical systems. As analyzed in , the size of public key and ciphertext for FrodoKEM is about 13 times of that of ML-KEM . Similar to FrodoKEM, Scloud+ is also an unstructured lattice based KEM with post-quantum security. An early version of SCloud+ is available at , while the previous algorithm called SCloud is available at . In a nutshell, Scloud+ leverages two particular techniques to significantly enhance both computational and communication efficiencyternary secrets and lattice coding: ternary secrets and lattice coding. A ternary secret, where each entry is select from {0,1,-1}, can be used to significantly reduce parameter sizes and improve the scheme’s efficiency. Ternary secrets have been widely used in homomorphic encryption schemes . For all parameters, Scloud+ employs a ternary secret with a Hamming weight equal to half its length. In unstructured-LWE-based schemes, two of the most time-consuming operations are the generation of the matrix A and the matrix-vector multiplication As. Employing a ternary secret in Scloud+ improves noise control during decryption, enabling the use of a smaller ciphertext modulus to ensure correct decryption. This provides an opportunity to reduce matrix sizes while maintaining the same security level, thereby facilitating faster matrix sampling and more efficient matrix-vector multiplication for implementation. Furthermore, fixing the Hamming weight of the secret to half its length prevents it from becoming overly sparse, addressing potential security concerns for sparse-secret LWE. Lattice Coding: Scloud+ designs a robust error correction method based on BW32 (BW for Barnes-Wall) lattice codes, ensuring a smaller choice of parameters while maintaining the appropriate decryption failure probability. While the use of lattice coding is common in LWE-based constructions, previous schemes often involve lattice codes with dimensions 4 to 16. Although larger-dimensional lattice codes generally offer better signal-to-noise ratios and thus stronger error correction capabilities, they require specially designed labeling and delabeling processes to efficiently map the message to the lattice code or vice versa, which poses a chal-lenge for high-dimensional lattice codes. Scloud+ overcomes this by designing efficient labeling and delabeling for Barnes-Wall lattice codes, enabling the use of 32-dimensional lattice codes for error correction without compromising the scheme’s perfor-mance.

Scloud+ provides three sets of parameters, targeting 128, 192, and 256 bits of security, which are correpsonding to NIST level 1, 3 and 5 security, respectively. Benefiting from killfully using ternary secrets and BW32 lattice codes, Scloud+ achieves a very flexible parameter selection and maintains a moderate security margin (about 88 bits) for all sets of parameters while ensuring the conformed decryption failure probability. The security of Scloud+ is comprehensively analyzed using potentially the most effective attacks for LWE, including primal attack, dual attack, and hybrid attack . As shown in Table 1 and Table 2, compared to FrodoKEM, Scloud+ achieves better performance. About the size of public key and ciphertext, the corresponding size of Scloud+ is shorter than that of FrodoKEM for 34.5%, 30%, and 17.5%, for security level 1, 3, and 5, respectively. Similarly, about the corresponding computation cost for encapsulation and decapsulation together, Scloud+ is less than that of FrodoKEM for 26%, 22.5%, and 24.5%, for security level 1, 3, and 5, respectively. Note that here, computation cost is treated as the same as operation efficiency (in 10^3 cycles) shown in Table 2, where are obtained using x86 platform .

As specified in , each particular combination of a hybrid key exchange is represented as a NamedGroup and sent in the supported_groups extension in TLS 1.3. No internal structure or grammar is implied or required in the value of the identifier; they are simply opaque identifiers. This section describes the client's and server's key_exchange values for each of the three hybrids of ECDHE-Scloud+. Namely, the X25519 , SecP256r1 (NIST P-256) , and SecP384r1 (NIST P-384) is combining with Scloud+-126, Scloud+-192 and Scloud+-256, respectively. Correspondingly, these groups are called X25519SCloud+128, SecP256r1SCloud+192, and SecP384r1SCloud+256. In more detail, when each of these three groups is negotiated, the client's key_exchange value is the concatenation of the client's ECDH ephemeral share and the SCloud+ encapsulation key. The exact size of the client share is shown in Table 3, for all three groups. Similarly, when each of these three groups is negotiated, the server's key_exchange value is the concatenation of the server's ECDH ephemeral share and the SCloud+ encapsulated ciphertex. The exact size of the client share is shown in Table 3, for all three groups.

The shared secret is also just the the concatenation of the ECDHE shared secret and the SCloud+ shared secret. Namely, the size of shared secret are 48 (32+16), 56 (32+24), and 80 (48+32) bytes, for X25519SCloud+128, SecP256r1SCloud+192, and SecP384r1SCloud+256, respectively. These numbers are also shown in Table 3. As highligted in , "for all groups, both client and server MUST calculate the ECDH part of the shared secret as described in Section 7.4.2 of , including the all-zero shared secret check for X25519, and abort the connection with an illegal_parameter alert if it fails."

As SCloud+ is shown as an IND-CCA secure post-quantum KEM scheme. So, the security considerations given in apply here as well. At the time of writing, there are no other security issues which may need to be considered here.

Table 3 below gives the list of 3 IANA values for the 3 hybrid combination with ECDHE and SCloud+. These values are to be assigned by IANA, and registered under the "TLS Supported Groups" registry of Transport Layer Security (TLS) Parameters .

...