Practical Implementations of Quantum-Resistant Cryptography Jes´usAntonio Soto Vel´azquez December 18, 2017 Contents 1 Introduction 2 2 Quantum-Safe Hybrid Key Exchange 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 discrete logarithm. 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), Digital Signature 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 Transport Layer Security (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 cipher 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 \Curve25519+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 Key Derivation Function (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.