Practical Implementations ofQuantum-Resistant Cryptography

Jesus Antonio Soto Velazquez

December 18, 2017

Contents

1 Introduction 2

2 Quantum-Safe Hybrid Key Exchange for TLS version 1.3 22.1 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Modified TLS steps . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Recommendations on the algorithms . . . . . . . . . . . . . . 52.4 On the security aspect . . . . . . . . . . . . . . . . . . . . . . 5

3 Incorporation of Quantum-safe Algorithms into OpenSSL 53.1 Quantum-safe Key Exchange Mechanism . . . . . . . . . . . . 63.2 Open Quantum Safe (OQS) and liboqs . . . . . . . . . . . . . 63.3 Quantum-Safe KEM in OpenSSL . . . . . . . . . . . . . . . . 8

3.3.1 Stebila’s OpenSSL Fork with RLWE . . . . . . . . . . 83.3.2 Singh’s OpenSSL Fork with RLWE . . . . . . . . . . . 93.3.3 Open Quantum Safe’s OpenSSL Fork . . . . . . . . . . 9

3.4 Quantum-safe Authentication . . . . . . . . . . . . . . . . . . 113.5 Alternative implementations of TLS . . . . . . . . . . . . . . . 11

3.5.1 wolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . . 113.5.2 BoringSSL . . . . . . . . . . . . . . . . . . . . . . . . . 123.5.3 PolarSSL . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.6 On the difficulty of extending OpenSSL . . . . . . . . . . . . . 14

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

5 Conclusion 18

1

1 Introduction

The confidentiality and authenticity of today’s communication in the Internetheavily depend on the use of cryptographic primitives and protocols. Thesecryptographic primitives usually rely on the difficulty of solving a certainproblem, e.g., prime factorization and discrete logarithm. These problemsshould be easy to solve for the intended participants who hold the secretpieces of information, but hard to solve for those who only hold the publicpieces of information for a particular instance of these problems.

Due to Shor’s algorithm, which operates under a quantum computer, thediscrete logarithm and prime factorization problems are solvable easily. Thismeans that algorithms such as RSA, Diffie-Hellman Exchange (DHE), DigitalSignature Algorithm (DSA), and the elliptic curve variations (ECDHE andECDSA) can be broken by a quantum computer of enough capacity. It hasbeen predicted that quantum computers [2] will finally be built within adecade. Thus, this calls for the need of employing a new set of algorithmsthat rely on hard problems that quantum computers cannot break. Suchalgorithms may be based on hash functions, error correcting codes, lattices(including learning with errors), multivariate equations, and supersingularelliptic curve isogenies.

These algorithms already exist, and have been studied in the theoreticalsetting for long. As we know it is inevitable that quantum computers willeventually be built, it is relevant to consider how to move away from thevulnerable 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 publickeys and signatures in the X.509 certificate.

2 Quantum-Safe Hybrid Key Exchange for

TLS version 1.3

The Transport Layer Security (TLS) protocol is widely used to ensure se-curity among two parties communicating over the Internet. The underlyingalgorithms 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 resultsin comparison to the ones adopted in TLS. However, governments have notupdated their list of approved algorithms to include these as standards. AsNovember 2017, there is an ongoing effort organized by NIST to find a suiteof 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 theTLS 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 alternativealgorithms like NTRU and McBits could already be put into TLS, it wouldbe desirable to keep the protocol algorithm-agnostic. In the event that oneof these algorithms is broken, it would be easy to replace it with another one.

Members of the IETF have proposed a mechanism [22] to incorporatequantum-safe algorithms within the protocol, while ensuring compatibilitywith the systems in use today.

2.1 Idea

The idea behind the proposal is to encapsulate the classic key exchange thattakes place in TLS, and in parallel perform another key exchange which relieson a quantum-resistant algorithm. The resulting shared key of this processwill be secure in both the classical and quantum settings. This term forthis mechanism is coined as Quantum-Safe Hybrid Key Exchange (QSH KeyExchange).

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 cipher suite was negotiated between peers. However,negotiating groups can also be useful for the QSH key exchange, becauseincluding quantum-safe algorithms would be very similar to having moregroups for DHE and ECDHE. Thus, the overall structure of the handshakewould remain unchanged, except that now it would include a description ofthe encoding used to hold the information regarding the new algorithms.

Additionally, it is desirable to follow an hybrid approach, so that instancesof a TLS protocol would use both the classical and quantum-safe algorithmsto generate their respective secrets in parallel. Thus, it was proposed toinclude 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 ahybrid key exchange, and it uses multiple key exchange methods in parallel.

As an example, consider the hybrid key exchange “Curve25519+NTRU”proposed by the client to the server. The server would need to accept bothkey exchanges, not only one of them. It would be problematic if the clientcould only propose one hybrid group. Thus, the proposal allows for morethan one combination, specifically up to 10, so that other ECDHE groupsand other quantum-safe algorithms can be considered as alternatives. Asmore combinations are supported by a server, the more likely it is that aclient will recognize at least one of the combinations, letting the TLS pro-tocol proceed as usual. After choosing the combinations of key-exchangemechanisms to use, their outputs can be combined through a Key DerivationFunction (KDF) to obtain a secret key shared by both parties. This impliesthat as long as one of the negotiated key exchanges is secure, the negotiatedkeys will remain secure.

2.2 Modified TLS steps

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

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

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

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

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

There are some structural changes that should be done to the data sentduring the ClientHello and ServerHello, so that it captures the possibility ofhaving one or more hybrid key exchanges. Additionally, a hybrid extensionis 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 hybridgroup. Apart from this, these changes are intended to be minimal to theTLS 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 includesome parameter recommendations:

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

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

NTRU, Stehle-Steinfeld version No particular parameters were recom-mended.

This proposal is quite outdated, and more recommendations may be madein 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. Itadditionally 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 assumesto 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. Theseare aspects that have an impact on the Quality of Service, and may hinderor 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 intendedto establish shared keying material and to select cryptographic parameters[15]. Thus, a Key Exchange Mechanism (KEM) is a procedure that performsthe Key Exchange phase.

The current KEM used in the TLS protocol relies on algorithms thatwould be broken by a quantum computer. Some of these algorithms, likeRSA, are already deprecated. The rest, e.g. DHE, and ECDHE, work undercertain 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 supportalgorithms resistant against classical attacks is being made in [22].

A quantum-resistant public-key algorithm can be encapsulated into aKEM for adoption into TLS. The quantum-safe solutions proposed so far,e.g., Quantum-Safe Hybrid KEM, relies on the assumption that the channel isauthenticated classically, and thus in reality would only offer security againstpassive attacks. For these algorithms, such as NewHope and NTRU, to besecure 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 withoutneeding 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 twoimportant things: a toolkit called liboqs and prototype integrations into pro-tocols and applications. Liboqs is an open source C library that implementsquantum-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 ExchangeMechanisms, and so far, the inclusion of entity authentication has been leftout 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 oflatency considering communication between two parties P1 and P2. Theseresults were obtained by running one of the test functions built into the liboqstoolkit. The results are summarized in Table 1.

Operations (µs)Scheme

P1 (start) P2 P1 (end) TotalSIDH 15,015 33,530 14,241 62,786McBits 170,892 53 133 171,078FRODO 3,436 4,027 105 7,568BCNS 1,087 1,729 178 2,994NewHope (MSR) 60 104 19 183NewHope 69 107 18 194Kyber 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 resultsonly take into consideration the time spent for key exchange, and not thesize 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 havealso run various tests to compare HILA5 with the other algorithms from thetoolkit. The tests were run under a Core i7-6700 @ 3.40 GHz Ubuntu 17.04workstation. The results are shown in Table 2.

Init Public Private Key Exch. DataScheme

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 thatthere is consistency in the results regarding the latency of the key exchangeprocedure. Unfortunately, Kyber was not included in these results, so itremains to be seen what is the expected size of the data transferred betweenthe communicating parties that use this algorithm. Otherwise, it seems thatNewHope and HILA5 maintain a good balance between latency and size ofdata.

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 ofthem have been made as proof of concept, and thus abandoned, but it givessome insight on the changes that would be done in software libraries to adopta quantum-resistant KEM.

3.3.1 Stebila’s OpenSSL Fork with RLWE

The first known addition of a quantum-resistant algorithm into OpenSSLwas done in [5]. This is a fork of OpenSSL 1.0.1f that was available atthe time. The repository can be found in [4]. The intention was to showthe practicality of post-quantum key exchange by adding new cipher suitesbased on the RLWE to the TLS protocol. The ring learning with errors(RLWE) problem is based on lattices, and is known to be resistant againstquantum computers. This work assumes authentication via classical means,i.e., using RSA or ECDSA, so it provides forward secrecy against futurequantum attackers.

The authors ran performance tests using this OpenSSL fork and theApache web server on a 2-core computer. The cipher suites tested were:RLWE-ECDSA-AES128-GCM-SHA256 and ECDHE-RSA-AES128-GCM-SHA256. Thisimplies that the differences lie in the key exchange and authentication algo-rithms. For the latter case, ECDHE ran under the nistp256 curve, and theauthentication was done with 3072-bit RSA. It was found that by using thefirst 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 theECDHE cipher suite choice to reach the same number of connections. Thisrepresents that the RLWE cipher suite showed a reduction in throughput of21% in comparison to the ECDHE case. In both scenarios, the intended se-curity level was 128-bit. In general, latency when adopting RLWE increasedby factors of 7.6x (ECDSA) and 3.9x (RSA). The size of the handshake alsoincreased 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 hybridversion 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 whenusing 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 schemesto accomplish key transport, encryption, and authenticated key exchange.One of the main highlights of this particular key-exchange protocol is thatit uses a simple low-bandwidth reconciliation technique that allows the twoparties to approximately agree on a secret to reach an exact agreement. Fur-thermore, the size of the ciphertext is reduced nearly by half in comparisonto the original size of the ciphertexts obtained by the original lattice-basedscheme.

A simplification of these protocols is described in [18]. In 2016, the sameauthor 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 isbeing used in the scheme: power-of-two case and prime case, respectively.For both cases, the key exchange mechanism achieves a security level of 256bits. Regarding the sizes for the public keys are 2.048 KiB and 1.64 KiB forRLWE and RLWEP, respectively.

Apart from the sizes of the ciphertexts, the performance of these ciphersuites in OpenSSL in terms of latency was not reported. Finally, it pro-poses hybrid RLWE+ECDHE key exchange mechanisms, but these were notimplemented into the fork.

3.3.3 Open Quantum Safe’s OpenSSL Fork

The Open Quantum Safe (OQS) project [20], as mentioned earlier, has theintention of exploring quantum-resistant key exchange and encryption algo-rithms. It also prototypes and evaluates how these algorithms can fit intoapplications and protocols used today. One such protocols of interest is theTLS 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 forkey 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 AESin GCM mode. Additionally, it is also proposed to have an hybrid ciphersuite. That is, having the TLS handshake use two exchange algorithms: onethat is quantum-resistant, and one that is classically secure. The goal of thishybrid approach is to retain security against today’s computers, while alsoobtaining 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 forkof OpenSSL 1.0.2, maintained in [11]. This project is not intended to be usedin a production environment, but rather serves as a prototype of inclusion ofquantum-resistant cryptography into the TLS protocol.

The key exchange mechanisms included in this OpenSSL fork are thoseincluded 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 variousbranches 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 ashashing function. Thus, these are all the possibilities for each KEM, whereX 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 suiteproposed as a key-exchange mechanism in in [17]. The OQS’s liboqs has notofficially included the HILA5 KEM, but there is an unofficial patch to addit in [16]. It includes two versions of the scheme as cipher suites: one withstandalone 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 themto be secure, it is either assumed that the channel is authenticated by somemeans, or that the attacker is passive only. In the OpenSSL forks, the ciphersuites include a signing algorithm, like ECDSA or RSA, which can be brokenby a quantum computer. Thus, making use of quantum-resistant KEM onlyguarantees security against passive attacks and offers forward security againstfuture 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 isto use quantum-resistant signatures to authenticate the keyshare material inthe protocol. This would replace ECDSA. The second method is to employa quantum-resistant key exchange mechanism with the IND-CCA3 prop-erty. In this case, the KEM would provide authenticated encryption whichis quantum-resistant as well. One such KEM secure against active attacks isKyber, and is described in [3]. Recently, Kyber has been included into theliboqs library, making it now trivial to include it into the respective OpenSSLfork. Using the Kyber cipher suite, regardless of the signing algorithm, wouldoffer an authenticated key exchange resistant to active attacks by quantumcomputers.

3.5 Alternative implementations of TLS

3.5.1 wolfSSL

An alternative solution to OpenSSL and formerly known as CyaSSL, wolfSSLis a small, fast, and portable implementation of TLS for embedded devicesto the cloud. It is also meant to be used for secure communications in smartgrid, smart home, mobile games, and other applications. [25].

In July 2015, wolfSSL officially announced support for quantum-safe keyexchange by using NTRU [26]. The approach taken in wolfSSL for the inclu-

11

sion of NTRU is the same Quantum-Safe Hybrid (QSH) handshake describedin the internet draft [22] by the IETF.

According to the technical documentation [24], if wolfSSL is enabled withNTRU, then the TLS QSH cipher suite will be given the highest preferenceorder 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 relieson NTRU. Additionally, it was not reported how the latency in communica-tion is affected between the communicating parties when enabling NTRU asa cipher suite.

3.5.2 BoringSSL

BoringSSL is a fork of OpenSSL that has been modified by Google to satisfytheir needs. This fork is currently used as the SSL library in Google Chromeand Chromium, and optionally Android.

In May 2016, Google deployed a version of BoringSSL which includes apost-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 algorithmswithin their existing TLS library. The post-quantum algorithm chosen forthis 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 andthe NewHope key agreements. Thus, the KEM mechanism operated in ahybrid 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 forwardsecrecy against quantum computers.

Lastly, this experiment is thought to have lasted until November of thesame year, with positive results overall [9]. In general, they did not encounterunexpected impediments for deployment of a post-quantum key exchange,and there were no reported problems caused by enabling it. It was predictedthat enabling this combination of key exchanges would incur in a serious hitto latency. In the end, it was found that the median latency increased by1ms, the slowest 5% increased by 20ms, and the slowest 1% by 150ms. It isthought that this is caused entirely by the increased message sizes, and notbecause of the computation overhead of using NewHope. Thus, clients withthe 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-agnosticapproach will be preferred.

3.5.3 PolarSSL

Recently rebranded as mbed TLS, PolarSSL is an TLS/SSL library intendedto be used for embedded devices. In [7], a fork of PolarSSL was createdto incorporate post-quantum algorithms into the TLS protocol, includinglattice-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 signatureschemes, were chosen to be used for the implementation. The security ofthese 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. Fourvariants as combinations of these algorithms are proposed as cipher suites tobe added to PolarSSL. The lattice-based key exchange may be combinedwith any of these signing algorithms: TTS, Rainbow, RSA, or ECDSA. Inthe latter two scenarios, it is expected that only forward secrecy would begained, as the algorithms used for authentication (RSA, ECDSA) are notquantum-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, theyran performance tests on complete TLS handshakes for each of the four com-binations they incorporated. The results of these integrated tests are shownin Table 4. The tests were run in an Intel CPU Xeon E3-1245v3 3.40GHzmachine.

It is apparent that the lattice-based key exchange algorithm suffers greatlyin performance, as it does 15% as many exchanges per second as the ECDHEdoes. The Rainbow scheme does 35% more sign operations per second as theECDSA does, which seems to be an improvement in performance. And withregards to the verify operation, the TTS and Rainbow schemes clearly domany more operations per second, almost as much as 14 times the numberof 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 typicalECDHE+ECDSA combination. On a positive side, it shows that a fullypost-quantum protocol is feasible in practice, even if there are performance

13

Computation ThroughputECDHE (secp256r1) exchange 189 exchange/s

Lattice exchange 28.5 exchange/sRSA (2048-bit) sign 482 sign/s

ECDSA (secp256r1) sign 1629 sign/sTTS (128b) sign 15381 sign/s

Rainbow (128b) sign 2199 sign/sRSA (2048-bit) verify 15883 verify/s

ECDSA (secp256r1) verify 434 verify/sTTS/Rainbow verify 6136 verify/s

Table 3: Performance of cryptographic operations

Cipher suiteThroughput

handshakes/secECDHE(secp521r1)-RSA(2048-bit) 20.0ECDHE(secp521r1)-ECDSA(secp256r1) 18.1ECDHE(secp521r1)-TTS(128b) 18.2LATTICE(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, butin the paper there is no mention of resistance against active attacks in thequantum setting.

3.6 On the difficulty of extending OpenSSL

In general, the OpenSSL library is very large and complex, partially to theamount of changes it was undergone through the years. [20] describes theprocess of extending OpenSSL to support additional algorithms for key ex-change. The first algorithm extended to OpenSSL was BCNS15 (RLWE keyexchange), and it was implemented directly on the library. Even thoughthe standalone implementation required under 900 lines of code, adding itto OpenSSL required adding or modifying another 2143 lines, distributedamong 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 mostlikely, easily broken by official changes in OpenSSL. Thus, from the integra-

14

tion of the Frodo scheme and onward, an intermediate API was developedto ease the integration into the OpenSSL fork. This API was not releasedpublicly, but it motivated many features present now in the Open QuantumSafe framework.

Several improvements have been made to the liboqs library and OpenSSLlibrary, so that adding a new cipher suite to OpenSSL from the liboqs libraryis a 15-minute task. As part of the changes, a generic key exchange methodwas included in liboqs. This method can be hard-coded at compile time toany of its implementations (NewHope, Frodo, Kyber, etc.). Meanwhile, theOpenSSL fork includes a generic OQS key-exchange cipher suite that callsthe respective generic key-exchange method from liboqs. Thus, by correctlyimplementing an additional key-exchange mechanism into liboqs, it becomestrivial 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 algorithmsis relatively trivial, as they are negotiated between peers. However, it ismuch more difficult to update an authentication system which relies on asingle signature algorithm. This is because there is a circular dependencybetween identity systems and the dependent communication protocols. Toupdate such a system, a duplicate PKI system which uses the new signaturealgorithm would be needed, and then it would migrate all the dependentsystems one at a time [1]. This is a very troublesome way of updating anauthentication system which relies on a single signature algorithm.

A meeting by the ITU-T Study Group 17 of the IETF made a proposeda solution to this with regards to the X.509 certificate: to include optionalsupport 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 wouldsign certificates using a layered approach, so that every attribute can beauthenticated 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 containinga alternate quantum safe public key and signature. The implementation ofthis proposal would remove the need to have a duplicate PKI system whendoing the transition to support quantum-safe algorithms.

In essence, old systems will still use the classic pair of public key andsignature provided, while systems which support quantum-safe algorithmswill prefer to use the alternate public key and algorithm. This would facilitate

15

the migration of PKI and dependent protocols to the newer digital signaturealgorithms.

4.1 Proof of concept

[21] reported on his implementation of a certificate chain which can hold twodistinct public keys and two signatures: RSA being the underlying algorithmfor 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, whichcontains a Diffie-Hellman (DH) key, which is to be used in subsequent stepsof 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 ofthe cipher suite that will be used. In the proposed implementation, thereare two possible cipher suites to consider for digital signing of the DH keyenclosed 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 supportsnon quantum-safe algorithms), and the other where the server is updatedto additionally support quantum-safe public-key algorithms. In the case ofthe updated server, it further branches out into two cases: when it commu-nicates with a client with an unmodified browser, and when the client hasa modified browser. The modified browser is able to support the quantum-safe algorithms. The proof-of-concept implementation for this proposal wastested 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 verificationof the certificate. The extra key and signature are not used. RSA isnegotiated as cipher suite, the client verifies the certificate’s regularsignature, and the protocol proceeds as usual.

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

3. If the client is modified, so that both the server and client supportquantum-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 issigned with the LMS private key of the server. For verification on theclient’s end, first the outer regular signature is peeled off, and then thecertificate is verified by using the outer LMS signature. Having donethis, the LMS public key can be used to verify the (LMS) signature ofthe inner DH public key. Having recovered this public key, the clientproceeds with the protocol.

Note that this was done in a certificate chain, so actually there were aseries of DH keys involved in the verification step.

The following figure shows how the modifications would look like in thestructure of the X.509 certificate:

X.509 Certificate

Subject

PublicKey Info (DH)

Signature (RSA or LMS)

Regular

setting

PublicKey Info (LMS)

Signature (LMS)

Additional

Q-safe

key and

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 staysalgorithm-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 forthe use of quantum-safe cipher suites, if both the server and client supportthem, while staying compatible with systems that have not yet been updated.

17

5 Conclusion

This report provides a general overview of how quantum-resistant algorithmscan be adopted to protocols and public-key infrastructure that are used today.As quantum computers might be built within a decade, it is reasonable toalso start considering the practical and performance implications of relyingon these newer algorithms.

The Open Quantum Safe framework gives a strong argument on the easeof extending libraries to support quantum-resisant algorithms. If adding anew 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 forincorporating quantum-resistant algorithms will look like.

References

[1] ITU-T Study Group 17. LS on ITU-T SG17 work on quantum-safe PKI.https://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, andM. Troyer. Hybrid quantum-classical approach to correlated materials.2015.

[3] Joppe Bos, Leo Ducas, Eike Kiltz, Tancrede Lepoint, Vadim Lyuba-shevsky, John M. Schanck, Peter Schwabe, and Damien Stehle. 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. Coderepository, 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 learningwith 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/tlsfor embedded systems. In 2014 IEEE 7th International Conference onService-Oriented Computing and Applications, pages 266–270, Nov 2014.

[8] Bruno Huttner and Jane Melia. Applied quantum-safe security:Quantum-resistant algorithms and quantum key distribution. CloudSecurity 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, June2017. http://www.ietf.org/internet-drafts/draft-mcgrew-hash-sigs-07.txt.

[11] Michele Mosca and Douglas Stebila. Fork of openssl that includesquantum-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 ePrintArchive, 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’swebsite, 2017. https://mjos.fi/hila5/tls.html.

[17] Markku-Juhani O. Saarinen. Hila5: On reliability, reconciliation, anderror 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 theinternet 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 onquantum-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 exchangefor 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 overlattices, and how we get there from here. Slides, https :

//www.researchgate.net/profile/William_Whyte/publication/

309354393_Quantum_cryptanalysis_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 OzgurDagdelen. Authenticated key exchange from ideal lattices. Cryptology

20

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

2014/589.

21