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!

 

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 7/9/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...