Harvest Now, Decrypt Later – Fact or Fiction?

A couple of years ago, I published a blog post AES Turns 20, celebrating the 20^th year since the trusted symmetric algorithm was approved by the National Institute of Standards and Technology (NIST). In the article, I dug into post-quantum and how Lov Grover’s quadratic speed-up algorithm might be applied to brute force attacks on symmetric algorithms. NIST’s position on this remains unchanged; symmetric algorithms such as AES 192 and AES 256 bit are good for the next couple of decades. The general recommendation persists: Anything with less than 112 bits of classical security should not be used. If there are any doubts, consider doubling the key length if you are using shorter bit lengths.

It got me thinking about the post-quantum threats being discussed and the Harvest Now, Decrypt Later attack frequently mentioned on technology websites and cited by some of my colleagues. I decided a blog post was in order to investigate a bit further. My colleague Dave Butcher, Technical Sales Consultant, is as passionate about PQ as I am, and I enlisted him to discuss the topic in more detail and exchange ideas.

First, a quick recap on what is meant by Harvest Now, Decrypt Later. The attack assumes that classical encryption techniques applied to data today, to make it unreadable and unusable, will in the future be vulnerable to attack from post-quantum computers. They will be able to crack the hard math problems that today’s computers would take in some cases hundreds and even thousands of years to solve. So, the idea is bad actors and nation-states will intercept and steal (harvest) data. They’ll then store it and wait until quantum computers are capable of crunching the numbers and decrypting the data to make it readable.

Data In Motion With TLS

Some of you might be thinking that most data at rest is encrypted using symmetric algorithms like AES, so surely we are in decent shape and this isn’t a real threat? I initially jumped to the same conclusion and then realized it is a bit more nuanced. Data at rest is typically encrypted using symmetric algorithms like AES and should be resilient to Harvest Now, Decrypt Later attacks. However, data is typically transported to a location before it comes to rest using network switches, routers, load balancers, etc. And this is where is gets a bit more nuanced. As data is moved around on the internet, a range of communication protocols are in play. Transport Layer Security (TLS) is the de facto protocol in use on the Internet securing HTTPS web pages, email, WhatsApp, and a myriad of other applications. To establish a secure connection between a client and server the TLS handshake is invoked:

1. The client sends a Hello message detailing the TLS version being used and available cipher suite.
2. The server responds back with their Hello message confirming TLS version and cipher suite followed by the server’s certificate, which includes the public key of the server’s asymmetric key pair.
3. This is then used in a key exchange where a symmetric-based session key is encrypted and sent to the server using the server’s public key.

The server now has the same symmetric encryption key as the client – this is a pre-requisite for symmetric encryption. A secure bi-direction channel is now established between client and server and data can be efficiently encrypted, transported, and stored at its final destination.

The main takeaway here is the session key is based on a symmetric algorithm, which is the most efficient way to encrypt bulk data – asymmetric algorithms are not efficient at
encrypting bulk data. Based on current NIST recommendations, as long as the symmetric key is a decent length of bits it’ll be resistant to a PQ attack. However, the asymmetric public/private keys used in the key exchange step are most likely using RSA- or elliptic-curve-based cryptography. These are the classical asymmetric algorithms that Peter Shor identified in the late 1990s as being vulnerable to being compromised by a quantum computer. It is unlikely that state-sponsored actors will be targeting data stored at rest; instead they’ll be targeting data in transit armed with the knowledge that asymmetric keys are used in the key exchange process. If they can intercept that transaction and store it away while biding their time, then in the future they’ll be able to use a quantum computer to factorize the asymmetric key pair, allowing them to expose the symmetric key and thus decrypt the data. Voila!

Actionable Steps to Mitigate Against Harvest Now, Decrypt Later

So, Harvest Now, Decrypt Later is a valid concern for organizations who store long-term encrypted data. What steps should you be taking to mitigate such attacks?

1. Start using longer symmetric key lengths. This is likely an easy change as AES with a 256-bit key has been part of the AES standard from the beginning. Most TLS services rely on standard TLS implementations that include configurable cipher suites. Changing to a longer key length is likely as easy as updating a configuration file and restarting a service. Many other tools you are using may also have this option.
2. Consider adding protection to communication paths that move high-value data to prevent Harvest Now, Decrypt Later later attacks. For example, there are VPN implementations (e.g. Open Quantum Safe’s OpenVPN project) that have been built using newer quantum-resistant cryptography. These are not fully standardized, but when you control both ends of a communication path (for example, between a branch location and headquarters) utilizing a non-standard protocol is not an issue.
3. Think about using pre-shared keys for certain interactions where you share symmetric encryption keys out of band, such as by exchanging physical media. This eliminates the asymmetric key exchange that is vulnerable to quantum computers.
4. Understand if there are already quantum-resistant versions of the protocol that you are using that you could migrate to today. For example, the Signal messaging protocol has been updated to be quantum-resistant. Consider becoming a first adopter.
5. Prioritize crypto-agility within your organization. Planning and building crypto-agility are going to be key to adopting quantum-safe cryptography. While this does not fix the problem today, it puts your organization in the best position to quickly adopt post-quantum cryptography as it becomes available and minimize the vulnerability window for Harvest Now, Decrypt Later.

One of the tools that can help you plan is Mosca’s Theorem. Understanding how long your data needs to be secure is key to prioritizing projects to mitigate Harvest Now, Decrypt Later. Data that has fleeting value is probably not at high risk for Harvest Now, Decrypt Later. Data whose value remains high even as time begins to approach the advent of cryptographically relevant quantum computers needs to be a priority for secondary protection. Mosca’s Theorem is discussed in more detail in an earlier blog post, A Bridge to Post-Quantum Cryptography.

The PQC Elephant in the Room

The elephant in the room when post-quantum cryptography is being discussed is “when”? When is this going to happen? The answer is of course we don’t really know. It could be five years away. It could also be 10 or 20+ years away. However, to play devil’s advocate, what if nation-state actors already have quantum computers with sufficient processing capability running in their labs? It’s not quite apples to apples, but there are some precedents. Public key cryptography was first postulated by Whitfield Diffie and Martin Hellman in 1976 and its implementation as RSA announced in 1977 by Rivest, Shamir, and Adleman. At least that is what was understood to be the case until in 1997 some UK secrets held by Government Communications Headquarters (GCHQ) became declassified, revealing that British mathematician Clifford Cocks, working for the intelligence agency, described an equivalent public/private key system in an internal document in 1973. Whether it was ever used is pure speculation, but it does illustrate the art of the possible. With that we will leave you to ponder, but at least you should now be clear that Harvest Now, Decrypt Later is real.

Learn more about Entrust and our post-quantum solutions here.