Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
SPONSORED BY
8/24/2017
01:30 PM
David Holmes
David Holmes
Partner Perspectives
Connect Directly
Twitter
LinkedIn
RSS
50%
50%

How Quantum Computing Will Change Browser Encryption

From a protocol point of view, we're closer to a large-scale quantum computer than many people think. Here's why that's an important milestone.

In 2015, The NSA’s Information Assurance Directorate issued guidance to postpone moving from RSA cryptography to elliptic curve cryptography (ECC) if they hadn’t already done so. The guidance stated:

For those partners and vendors that have not yet made the transition to Suite B elliptic curve algorithms, we recommend not making a significant expenditure to do so at this point but instead to prepare for the upcoming quantum-resistant algorithm transition.

The timing of the announcement was curious. Many in the crypto community wondered if there had been a quantum computing breakthrough significant enough to warrant the NSA’s concern. Since then, the crypto community has been trying to prepare for the transition to “quantum-resistant" algorithms — that is, algorithms that are secure against an attack by a quantum computer. Let’s look at some of the likely candidates for those algorithms and how they’ll be fitted into the Transport Layer Security (TLS) protocol that we all use today with HTTPS. But first, a bit of explanation.

If the day ever comes when a real, working, large-scale quantum computer can be built, then the era after that moment will become known as the “post-quantum” era. Encryption algorithms used in the "post-quantum" era should be puzzles that are not easily solved by quantum computers.

What’s the Current Quantum Computing Exposure?
Cryptographers currently believe that asymmetric encryption algorithms are vulnerable to quantum computing. Unfortunately, these include all the ones we use for TLS protocol handshakes!

  • RSA: Vulnerable
  • Elliptic Curve Digital Signature Algorithm (ECDSA): Vulnerable
  • Elliptic Curve Diffie-Hellman (ECDH): Vulnerable
  • Diffie-Hellman (DH): Vulnerable

Interestingly, a 2017 paper, Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms, by Martin Roetteler, Michael Naehrig, Krysta M. Svore, and Kristin Lauter, appears to confirm suspicions that ECC will fall to quantum computing before RSA does. That may have been another factor in the NSA’s announcement.

Symmetric algorithms (used by bulk encryption) are thought to be safe from quantum computing by merely doubling their key sizes, for example, using the advanced encryption standard AES-256 instead of AES-128.

How Post-Quantum Computing Will Affect TLS
So, what’s the problem that quantum computing introduces? Before we look at that, let’s start with the good news, which is that record processing in a quantum computing world will be exactly the same. That’s because the symmetric encryption ciphers (like AES) and hash message authentication code  (HMAC) hashing algorithms (like SHA) are thought to be mostly resistant to quantum computing, requiring only a doubling of key size to be resistant until the end of time. According to the NSA’s Information Assurance Directorate, "The AES-256 and SHA-384 algorithms are symmetric, and believed to be safe from attack by a large quantum computer."

F5 Labs’ own research shows that 75% of TLS hosts on the Internet already prefer AES-256, so we’re practically there already—at least for the record processing!

Figure 1. Quantum computing exposure, TLS 1.2 Protocol
Figure 1. Quantum computing exposure, TLS 1.2 Protocol

 

That leaves just the asymmetric encryption functions that need to be replaced: RSA, DSA, DH and their ECC variants, ECDSA and ECDH. Those are only used during the initial handshake phase of the TLS protocol, which for many clients is only done once per site, once per day, because of session reuse. That’s pretty good news when you think about it!

So, we don’t have to replace all of TLS, just shoe-horn in a new asymmetric handshake cipher. But which one will we use?

NIST Projected Timeline for Choosing Post-Quantum Algorithms
The National Institute of Standards and Technology (NIST) has issued a timeline by which they would like to see a post-quantum algorithm ready to replace the existing asymmetric algorithms. At the time of this writing (summer of 2017), we’re currently in the submissions phase, with deadlines for submissions at the end of November, followed by submitters’ presentations in early 2018. A three- to five-year analysys will follow when NIST will report findings, and one or two workshops will be scheduled. Finally, two years after that, draft standards may be read.

In 2009 two NIST researchers, Ray A. Perlner and David A. Cooper, published a white paper examining the (then) likely post-quantum algorithm candidates. They included the chart below showing some of the algorithms’ comparative metrics against non-post-quantum algorithms (RSA, DSA, DH, ECC).

Since that paper was published, new algorithms have found currency in the community. You quickly find that none are perfect!

Current Candidates for Post-Quantum Asymmetric Encryption Algorithms
Several candidates are already being discussed, all of which have chosen key sizes that achieve the 128-bit level of security necessary to be quantum-safe: NTRUEncrypt, McEliece with Goppa codes, and Ring Learning with Errors. One promising algorithm is Supersingular Isogeny Diffie-Hellman (SIDH).

SIDH uses the smallest key sizes of the candidates (3K public keys), can support forward secrecy, and is free of patents. However, SIDH is not perfect; some researchers have already been poking holes at it and have come up with some pretty disturbing attacks, which can be mitigated against, but  add a whole new rash of complications.

Related and Relevant IETF Projects
The IETF TLS working group has already started design work to fit a post-quantum algorithm into TLS. At the 93rd IETF in 2015, William Whyte proposed a hybrid handshake. Like Google’s CECPQ1, Whyte’s proposal uses a classical key exchange for half of the key, and a post-quantum key exchange for the other half. The two halves are then combined into a key derivation function to get the final master key, from which the rest of the session key data is derived.

If it seems unlikely that any of these algorithms will make an ideal candiate, well, that’s okay. Many people in the crypto community are skeptical that a large-scale quantum computer is even possible. But if it really does become a thing, we’ll be (sort of) ready for post-quantum in pretty short order, at least from a protocol point of view.

Get the latest application threat intelligence from F5 Labs.

 

 

David Holmes is the world-wide security evangelist for F5 Networks. He writes and speaks about hackers, cryptography, fraud, malware and many other InfoSec topics. He has spoken at over 30 conferences on all six developed continents, including RSA ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 4/7/2020
The Coronavirus & Cybersecurity: 3 Areas of Exploitation
Robert R. Ackerman Jr., Founder & Managing Director, Allegis Capital,  4/7/2020
'Unkillable' Android Malware App Continues to Infect Devices Worldwide
Jai Vijayan, Contributing Writer,  4/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-1633
PUBLISHED: 2020-04-09
Due to a new NDP proxy feature for EVPN leaf nodes introduced in Junos OS 17.4, crafted NDPv6 packets could transit a Junos device configured as a Broadband Network Gateway (BNG) and reach the EVPN leaf node, causing a stale MAC address entry. This could cause legitimate traffic to be discarded, le...
CVE-2020-8834
PUBLISHED: 2020-04-09
KVM in the Linux kernel on Power8 processors has a conflicting use of HSTATE_HOST_R1 to store r1 state in kvmppc_hv_entry plus in kvmppc__tm, leading to a stack corruption. Because of this, an attacker with the ability run code in kernel space of a guest VM can cause the host kernel to...
CVE-2020-11668
PUBLISHED: 2020-04-09
In the Linux kernel before 5.6.1, drivers/media/usb/gspca/xirlink_cit.c (aka the Xirlink camera USB driver) mishandles invalid descriptors, aka CID-a246b4d54770.
CVE-2020-8961
PUBLISHED: 2020-04-09
An issue was discovered in Avira Free-Antivirus before 15.0.2004.1825. The Self-Protection feature does not prohibit a write operation from an external process. Thus, code injection can be used to turn off this feature. After that, one can construct an event that will modify a file at a specific loc...
CVE-2020-7922
PUBLISHED: 2020-04-09
X.509 certificates generated by the MongoDB Enterprise Kubernetes Operator may allow an attacker with access to the Kubernetes cluster improper access to MongoDB instances. Customers who do not use X.509 authentication, and those who do not use the Operator to generate their X.509 certificates are u...