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

Cryptographically relevant quantum computers (CRQC) may pose a threat to data protected using conventional cryptographic means in the near future. The harvest-now decrypt-later (HNDL) attack threatens existing data even in the absence of a CRCQ because the data can be stored until such time that one CRCQ becomes available. As introduced in , hybrid mechanisms that combine post-quantum (PQ) and traditional KEMs ensure continuing security even if one of the algorithms becomes insecure. "Hybrid key exchange in TLS 1.3" specifies the framework of concatenation-based approach. In this approach, 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 not only achieves the primary security goal of hybrid key exchange mentioned 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 this 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 exchange in TLS 1.3 using ECDHE and the post-quantum secure KEM SCloud+ . SCloud+ and its predecessor SCloud are based on the unstructured LWE problem. The absence of algebraic structure, such as rings or modules, in these algorithms presumes a higher level of security than for algorithms based on structured lattices, such as ML-KEM , in the event of attacks that exploit structure are devised. The downside of this conservative approach is reduced computational and communication efficiency. SCloud+ utilizes ternary secrets and lattice codes to enhance noise control and ensure robust error correction during decryption, enabling smaller parameters while maintaining low decryption failure probabilities. Compared with FrodoKEM , a well-known PQ KEM based on the unstructured LWE problem, SCloud+ reduces the size of public key and ciphertext from between 17 to 34 percent, depending on the chosen parameter set. 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 become 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) in 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 algebraic structure is introduceed into the LWE problem. The first category includes schemes built on variants of the LWE problem that incorporate algebraic structured, such as the Ring-LWE and Module-LWE problems. These structured lattice schemes include the well known NIST standard ML-KEM (ML referring to Module-Lattice). The second category are KEMs whose security are based on hardness of the LWE problem without any algebraic structure. These unstructured lattice schemes, include FrodoKEM , which is well known for its conservative security. The main benefit of introducing algebraic structure is to make LWE-based schemes more compact, i.e., more efficient in both aspects of computation and communication complexity. However, the algebraic structure also complicates the procedures of reducing the structured-LWE problems to the 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 structured 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 ).

FrodoKEM is built on the plain LWE encryption framework，namely, in algebraically unstructured lattices. Specifically, FrodoKEM operates with matrix-matrix multiplication modulo a power-of-2 q. In its key generation and encryption, several variables (e.g., 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. FrodoKEM is now one of three KEMs in the process of ISO standardization . 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.' However, the computation and communication efficiency of FrodoKEM is much worse than that of ML-KEM. As analyzed in , the size of public key and ciphertext for FrodoKEM is about 13 times of that of ML-KEM. This poses a major obstacle to their deployment in practical systems.

Similar to FrodoKEM, SCloud+ is also an unstructured lattice based KEM with post-quantum security. In a nutshell, SCloud+ leverages two particular techniques to significantly enhance both computation and communication efficiency: ternary secrets and lattice coding. A ternary secret, where each entry is selected 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 of its length. In unstructured-LWE-based schemes, two of the most time-consuming operations are the generation of matrix and the matrix-vector multiplication. Employing a ternary secret in SCloud+ improves noise control during decryption and thus enables to use a smaller ciphertext modulus ensuring 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. Furthermore, setting the Hamming weight of the secret to half of its length prevents it from becoming overly sparse, and also addresses potential security concerns on sparse-secret LWE. Lattice Coding: SCloud+ carefully selects a robust error correction method to ensure a smaller choice of parameters while maintaining a proper decryption failure probability. While the use of lattice coding is common in LWE-based constructions, previous schemes often involve lattice codes with small dimensions (4 to 16, normally). Although larger-dimensional lattice codes generally offer better signal-to-noise ratios and thus stronger error correction capabilities, they require specially designed processes to efficiently map the message to the lattice code or vice versa, which poses a challenge for high-dimensional lattice codes. SCloud+ overcomes this challenge 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 performance.

FrodoKEM has 12 variants with IND-CCA security. Namely, it offers 3 NIST security levels 1, 3, and 5; the pseudorandom generator (PRG) uses AES128 or SHAKE 128; and the KEM public key can be a long-term key (standard mode) or a short-term key (ephemeral mode). Here, just FrodoKEM (standard mode), rather than eFrodoKEM, is compared with SCloud+, regardless the PRG is AES128 or SHAKE 128. SCloud+ provides three sets of parameters, targeting 128, 192, and 256 bits of security, which are correpsonding to NIST levels 1, 3 and 5 security, respectively. Benefiting from ternary secrets and Barnes-Wall lattice codes which are carefully selected, SCloud+ achieves a very flexible parameter selection and maintains a moderate security margins (about 88 bits) for all sets of parameters while ensuring the conformed decryption failure probability. The IND-CCA security of SCloud+ is shown, and also comprehensively analyzed using potentially the most effective attacks for LWE, including primal attack, dual attack, and hybrid attack in . As demonstrated in Table 1 and Table 2, compared to FrodoKEM, SCloud+ achieves better performance in both aspects of communications and computation. Here, the original size numbers in Table 1 come from Table A.5 in , and Table 6 in . About the total length 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 levels 1, 3, and 5, respectively. As shown in Table 2, for the corresponding computation cost for encapsulation and decapsulation together, SCloud+ is less than that of FrodoKEM for 24.5%, 16%, and 26%, for security levels 1, 3, and 5, respectively. These original numbers come from Tables 5 and 7 in . Note that here, computation cost is treated as the same as operation efficiency (in 10^3 cycles) shown in Table 2, based on 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 following three hybrids of ECDHE-SCloud+:

X25519SCloud+128: X25519 is combined with SCloud+-128.
SecP256r1SCloud+192: SecP256r1 (NIST P-256) is combined with SCloud+-192.
SecP384r1SCloud+256: SecP384r1 (NIST P-384) is combined with SCloud+-256.

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. 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 ciphertext. The exact size of the server share is also 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 is 48 (32+16) bytes for X25519SCloud+128, 56 (32+24) bytes for SecP256r1SCloud+192, and 80 (48+32) bytes for SecP384r1SCloud+256. These numbers are also shown in Table 3. As highlighted 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 , the security analysis given in applies here as well. At the time of writing, there are no other security issues which may need to be considered here.

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

...