Practical Implementations of Quantum-Resistant

Jes´usAntonio Soto Vel´azquez December 18, 2017

Contents

1 Introduction 2

2 Quantum-Safe Hybrid for TLS version 1.3 2 2.1 Idea ...... 3 2.2 Modified TLS steps ...... 4 2.3 Recommendations on the algorithms ...... 5 2.4 On the security aspect ...... 5

3 Incorporation of Quantum-safe Algorithms into OpenSSL 5 3.1 Quantum-safe Key Exchange Mechanism ...... 6 3.2 Open Quantum Safe (OQS) and liboqs ...... 6 3.3 Quantum-Safe KEM in OpenSSL ...... 8 3.3.1 Stebila’s OpenSSL Fork with RLWE ...... 8 3.3.2 Singh’s OpenSSL Fork with RLWE ...... 9 3.3.3 Open Quantum Safe’s OpenSSL Fork ...... 9 3.4 Quantum-safe Authentication ...... 11 3.5 Alternative implementations of TLS ...... 11 3.5.1 wolfSSL ...... 11 3.5.2 BoringSSL ...... 12 3.5.3 PolarSSL ...... 13 3.6 On the difficulty of extending OpenSSL ...... 14

4 Hybrid public keys and signatures in X.509 15 4.1 Proof of concept ...... 16

5 Conclusion 18

1 1 Introduction

The confidentiality and authenticity of today’s communication in the Internet heavily depend on the use of cryptographic primitives and protocols. These cryptographic primitives usually rely on the difficulty of solving a certain problem, e.g., prime factorization and . These problems should be easy to solve for the intended participants who hold the secret pieces of information, but hard to solve for those who only hold the public pieces of information for a particular instance of these problems. Due to Shor’s algorithm, which operates under a quantum computer, the discrete logarithm and prime factorization problems are solvable easily. This means that algorithms such as RSA, Diffie-Hellman Exchange (DHE), Algorithm (DSA), and the elliptic curve variations (ECDHE and ECDSA) can be broken by a quantum computer of enough capacity. It has been predicted that quantum computers [2] will finally be built within a decade. Thus, this calls for the need of employing a new set of algorithms that rely on hard problems that quantum computers cannot break. Such algorithms may be based on hash functions, error correcting codes, lattices (including learning with errors), multivariate equations, and supersingular elliptic curve isogenies. These algorithms already exist, and have been studied in the theoretical setting for long. As we know it is inevitable that quantum computers will eventually be built, it is relevant to consider how to move away from the vulnerable algorithms, and slowly adopt these newer, quantum-resistant1 al- gorithms. This report covers three main topics: adoption of quantum-resistant al- gorithms in the TLS 1.3 protocol, incorporation of quantum-resistant algo- rithms into the OpenSSL library, and the proposal to include multiple public keys and signatures in the X.509 certificate.

2 Quantum-Safe Hybrid Key Exchange for TLS version 1.3

The (TLS) protocol is widely used to ensure se- curity among two parties communicating over the Internet. The underlying algorithms in TLS are approved by governments [8] and organizations, e.g.: NIST SP800-131a, NSA Suite B, ISO standards, etc., and thus, are difficult

1the words quantum-resistant, quantum-safe, and post-quantum are used interchange- ably, and refer to the same security property.

2 to change. As mentioned earlier, these algorithms (ECDHE, DHE, ECDSA, RSA) are easily broken by quantum computers. Alternatives to these algo- rithms do exist, and some of them have shown similar performance results in comparison to the ones adopted in TLS. However, governments have not updated their list of approved algorithms to include these as standards. As November 2017, there is an ongoing effort organized by NIST to find a suite of post-quantum algorithms [12]. To gain some insight as how communications will be affected in the fu- ture, the idea is to incorporate these quantum-resistant algorithms into the TLS protocol. This protocol is compliant to various security requirements, and is also widely used, making it a good candidate for experimentation. Having said that, there is no guarantee that a new attack against these algo- rithms won’t be discovered in the future. Therefore, even if solid alternative algorithms like NTRU and McBits could already be put into TLS, it would be desirable to keep the protocol algorithm-agnostic. In the event that one of these algorithms is broken, it would be easy to replace it with another one. Members of the IETF have proposed a mechanism [22] to incorporate quantum-safe algorithms within the protocol, while ensuring compatibility with the systems in use today.

2.1 Idea The idea behind the proposal is to encapsulate the classic key exchange that takes place in TLS, and in parallel perform another key exchange which relies on a quantum-resistant algorithm. The resulting shared key of this process will be secure in both the classical and quantum settings. This term for this mechanism is coined as Quantum-Safe Hybrid Key Exchange (QSH Key Exchange). The TLS protocol has undergone many changes between versions 1.1, 1.2, and 1.3. Particularly, in the handshake phase of TLS 1.3, Diffie-Hellman Ex- change and ECDHE groups are negotiated between the client and the server. In previous versions, a suite was negotiated between peers. However, negotiating groups can also be useful for the QSH key exchange, because including quantum-safe algorithms would be very similar to having more groups for DHE and ECDHE. Thus, the overall structure of the handshake would remain unchanged, except that now it would include a description of the encoding used to hold the information regarding the new algorithms. Additionally, it is desirable to follow an hybrid approach, so that instances of a TLS protocol would use both the classical and quantum-safe algorithms to generate their respective secrets in parallel. Thus, it was proposed to include a combination of a “classical” key exchange and a “quantum-safe”

3 key exchange for the the handshake part of the protocol. This is called a hybrid key exchange, and it uses multiple key exchange methods in parallel. As an example, consider the hybrid key exchange “+NTRU” proposed by the client to the server. The server would need to accept both key exchanges, not only one of them. It would be problematic if the client could only propose one hybrid group. Thus, the proposal allows for more than one combination, specifically up to 10, so that other ECDHE groups and other quantum-safe algorithms can be considered as alternatives. As more combinations are supported by a server, the more likely it is that a client will recognize at least one of the combinations, letting the TLS pro- tocol proceed as usual. After choosing the combinations of key-exchange mechanisms to use, their outputs can be combined through a (KDF) to obtain a secret key shared by both parties. This implies that as long as one of the negotiated key exchanges is secure, the negotiated keys will remain secure.

2.2 Modified TLS steps In very broad terms, the changes to the protocol can be observed in three steps: initial handshake, creation of pre-master secret, and derivation of secret keys. This procedure is described as follows:

Initial Handshake Client initiates the protocol by sending to server a list of supported groups (for DHE and ECDHE), key shares2, other key exchanges, and hybrid groups (combination of multiple key exchanges).

Server selects one of the combinations proposed by the client, and sends back the reply.

Pre-master secret Client and Server proceed to generate the shared secret as it is done in TLS 1.3, except that this is done for each of the groups proposed during the handshake, in parallel.

Secret keys Client and server concatenate the shared secrets obtained in the previous step, and the result is used to derivate the secret key according to TLS 1.3.

There are some structural changes that should be done to the data sent during the ClientHello and ServerHello, so that it captures the possibility of having one or more hybrid key exchanges. Additionally, a hybrid extension is proposed, so that when the client lists hybrid name groups, it also includes

2share material for key derivation

4 the hybrid extension which defines which “atomic” groups form the hybrid group. Apart from this, these changes are intended to be minimal to the TLS 1.3 protocol.

2.3 Recommendations on the algorithms The proposal makes mention of an initial recommendation made in [14] re- garding which quantum-safe algorithms are deemed good enough to with- stand attacks by quantum computers. Particularly, to obtain roughly a 2128 bit post-quantum level of security, the authors recommend the following vari- ations of some of the well-known quantum-safe algorithms, and also include some parameter recommendations:

McEliece with binary Goppa codes With parameters at least: length n = 6960, dimension k = 5413, and adding t = 119 errors.

McEliece with Quasi-cyclic MDPC codes With parameters at least: Length n = 216 + 6, dimension k = 215 + 3, d = 274, and adding t = 264 errors.

NTRU, Stehl´e-Steinfeldversion No particular parameters were recom- mended.

This proposal is quite outdated, and more recommendations may be made in the future by NIST, after the process to evaluate and standarize quantum- resistant algorithms is finished.

2.4 On the security aspect In reality, the QSH Key Exchange is secure only against passive attacks. It additionally offers forward security [23], in the sense that if the communi- cation is recorded and stored, it would not be decrypted by the quantum- computers built in the future. This is because QSH Key Exchange assumes to have a classically authenticated channel, and current methods of authen- tication (DSA, RSA) can be broken by quantum computers as well.

3 Incorporation of Quantum-safe Algorithms into OpenSSL

In section 2, the proposed mechanism to include quantum-resistant algo- rithms into TLS 1.3 in a hybrid fashion was described. However, the big

5 question remains as to what extent the performance will be affected in prac- tice. This section attempts to highlight the documented attempts to incor- porate the implementation of quantum-resistant algorithms into OpenSSL, which is a very popular open-source implementation of the TLS protocol. In concrete terms, it is of interest to see how much the latency is increased, and how much more memory is required to establish a TLS session. These are aspects that have an impact on the Quality of Service, and may hinder or slow down adoption by both clients and servers.

3.1 Quantum-safe Key Exchange Mechanism Key Exchange is one of the main phases in the TLS protocol, and it’s intended to establish shared keying material and to select cryptographic parameters [15]. Thus, a Key Exchange Mechanism (KEM) is a procedure that performs the Key Exchange phase. The current KEM used in the TLS protocol relies on algorithms that would be broken by a quantum computer. Some of these algorithms, like RSA, are already deprecated. The rest, e.g. DHE, and ECDHE, work under certain groups that are otherwise known to be secure in the classical set- ting. As seen in section 2, an effort to update the TLS protocol to support algorithms resistant against classical attacks is being made in [22]. A quantum-resistant public-key algorithm can be encapsulated into a KEM for adoption into TLS. The quantum-safe solutions proposed so far, e.g., Quantum-Safe Hybrid KEM, relies on the assumption that the channel is authenticated classically, and thus in reality would only offer security against passive attacks. For these algorithms, such as NewHope and NTRU, to be secure against active attacks, quantum-safe entity authentication is required. The proposal in [3] shows that Kyber, a quantum-resistant KEM, is IND- CCA secure. Thus, it can be used in authenticated key exchange without needing quantum-resistant signatures.

3.2 Open Quantum Safe (OQS) and liboqs The Open Quantum Safe (OQS) project [11] intends to support the devel- opment and prototyping of quantum-resistant cryptography. It provides two important things: a toolkit called liboqs and prototype integrations into pro- tocols and applications. Liboqs is an open source C library that implements quantum-resistant cryptographic algorithms. Among the prototype integra- tions, the most relevant one is a fork of the OpenSSL library with quantum- resistant algorithms built into it.

6 The algorithms included in liboqs are meant to be used as Key Exchange Mechanisms, and so far, the inclusion of entity authentication has been left out as future work. The algorithms included in libqos are: SIDH, McBits, FRODO, BCNS, NewHope, and the latest addition, Kyber. The work in [3] shows the performance of these algorithms in terms of latency considering communication between two parties P1 and P2. These results were obtained by running one of the test functions built into the liboqs toolkit. The results are summarized in Table 1.

Operations (µs) Scheme P1 (start) P2 P1 (end) Total SIDH 15,015 33,530 14,241 62,786 McBits 170,892 53 133 171,078 FRODO 3,436 4,027 105 7,568 BCNS 1,087 1,729 178 2,994 NewHope (MSR) 60 104 19 183 NewHope 69 107 18 194 Kyber 77 100 110 287

Table 1: Performance of implementations in liboqs

In general, it would seem that NewHope and Kyber are the best candi- dates to encapsulate as Key Exchange Mechanisms. However, these results only take into consideration the time spent for key exchange, and not the size of data being exchanged through the process. Although Kyber is the latest addition to the liboqs toolkit, there is an- other algorithm which is trying to make its way into it, namely, HILA5 [17]. In their work, the authors unofficially include HILA5 into liboqs. They have also run various tests to compare HILA5 with the other algorithms from the toolkit. The tests were run under a Core i7-6700 @ 3.40 GHz Ubuntu 17.04 workstation. The results are shown in Table 2.

Init Public Private Key Exch. Data Scheme KeyGen() Encaps() Decaps() Total Total transfer (RLWE) NewHope 60.7 µs 92.3 µs 16.2 µs 169.2 µs 3,872 B (RLWE) HILA5 68.7 µs 89.9 µs 16.9 µs 175.4 µs 3,836 B (RLWE) BCNS15 951.6 µs 1546 µs 196.9 µs 2.694 ms 8,320 B (LWE) Frodo 2.839 ms 3.144 ms 84.9 µs 6.068 µs 22,568 B (SIDH) CLN16 10.3 ms 22.9 ms 9.853 ms 43.1 ms 1,152 B

Table 2: Alternative performance test of implementations in liboqs

7 Even though there are differences in the numbers obtained, it seems that there is consistency in the results regarding the latency of the key exchange procedure. Unfortunately, Kyber was not included in these results, so it remains to be seen what is the expected size of the data transferred between the communicating parties that use this algorithm. Otherwise, it seems that NewHope and HILA5 maintain a good balance between latency and size of data.

3.3 Quantum-Safe KEM in OpenSSL This subsection describes the documented attempts to include quantum- resistant KEM into the OpenSSL library as independent forks. Some of them have been made as proof of concept, and thus abandoned, but it gives some insight on the changes that would be done in software libraries to adopt a quantum-resistant KEM.

3.3.1 Stebila’s OpenSSL Fork with RLWE The first known addition of a quantum-resistant algorithm into OpenSSL was done in [5]. This is a fork of OpenSSL 1.0.1f that was available at the time. The repository can be found in [4]. The intention was to show the practicality of post-quantum key exchange by adding new cipher suites based on the RLWE to the TLS protocol. The ring learning with errors (RLWE) problem is based on lattices, and is known to be resistant against quantum computers. This work assumes authentication via classical means, i.e., using RSA or ECDSA, so it provides against future quantum attackers. The authors ran performance tests using this OpenSSL fork and the Apache web server on a 2-core computer. The cipher suites tested were: RLWE-ECDSA-AES128-GCM-SHA256 and ECDHE-RSA-AES128-GCM-SHA256. This implies that the differences lie in the key exchange and authentication algo- rithms. For the latter case, ECDHE ran under the nistp256 curve, and the authentication was done with 3072-bit RSA. It was found that by using the first cipher suite choice, they could achieve 506 HTTPS connections per sec- ond for a 10 KiB payload. In contrast, it required a 2 KiB payload for the ECDHE cipher suite choice to reach the same number of connections. This represents that the RLWE cipher suite showed a reduction in throughput of 21% in comparison to the ECDHE case. In both scenarios, the intended se- curity level was 128-bit. In general, latency when adopting RLWE increased by factors of 7.6x (ECDSA) and 3.9x (RSA). The size of the handshake also increased by factors of 7.4x (ECDSA) and 4.4x (RSA).

8 This attempt showed the feasability of the inclusion post-quantum algo- rithms into the OpenSSL software. Finally, the fork also included a hybrid version of key exchange by combining the outputs of ECDHE and RLWE. This approach showed a slow down in performance by a factor of 7.9x when using ECDSA, and of 3.9x when using RSA as the authentication scheme.

3.3.2 Singh’s OpenSSL Fork with RLWE In [13], Peikert proposes a series of protocols based on lattice-based schemes to accomplish key transport, encryption, and authenticated key exchange. One of the main highlights of this particular key-exchange protocol is that it uses a simple low-bandwidth reconciliation technique that allows the two parties to approximately agree on a secret to reach an exact agreement. Fur- thermore, the size of the ciphertext is reduced nearly by half in comparison to the original size of the ciphertexts obtained by the original lattice-based scheme. A simplification of these protocols is described in [18]. In 2016, the same author released a fork of OpenSSL 1.0.2e in [19] that implements a Ring- Learning with Errors scheme as a Key Exchange Mechanism from the propos- als by Peikert. In this fork, two additional cipher suites are defined for key ex- change, namely: RLWE-RSA-AES128-GCM-SHA256 and RLWEP-RSA-AES128-GCM -SHA256. The difference between RLWE and RLWEP lies on which case is being used in the scheme: power-of-two case and prime case, respectively. For both cases, the key exchange mechanism achieves a of 256 bits. Regarding the sizes for the public keys are 2.048 KiB and 1.64 KiB for RLWE and RLWEP, respectively. Apart from the sizes of the ciphertexts, the performance of these cipher suites in OpenSSL in terms of latency was not reported. Finally, it pro- poses hybrid RLWE+ECDHE key exchange mechanisms, but these were not implemented into the fork.

3.3.3 Open Quantum Safe’s OpenSSL Fork The Open Quantum Safe (OQS) project [20], as mentioned earlier, has the intention of exploring quantum-resistant key exchange and encryption algo- rithms. It also prototypes and evaluates how these algorithms can fit into applications and protocols used today. One such protocols of interest is the TLS protocol for securing Internet communications. The OQS proposes the inclusion of post-quantum algorithms into TLS, specifically version 1.2, and it defines several new cipher suites to be used for key exchange. These cipher suites use RSA/ECDSA as signing algorithms,

9 but use quantum-resistant key exchange to derive the shared secret. Then, the TLS protocol proceeds as usual, i.e., use symmetric encryption with AES in GCM mode. Additionally, it is also proposed to have an hybrid cipher suite. That is, having the TLS handshake use two exchange algorithms: one that is quantum-resistant, and one that is classically secure. The goal of this hybrid approach is to retain security against today’s computers, while also obtaining passive security against quantum-computers. As part of the OQS project, their library of quantum-resistant algo- rithms, liboqs, is integrated into the OpenSSL library, specifically as a fork of OpenSSL 1.0.2, maintained in [11]. This project is not intended to be used in a production environment, but rather serves as a prototype of inclusion of quantum-resistant cryptography into the TLS protocol. The key exchange mechanisms included in this OpenSSL fork are those included into the liboqs library, namely:

• RLWE-BCNS15 • RLWE-NEWHOPE • RLWE-MSRLN16 • LWE-FRODO-RECOMMENDED • SIDH-CLN16 • SIDH-IQC-REF • CODE-MCBITS • NTRU • MLWE-KYBER

For each of the distinct key exchange mechanisms, there are various branches that result in a distinct cipher suite. The cipher suite varies depend- ing on: standalone or hybrid KEM, RSA or ECDSA as signing algorithm, AES-128 or AES-256 as symmetric encryption, and SHA-256 or SHA-384 as hashing function. Thus, these are all the possibilities for each KEM, where X is one of the quantum-resistant algorithms listed earlier:

• X-RSA-AES128-GCM-SHA256 • X-ECDSA-AES128-GCM-SHA256 • X-RSA-AES256-GCM-SHA384 • X-ECDSA-AES256-GCM-SHA384 • X-ECDHE-RSA-AES128-GCM-SHA256 • X-ECDHE-ECDSA-AES128-GCM-SHA256 • X-ECDHE-RSA-AES256-GCM-SHA384 • X-ECDHE-ECDSA-AES256-GCM-SHA384

Up to the addition of the Frodo KEM, performance results in the OpenSSL

10 suite can be seen in [20]. Since then, two more additions have been made, namely: Kyber and HILA5. The last inclusion into the OQS’s OpenSSL fork is the HILA5 cipher suite proposed as a key-exchange mechanism in in [17]. The OQS’s liboqs has not officially included the HILA5 KEM, but there is an unofficial patch to add it in [16]. It includes two versions of the scheme as cipher suites: one with standalone HILA5, and a hybrid one combined with ECDHE.

3.4 Quantum-safe Authentication Many of the key exchange mechanisms outlined earlier, such as BCNS15, Frodo and NewHope, are only for unauthenticated key exchange. For them to be secure, it is either assumed that the channel is authenticated by some means, or that the attacker is passive only. In the OpenSSL forks, the cipher suites include a signing algorithm, like ECDSA or RSA, which can be broken by a quantum computer. Thus, making use of quantum-resistant KEM only guarantees security against passive attacks and offers forward security against future quantum computers. However, once quantum-computers are built, this security notion will not be enough. There are two alternatives to fix the issue outlined above. The first is to use quantum-resistant signatures to authenticate the keyshare material in the protocol. This would replace ECDSA. The second method is to employ a quantum-resistant key exchange mechanism with the IND-CCA3 prop- erty. In this case, the KEM would provide which is quantum-resistant as well. One such KEM secure against active attacks is Kyber, and is described in [3]. Recently, Kyber has been included into the liboqs library, making it now trivial to include it into the respective OpenSSL fork. Using the Kyber cipher suite, regardless of the signing algorithm, would offer an authenticated key exchange resistant to active attacks by quantum computers.

3.5 Alternative implementations of TLS 3.5.1 wolfSSL An alternative solution to OpenSSL and formerly known as CyaSSL, wolfSSL is a small, fast, and portable implementation of TLS for embedded devices to the cloud. It is also meant to be used for secure communications in smart grid, smart home, mobile games, and other applications. [25]. In July 2015, wolfSSL officially announced support for quantum-safe key exchange by using NTRU [26]. The approach taken in wolfSSL for the inclu-

11 sion of NTRU is the same Quantum-Safe Hybrid (QSH) handshake described in the internet draft [22] by the IETF. According to the technical documentation [24], if wolfSSL is enabled with NTRU, then the TLS QSH cipher suite will be given the highest preference order when the protocol picks a cipher suite. It is unknown if the key ex- change is hybrid, combining NTRU with a classical KEM, or if it merely relies on NTRU. Additionally, it was not reported how the latency in communica- tion is affected between the communicating parties when enabling NTRU as a cipher suite.

3.5.2 BoringSSL BoringSSL is a fork of OpenSSL that has been modified by Google to satisfy their needs. This fork is currently used as the SSL library in Google Chrome and Chromium, and optionally Android. In May 2016, Google deployed a version of BoringSSL which includes a post-quantum key-exchange algorithm in parallel with a elliptic-curve key- exchange algorithm that is typically used in a TLS session [6]. This experi- ment was conducted to see how feasible it is to pack post-quantum algorithms within their existing TLS library. The post-quantum algorithm chosen for this was NewHope, and the elliptic curve was chosen under the group X25519. The experiment was carried on the TLS version 1.2, as implemented by Bor- ingSSL. The resulting key exchange mechanism was called CECPQ1, and it basi- cally consisted of concatenating the results of the elliptic curve x25519 and the NewHope key agreements. Thus, the KEM mechanism operated in a hybrid fashion, providing protection against classical and quantum attacks. This attempt uses ECDSA for signing, and thus does not offer post- quantum authentication. Therefore, this approach provides only forward secrecy against quantum computers. Lastly, this experiment is thought to have lasted until November of the same year, with positive results overall [9]. In general, they did not encounter unexpected impediments for deployment of a post-quantum key exchange, and there were no reported problems caused by enabling it. It was predicted that enabling this combination of key exchanges would incur in a serious hit to latency. In the end, it was found that the median latency increased by 1ms, the slowest 5% increased by 20ms, and the slowest 1% by 150ms. It is thought that this is caused entirely by the increased message sizes, and not because of the computation overhead of using NewHope. Thus, clients with the slowest connections are the ones who are taking the hit in latency. After the conclusion of this experiment, a later update disabled support

12 for the CECPQ1 key exchange, and in the future a more algorithm-agnostic approach will be preferred.

3.5.3 PolarSSL Recently rebranded as TLS, PolarSSL is an TLS/SSL library intended to be used for embedded devices. In [7], a fork of PolarSSL was created to incorporate post-quantum algorithms into the TLS protocol, including lattice-based key exchange and multivariate public key signature schemes. The modifications in this fork have also made it easier to make future addi- tions into the library. The lattice-based key exchange mechanism they incorporated to the li- brary is based on [27], and the operation is very similar to Diffie-Hellman . As for the signatures, Rainbow and TTS, two multivariate-based signature schemes, were chosen to be used for the implementation. The security of these signature schemes are on the scale of 80-bit security, though the au- thors propose a set of parameters which may increase the security level. Four variants as combinations of these algorithms are proposed as cipher suites to be added to PolarSSL. The lattice-based key exchange may be combined with any of these signing algorithms: TTS, Rainbow, RSA, or ECDSA. In the latter two scenarios, it is expected that only forward secrecy would be gained, as the algorithms used for authentication (RSA, ECDSA) are not quantum-resistant. In their work, they measured performance in terms of cryptographic op- erations done per second (e.g., number of signing operations per second). The results obtained by these tests are shown in Table 3. Additionally, they ran performance tests on complete TLS handshakes for each of the four com- binations they incorporated. The results of these integrated tests are shown in Table 4. The tests were run in an Intel CPU Xeon E3-1245v3 3.40GHz machine. It is apparent that the lattice-based key exchange algorithm suffers greatly in performance, as it does 15% as many exchanges per second as the ECDHE does. The Rainbow scheme does 35% more sign operations per second as the ECDSA does, which seems to be an improvement in performance. And with regards to the verify operation, the TTS and Rainbow schemes clearly do many more operations per second, almost as much as 14 times the number of verify operations in the ECDSA. From the results shown in Table 4, it is clear that the proposed lattice- based KEM does as many as 25% of the handshakes done for the typical ECDHE+ECDSA combination. On a positive side, it shows that a fully post-quantum protocol is feasible in practice, even if there are performance

13 Computation Throughput ECDHE (secp256r1) exchange 189 exchange/s Lattice exchange 28.5 exchange/s RSA (2048-bit) sign 482 sign/s ECDSA (secp256r1) sign 1629 sign/s TTS (128b) sign 15381 sign/s Rainbow (128b) sign 2199 sign/s RSA (2048-bit) verify 15883 verify/s ECDSA (secp256r1) verify 434 verify/s TTS/Rainbow verify 6136 verify/s

Table 3: Performance of cryptographic operations

Throughput Cipher suite handshakes/sec ECDHE(secp521r1)-RSA(2048-bit) 20.0 ECDHE(secp521r1)-ECDSA(secp256r1) 18.1 ECDHE(secp521r1)-TTS(128b) 18.2 LATTICE(III)-TTS(128b) 4.5

Table 4: Performance of TLS handshakes issues. Lastly, the algorithms included in the cipher suite (lattice-based exchange and Rainbow/TTS) are known to be resistant against quantum attacks, but in the paper there is no mention of resistance against active attacks in the quantum setting.

3.6 On the difficulty of extending OpenSSL In general, the OpenSSL library is very large and complex, partially to the amount of changes it was undergone through the years. [20] describes the process of extending OpenSSL to support additional algorithms for key ex- change. The first algorithm extended to OpenSSL was BCNS15 (RLWE key exchange), and it was implemented directly on the library. Even though the standalone implementation required under 900 lines of code, adding it to OpenSSL required adding or modifying another 2143 lines, distributed among 23 files. Indeed, it would not be manageable to follow the same approach for in- corporating other algorithms, as it would be very time consuming, and most likely, easily broken by official changes in OpenSSL. Thus, from the integra-

14 tion of the Frodo scheme and onward, an intermediate API was developed to ease the integration into the OpenSSL fork. This API was not released publicly, but it motivated many features present now in the Open Quantum Safe framework. Several improvements have been made to the liboqs library and OpenSSL library, so that adding a new cipher suite to OpenSSL from the liboqs library is a 15-minute task. As part of the changes, a generic key exchange method was included in liboqs. This method can be hard-coded at compile time to any of its implementations (NewHope, Frodo, Kyber, etc.). Meanwhile, the OpenSSL fork includes a generic OQS key-exchange cipher suite that calls the respective generic key-exchange method from liboqs. Thus, by correctly implementing an additional key-exchange mechanism into liboqs, it becomes trivial to extend this particular OpenSSL fork to support it.

4 Hybrid public keys and signatures in X.509

Considering the changes needed, updating public-key exchange algorithms is relatively trivial, as they are negotiated between peers. However, it is much more difficult to update an authentication system which relies on a single signature algorithm. This is because there is a circular dependency between identity systems and the dependent communication protocols. To update such a system, a duplicate PKI system which uses the new signature algorithm would be needed, and then it would migrate all the dependent systems one at a time [1]. This is a very troublesome way of updating an authentication system which relies on a single signature algorithm. A meeting by the ITU-T Study Group 17 of the IETF made a proposed a solution to this with regards to the X.509 certificate: to include optional support for multiple key algorithms, which is backward compatible with ex- isting systems. More specifically, the X.509 certificate can contain an alter- nate public key and alternate signature, and the Certificate Authority would sign certificates using a layered approach, so that every attribute can be authenticated by both signatures. This results in a certificate which can be used as usual by existing sys- tems relying on the initial public key and signature, while also containing a alternate quantum safe public key and signature. The implementation of this proposal would remove the need to have a duplicate PKI system when doing the transition to support quantum-safe algorithms. In essence, old systems will still use the classic pair of public key and signature provided, while systems which support quantum-safe algorithms will prefer to use the alternate public key and algorithm. This would facilitate

15 the migration of PKI and dependent protocols to the newer digital signature algorithms.

4.1 Proof of concept [21] reported on his implementation of a certificate chain which can hold two distinct public keys and two signatures: RSA being the underlying algorithm for the first pair, and LMS for the second pair. It should be noted that LMS (Leighton-Micali Signature) is considered to be quantum-safe [10]. The use case is transferring a certificate from a server to a client, which contains a Diffie-Hellman (DH) key, which is to be used in subsequent steps of the protocol. As per the usual TLS procedure, the client sends a HELLO message to the server, along with a list of supported cipher suites. To this, the server replies with a HELLO message, its own certificate, and the OID of the cipher suite that will be used. In the proposed implementation, there are two possible cipher suites to consider for digital signing of the DH key enclosed in the certificate: xx RSA xx and xx LMS xx. Depending on the server and client, different scenarios occur during trans- mission of this certificate: the first where server is old (and only supports non quantum-safe algorithms), and the other where the server is updated to additionally support quantum-safe public-key algorithms. In the case of the updated server, it further branches out into two cases: when it commu- nicates with a client with an unmodified browser, and when the client has a modified browser. The modified browser is able to support the quantum- safe algorithms. The proof-of-concept implementation for this proposal was tested on Firefox, Chrome, and Safari. Note that in all scenarios, the certifi- cate is signed (by what would be a Certificate Authority) with two signatures: a regular signature, and a quantum-safe signature.

1. In the old server scenario, only the RSA pairs are used for verification of the certificate. The extra key and signature are not used. RSA is negotiated as cipher suite, the client verifies the certificate’s regular signature, and the protocol proceeds as usual.

2. In the updated server case, where the client is unmodified, the server is notified that the client does not support a quantum-safe algorithm, and thus chooses RSA as cipher suite. Then the protocol proceeds as in the previous case.

3. If the client is modified, so that both the server and client support quantum-safe algorithms, LMS is selected as cipher suite by the server. Before sending the certificate, the server signs the DH public key of the

16 certificate using its LMS private key, instead of the RSA private key. The certificate also includes the additional LMS public key, which is signed with the LMS private key of the server. For verification on the client’s end, first the outer regular signature is peeled off, and then the certificate is verified by using the outer LMS signature. Having done this, the LMS public key can be used to verify the (LMS) signature of the inner DH public key. Having recovered this public key, the client proceeds with the protocol.

Note that this was done in a certificate chain, so actually there were a series of DH keys involved in the verification step. The following figure shows how the modifications would look like in the structure of the X.509 certificate:

X.509 Certificate

Subject Regular PublicKey Info (DH) setting Signature (RSA or LMS)

Additional PublicKey Info (LMS) Q-safe key and Signature (LMS) signature

Figure 1: Structure of modified X.509 certificate

In this proof-of-concept, RSA and LMS were chosen as classic and quantum- safe algorithms, respectively, but in general, the idea is that X.509 stays algorithm-agnostic, so that it’s easier to adopt other quantum-safe algo- rithms. The test cases showed that the redesign of the X.509 allows for the use of quantum-safe cipher suites, if both the server and client support them, while staying compatible with systems that have not yet been updated.

17 5 Conclusion

This report provides a general overview of how quantum-resistant algorithms can be adopted to protocols and public-key infrastructure that are used today. As quantum computers might be built within a decade, it is reasonable to also start considering the practical and performance implications of relying on these newer algorithms. The Open Quantum Safe framework gives a strong argument on the ease of extending libraries to support quantum-resisant algorithms. If adding a new key-exchange mechanism to OpenSSL, a very complex and large library, becomes a 15-minute task, then this gives an idea of how future efforts for incorporating quantum-resistant algorithms will look like.

References

[1] ITU-T Study Group 17. LS on ITU-T SG17 work on quantum-safe PKI. ://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017- 09-13-itu-t-sg-17-ipsecme-lamps-ls-on-itu-t-sg17-work-on- quantum-safe-pki-attachment-1.pdf, 2017.

[2] Bela Bauer, Dave Wecker, Andrew J. Millis, Matthew B. Hastings, and M. Troyer. Hybrid quantum-classical approach to correlated materials. 2015.

[3] Joppe Bos, L´eoDucas, Eike Kiltz, Tancr`ede Lepoint, Vadim Lyuba- shevsky, John M. Schanck, Peter Schwabe, and Damien Stehl´e.CRYS- TALS – Kyber: a CCA-secure module-lattice-based KEM, 2017. http: //cryptojedi.org/papers/#kyber.

[4] Joppe W. Bos, Craig Costello, Michael Naehrig, and Douglas Stebila. Fork of OpenSSL 1.0.1 for ring-LWE key exchange support. Code repository, https://github.com/dstebila/openssl-rlwekex, Octo- ber 2014.

[5] 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. Cryptology ePrint Archive, Report 2014/599, 2014. https://eprint.iacr.org/2014/599.

[6] Matt Braithwaite. Experimenting with post-quantum cryptography. https://security.googleblog.com/2016/07/experimenting-with- post-quantum.html, July 2016.

18 [7] Y. A. Chang, M. S. Chen, J. S. Wu, and B. Y. Yang. Postquantum ssl/tls for embedded systems. In 2014 IEEE 7th International Conference on Service-Oriented Computing and Applications, pages 266–270, Nov 2014.

[8] Bruno Huttner and Jane Melia. Applied quantum-safe security: Quantum-resistant algorithms and . Cloud Security Alliance, https : / / downloads . cloudsecurityalliance . org/assets/research/quantum-safe-security/applied-quantum- safe-security.pdf, 2017.

[9] Adam Langley. Cecpq1 results. Weblog post, https :/ / www. imperialviolet.org/2016/11/28/cecpq1.html, November 2016.

[10] David McGrew, Michael Curcio, and Scott Fluhrer. Hash-based signa- tures. Internet-Draft draft-mcgrew-hash-sigs-07, IETF Secretariat, June 2017. http://www.ietf.org/internet-drafts/draft-mcgrew-hash- sigs-07.txt.

[11] Michele Mosca and Douglas Stebila. Fork of that includes quantum-resistant algorithms and ciphersuites based on liboqs. Repos- itory , https://devhub.io/repos/open-quantum-safe-openssl.

[12] NIST. First PQC Standardization Conference, 2017. https://csrc. nist.gov/events/2018/first-pqc-standardization-conference.

[13] Chris Peikert. Lattice cryptography for the internet. Cryptology ePrint Archive, Report 2014/070, 2014. https://eprint.iacr.org/2014/ 070.

[14] PQCRYPTO. Initial recommendations of long-term secure post- quantum systems. http : / / pqcrypto . eu . org / docs / initial - recommendations.pdf, September 2015.

[15] Eric Rescorla. The transport layer security (tls) protocol version 1.3. Internet-Draft draft-ietf-tls-tls13-21, IETF Secretariat, July 2017. http: //www.ietf.org/internet-drafts/draft-ietf-tls-tls13-21.txt.

[16] Markku-Juhani O. Saarinen. Hila5 ciphersuites for openssl. Author’s website, 2017. https://mjos.fi/hila5/tls.html.

[17] Markku-Juhani O. Saarinen. Hila5: On reliability, reconciliation, and error correction for ring-lwe encryption. Cryptology ePrint Archive, Report 2017/424, 2017. https://eprint.iacr.org/2017/424.

19 [18] Vikram Singh. A practical key exchange for the internet using lat- tice cryptography. Cryptology ePrint Archive, Report 2015/138, 2015. https://eprint.iacr.org/2015/138.

[19] Vikram Singh. A practical key exchange for the internet using lat- tice cryptography. Code repository, https://github.com/vscrypto/ openssl-ringlwe, May 2016.

[20] Douglas Stebila and Michele Mosca. Post-quantum key exchange for the internet and the open quantum safe project. Cryptology ePrint Archive, Report 2016/1017, 2016. https://eprint.iacr.org/2016/1017.

[21] Alexander Truskovsky. Response to LS on ITU-T SG17 work on quantum-safe PKI. https://mailarchive.ietf.org/arch/msg/ spasm/vColblJzvJU6p6vL1mQqRGZU458, 2017. Mailing list.

[22] S.Fluhrer W. Whyte, Z.Zhang. Quantum-safe hybrid (qsh) key exchange for transport layer security (tls) version 1.3. https://tools.ietf.org/ html/draft-whyte-qsh-tls13-06.txt, 2017.

[23] William Whyte and Zhenfei Zhang. Quantum cryptanaly- sis, quantum-safe algorithms based on hard problems over lattices, and how we get there from here. Slides, https : //www.researchgate.net/profile/William_Whyte/publication/ 309354393 _ Quantum _ _ quantum - safe _ algorithms _ based _ on _ hard _ problems _ over _ lattices _ and _ how _ we _ get _ there _ from _ here / links / 580ab10a08ae74852b530692 / Quantum - cryptanalysis - quantum - safe - algorithms - based - on - hard - problems-over-lattices-and-how-we-get-there-from-here.pdf, 10 2016.

[24] wolfSSL. Quantum-safe handshake ciphersuite. Technical documenta- tion, https://www.wolfssl.com/docs/wolfssl-manual/ch4/. Ac- cessed on November 2017.

[25] wolfSSL. Quantum-Safe wolfSSL. https://www.wolfssl.com/. Ac- cessed in November 2017.

[26] wolfSSL. Quantum-Safe wolfSSL. https://www.wolfssl.com/ quantum-safe-wolfssl-2/, July 2015.

[27] Jiang Zhang, Zhenfeng Zhang, Jintai Ding, Michael Snook, and Ozg¨ur¨ Dagdelen. Authenticated key exchange from ideal lattices. Cryptology

20 ePrint Archive, Report 2014/589, 2014. https://eprint.iacr.org/ 2014/589.

21