July 11, 2018

Today's encryption protocols are mostly not resistant to quantum computers. Fortunately the latter don't exist yet but the time to prepare is now.

Wire's Head of Security Raphael Robert and cryptographer JP Aumasson write about the current state of quantum computing, the threat model, and plans to harden Proteus, Wire's encryption protocol, against quantum computers.

A quantum computer is not a computer that is running at a higher frequency than a normal, classical computer — it may actually be slower. Instead, thanks to a completely different way of computing output values from input values it will solve certain computational problems fundamentally more efficiently than *any* classical machine.

This phenomenon is called *quantum speed-up*. The National Institute of Standards and Technology (NIST) has compiled a list of problems that will benefit from this. The first two problems in this list — factoring and discrete logarithms — are practically impossible to solve unless you’ve got a large enough quantum computer.

How does this relate to Wire and cryptography in general?

When you create a new Wire session, and when you send new messages in a conversation, a cryptographic operation called key agreement happens under the hood. This operation involves mathematical operations whose security relies on the difficulty of the discrete logarithm problem.

In other words, the hardness of computing the number *x* given numbers *g* and *g*^{x}, for specific types of numbers *g* and *x*, is what keeps Wire conversations private. If a quantum computer existed, it could solve this problem efficiently and compromise Wire's security.

Quantum computers that could break today's cryptography do not exist today yet. The physicists are only experimenting with tiny quantum computers including fewer than 50 quantum bits (or *qubits*) that are able to run only for microseconds.

In comparison, the system needed to compute the kind of discrete logarithms used in Wire and other cryptographic systems today (incl. TLS, SSH, and many others) has to have millions of qubits running for days or weeks.

We are therefore very far from a cryptographic armageddon, yet there's a non-negligible chance of a breakthrough that leads to large, scalable quantum computers in the next 50 years. Non-negligible doesn't mean high, it just means that it cannot be completely ignored when managing risks.

To make an analogy, a Chief Security Officer or risk officer can't discard the risk of natural disaster and must prepare a Business Continuity and Disaster Recovery Plans if they’ve determined that the assets deserve protection against such a risk.

Likewise, if an organization needs to protect its sensitive information for decades, it can’t discard the risk associated with quantum computers, whereas it can safely ignore the risk that P=NP.

Quantum computing was labeled “the next big security risk” by Wired magazine a year ago and there are a few trends pushing this message::

- Physicists are making some progress towards a system that could solve some computational problem effectively faster than any classical computer — the so-called
*quantum supremacy*milestone. - NIST is running a Post-Quantum Cryptography project, in order to standardize one or more post-quantum algorithm around 2020-22. This follows a recommendation from the NSA to start adopting post-quantum cryptography as an insurance against an engineering breakthrough.
- A number of companies are offering post-quantum solutions, academic researchers in related fields seek funding for their research projects, and both are incentivized to communicate about and sometimes exaggerate the risk of quantum computers.

What could an attacker do against Wire today, if they expect to have access to a quantum computer in a near future?

Remember that the weakest component against *quantum attacks* is Wire's key agreement operation, namely the elliptic-curve Diffie-Hellman operation, or more specifically the Curve25519. The same elliptic curve is used by numerous other systems including TLS, SSH, TOR and Apple iOS to name a few.

Knowing that Wire's elliptic-curve Diffie-Hellman would be broken by a quantum computer, an attacker could do the following:

- Capture all the communications between two parties communicating on Wire, since the very beginning of their session, and without missing a data packet;
- Wait… until a quantum computer is commercially available;
- Use a quantum computer to retrieve the cryptographic keys protected by the Diffie-Hellman operations.

It's still unclear how much time breaking such keys would take, but it would definitely be closer to weeks (per key) than to thousands of years as it is today with classical computers.

With quantum computers still a thing of the future the reasonable question to ask is — what changes can be made to improve security *until* quantum computers emerge?

The good news is that solutions exist today to replace Diffie-Hellman key agreement with algorithms that wouldn't be broken by a large quantum computer. Such algorithms are called *post-quantum*, *quantum-safe*, or *quantum-resistant*. Today such algorithms are often slower and/or use longer keys, but their performance is not prohibitive, hence we can already experiment with post-quantum crypto in production applications.

Approaches to introduce some post-quantum cryptography into existing protocols exist in various areas. Most notably the Tor Project sought to improve the key derivation for encryption used in onion routing, and Google Chrome experimented with post quantum cryptography for TLS.

In both cases the chosen approach is to use hybrid cryptography rather than moving directly to post-quantum algorithms, which may require further scrutiny before being as trusted as more established methods.

In a hybrid system a classical, non-post-quantum algorithm is used in combination with a post-quantum algorithm, with the guarantee that the system will be secure as long as at least one of the two algorithms is secure. Indeed, the output values of both key agreements are combined to a new master secret, meaning that an attacker can't compute the master secret unless they determined both key agreements' values.

The traditional elliptic-curve algorithm can therefore mitigate the risk of the new post-quantum algorithm being vulnerable to classical (cryptanalytic or side-channel) attacks, while the post-quantum algorithm — if secure — mitigates the risk of quantum computers.

The core cryptographic component of Wire is Proteus, the library performing all cryptographic operations taking place during a Wire conversation, including the elliptic-curve Diffie-Hellman operations. To simplify a lot, Proteus will first compute a master secret as follows:

```
master_secret = HKDF(DH(A,b) | DH(a,B) | DH(a,b))
```

where DH stands for Diffie-Hellman, **A** and **a** are Alice's keys, **B** and **b** are Bob's keys, and HKDF is the key derivation function that generates a cryptographic key by hashing the three Diffie-Hellman results together.

We propose to simply integrate a post-quantum key agreement results to the master secret derivation, along with post-quantum key pairs extending the current Wire prekeys:

```
master_secret = HKDF(DH(A,b) | DH(a,B) | DH(a,b) | PQ(PQA, PQB))
```

In our proof-of-concept available at github.com/wireapp/pqproteus we conservatively chose NewHope, the same lattice-based protocol that Google Chrome experimented with, and for which reliable and fast implementations are available. NewHope is one of the submissions to NIST's post-quantum project, along with other promising constructions. But NewHope has nothing specific to Wire, and other algorithms could be integrated as well.

Note that in our proof-of-concept, NewHope is not integrated into every ratchet operation, but only in the initial key agreement. A binding between the session stages exists, using again HKDF to use the previous root key as a salt for the next stage. This makes Proteus resistant against quantum attacks later in the protocol.

It minimizes the performance impact, since adding the post-quantum key agreement in every ratchet step would considerably increase the message size, which could be a problem on mobile platform. Currently a Curve25519 public key is 32 bytes long, whereas NewHope keys have a size around 1kb (about 30 times more). Sending a short text message to multiple recipients would therefore quickly lead to a payload size in the range of megabytes.

We see this as a research project and more work is needed, be it performance assessment or general security scrutiny, before this can be deployed in a production system.

We’re very interested in your thoughts, and please report any bugs you would find in:

https://github.com/wireapp/pqproteus

*Raphael Robert, Wire & JP Aumasson, Kudelski Security*