Quantum Computing will not be able to crack Encryption Keys until the 2030s

In September, Satya Nadella announced that Microsoft is working on a quantum computer (QC) architecture. Since then, Intel also has announced it is working on a QC architecture. Microsoft and Intel join Alibaba, Google, IBM, Tencent and a host of academic and national research labs (including China, the European Commission, Russia and the US) in a quest to build working QC hardware and software that can solve real-world problems.

What is quantum computing and why will it make a difference?

Quantum Computing is a practical application of quantum physics using individual subatomic particles at sub-Kelvin temperatures as compute elements. It presents many research and development challenges, but the potential payoff is orders-of-magnitude faster compute acceleration for specific types of problems.

QC is like computing with a graphics processing unit (GPU) accelerator, in that GPUs and QC systems must be connected to a traditional processor that can run an operating system and schedule programs to run on the accelerator.

QC has the potential to quickly solve problems that are impossible to calculate in useful timeframes (or even human lifetimes) today.

One of the marquee potential applications for QC is breaking cryptographic keys—in other words, compromising security encryption that protects sensitive data. While a lot has been written about that, it is unlikely QC will be capable of cracking encryption keys until the 2030s. Here’s why it will take so long.

Challenge 1: Programming QC

QC architecture is based on “qubits” instead of binary computer bits. I am not a quantum physicist, so I’m not going to tell you how or why a qubit works. The analogy I use to describe how a QC program works is that multiple qubits interact like the waves generated by throwing a handful of small floating balls into a pool of water.

Assume that the distances between balls and the timing of when each ball hits the water are purposeful: the relative position of each ball and the order in which they hit the water is the program. The intersecting wave fronts between the balls then changes the up/down position of each of the balls in interesting patterns. At some point the position of each ball is measured, and that collection of measurements is the result of a QC program.

My analogy is easy to visualize but far too simple. It doesn’t explain how to write a QC program, nor does it tell you how to interpret the results.

However, that lack of connection to real-world programming talent and domain experience is actually just like real QC architectures! I’m not joking. Look at IBM’s Quantum Experience Composer, as an example. It looks like a music staff. But I’m not a musician, or in this case I’m not a quantum physicist who understands IBM’s QC system. For a mainstream software professional, it’s difficult to understand how to use IBM’s composer and how it is useful in solving a real-world problem. Programmers can place notes on the staff, but those notes won’t make any sense. Even after reading the detailed instructions, programmers will not be able to translate a problem in their real-world domain into a program in the QC domain.

The challenge in finding a quantum physicist who understands how to program a specific QC architecture and who understands the problem you want to solve is much worse than finding a Masters- or PhD-level data scientist to analyze all that big data you’ve been hoarding. It would be like trying to find a needle in a thousand haystacks.

Because of this challenge, QC ecosystems will have to create application programming interfaces (APIs) and then create libraries of useful functions with those APIs to hide QC complexity and enable programmers to use QC systems without knowing how QC systems work or how to compose programs for QC. For example, IBM’s QISKit enables QC acceleration through Python language APIs. However, those APIs still depend on programmers understanding quantum physics. The next step is to create libraries of useful QC acceleration functions.

Challenge 2: Getting a stable result from a QC program

One of the key challenges for QC is to make sure that the qubits are all working properly when a program starts and that they continue to work correctly until each qubit’s end-of-program state has been observed.

This is a lot harder than it sounds.

First, it requires freezing the qubits to nearly “absolute zero” just to have a fighting chance of keeping them in proper working order until a calculation is finished. Absolute zero (0°Kelvin / -459.67°Fahrenheit / -273.15°Celsius) is an ideal absence of any heat or movement at all; it is impossible to achieve in our universe, due to fundamental laws of thermodynamics. Qubits require 0.01°K / -459.65°F / -273.14°C, vanishingly close to absolute zero. That is a lot colder than deep space and expensive to achieve.

Because it is so difficult to get qubits to behave properly for long enough to finish a program, even at these low temperatures, QC architectures need to design error detection and correction into each qubit. Qubits with error detection and correction are interchangeably called a “fault-tolerant” qubits or “logical” qubits.

Directly observing a qubit ends a program. QC architectures must entangle extra qubits with a computing qubit, so a QC program can infer the state of a computing qubit without directly observing it (and thereby stopping a calculation). If an error is observed, then the erroneous qubit state can be corrected and the QC calculation completed.

Today, a lot of extra physical qubits are needed to create a logical qubit, on the order of 10s to thousands of extra physical qubits depending on the architecture. A single physical qubit is possible, if the structure of the qubit itself is fault-tolerant. Microsoft is claiming a breakthrough in materials-based fault-tolerant qubit design called “topological” qubits. Microsoft’s topological qubit contains only one physical qubit, based on a pair of Majorana fermion particles, but that breakthrough has not yet been confirmed by outside labs.

Challenge 3: Assembling and programing qubits as a QC accelerator

Today’s state-of-the-art is that no one has publicly shown even a single functional logical qubit. All demonstrations to-date have only used physical qubits. Public demonstrations are getting more complex as labs learn to orchestrate the manipulation and measurement of tens of physical qubits. For example, a Russian team implementing 51 physical qubits now leads the field.

Solving useful real-world problems, such as breaking 128-bit encryption keys, will require assembling and orchestrating thousands of logical qubits at near absolute zero temperatures. It will also require learning how to write complex programs for QC architectures. There are QC algorithmic frameworks for writing programs that can help speed up cracking encryption keys, such as Shor’s and Grover’s algorithms, but QC researchers still don’t understand how to frame those algorithms as an expression of qubit interactions (intersecting wave fronts in my example above).

Researchers are learning to build QC systems that can reliably orchestrate thousands of logical qubits. And they are learning how to usefully program those qubits. Then they must build a software ecosystem to commercialize their QC systems. Of course, it also requires building thousands of qubits.

Using graphics processing units (GPUs) compute as a model, QC must implement layers of software abstraction and easy to use development environments, so average programmers can use QC systems as compute accelerators without having to understand how to program any specific QC system.

Caution: QC objects through the looking glass are farther than they appear

There are some near-term applications for physical qubits: mostly solving optimization and quantum chemistry problems. Many of these problems can be solved using hundreds to thousands of physical qubits.

A raft of companies that are heavily invested in deep learning are also counting on physical qubits to accelerate deep learning training. Alibaba, Google, IBM, Microsoft and Tencent are all focused here. Integrating QC into the deep learning model creation process would be a neat way of side-stepping challenge #1 (programming), because QC programming would be hidden from human programmers by deep learning abstraction layers.

Many of the companies investing in physical qubits are striving to commercialize their QC architectures within the next five to ten years. This seems doable, given the level of investment by some of the larger competitors but still relies on several research breakthroughs, and breakthroughs cannot be scheduled.

All the QC researchers I have talked with say that shipping a commercial QC accelerator based on logical qubits is still at least 15 years away, pointing to commercialization in the early 2030s at the soonest. There is still a lot of fundamental science left to be done. Commercializing that science will take time. So too will building a programming ecosystem to make QC accelerators accessible to a wide range of programmers.

Breaking the code on quantum cryptography futures

The US National Institute of Standards and Technology (NIST) is working on detailed recommendations for a post-QC cryptography world. NIST issued a formal call for proposals last December; November 30, 2017 is the deadline for submissions. NIST’s intent is to issue draft standards on post-quantum cryptography in the 2023-2025 timeframe, about halfway through an industry consensus minimum 15-year QC development and commercialization period.

NIST has quantum physicists on staff. Many of its customers build and deploy systems that will spend decades in the field. Between now and NIST’s draft post-quantum cryptography standards, NIST published a concise summary of interim cryptographic safety measures.

QC will not break encryption keys this decade. Without massive research and development breakthroughs, the QC researchers I have talked with do not believe that QC will break encryption keys during the next decade, either.

It will happen at some point, but there are reasonable steps that can be taken now to keep data safe for at least a couple of decades. In a few years NIST, and presumably sibling governmental organizations across the globe, will publish stronger recommendations that will directly address post-quantum computing cryptographic safety.

Still confused? You are in good company. A key fact to remember is that QC is still at the beginning of a very long road to commercialization.

Biometric data becomes the encryption key in Fujitsu system

Biometric data becomes the encryption key in Fujitsu system

Fujitsu says it has developed software that uses biometric data directly as the basis for encryption and decryption of data, simplifying and strengthening security systems that rely on biometrics such as fingerprints, retina scans and palm vein scans.

Current security systems that rely on encryption require the management of encryption keys, which are stored on secure smartcards or directly on PCs. Biometric scans can be used as a way of authenticating the user and providing access to those encryption keys in order to decrypt data.

Fujitsu’s system uses elements extracted from the biometric scan itself as a part of a procedure to encrypt the data, making the biometric scan an integral part of the encryption system and removing the need for encryption keys.

That has two big benefits, according to the company.

The lack of encryption keys means there’s no need for smartcards and hackers won’t have anything to find should they break into a network.

The second major benefit comes from biometric data use with cloud services. With current systems, a user’s biometric data is potentially vulnerable as it’s sent over the Internet to allow log-in to a service. Because Fujitsu’s new system uses random numbers to convert the biometric data as part of the encryption and decryption process, unconverted data is not transmitted over a network.

The procedure employs error correction to smooth out slight differences in successive biometric scans that are the result of variations in a user’s position or motion when the scan is taken.

At present, the system has been developed to work with palm vein authentication, a technology that Fujitsu has spent years developing and has already deployed on systems like bank ATMs in Japan. But the company said it could readily be adapted to work with other biometric data such as fingerprints or retina scans.

The software was developed by Fujitsu Laboratories and two Japanese universities, Kyushu University and Saitama University, and is being presented this week at the 8th International Symposium on Foundations and Practice of Security in Clermont-Ferrand, France.

Whose keys are they anyway?

Whose keys are they anyway?

Google recently announced enhanced security support for its cloud customers by granting them the ability to hold the encryption keys to their data. These customer-supplied encryption keys for the Google Cloud Platform follow the example set by other cloud industry leaders such as Amazon Web Services and Box and position the tech giant as an advocate for user data privacy.

The many federal IT managers who rely on Google Cloud and AWS are now able to develop a more sound security strategy when it comes to adopting the cloud. Government security managers running Google Cloud should educate themselves on the various cloud encryption models available and also consider which complementary security solutions must also be implemented. Depending on the cloud encryption model employed, cloud data may be susceptible to unauthorized access by cloud service provider insiders or be moved to other jurisdictions that might present data sovereignty issues.

Let’s break it down.

Server-side encryption. At the most basic level of the cloud encryption models, there is server-side encryption (SSE), where the encryption is performed by the cloud service provider using keys it owns and manages itself. Server-side encryption is the most vulnerable cloud encryption model, as the key unlocking access to the data is in control of the cloud provider. While SSE provides a basic level of encryption, it does not provide enterprise security control nor does it help protect against insider attacks because service provider employees could access the data intentionally or by mistake.

Server-side encryption with customer-provided keys. What Box, AWS and now Google offer is server-side encryption with customer-provided keys (SSE-CPK). In this model, the cloud provider handles the encryption but hands the keys the customer to own and manage. The cloud service provider runs the encryption in its underlying infrastructure and promises to only keep the keys in memory while the virtual machine is up and running. However, the keys still flow through cloud provider application programming interfaces, so it is not much of a stretch for the cloud provider to divert or intercept the keys.

Client-side encryption. The most secure solution is client-side encryption (CSE), which occurs in the cloud but it is initiated and managed by the data owner. The customer selects the encryption method and provides the encryption software. Most important, the customer owns and manages the encryption keys.

This approach allows customers to store and manage the keys for the virtual machines on their own premises or in a controlled instance in the cloud. When the virtual machine boots up in the private or public cloud, it can use a pre-boot network connection to an enterprise-controlled intelligent key manager to retrieve the key.

In the announcement of SSE-CPK on Google’s blog, the company chides, “Keep in mind, though, if you lose your encryption keys, we won’t be able to help you recover your keys or your data – with great power comes great responsibility!” The onus is indeed on the customer to not only keep the keys close, but keep them safe. The most responsible move for IT admin is to have an enterprise-controlled intelligent key management solution to manage crypto activities.

Google’s support for SSE-CPK is a step in the right direction to giving enterprises control over who accesses their data, but it still falls short of client-side encryption. Only with the CSE model – where both the encryption and keys are initiated and managed by the data owner, not the cloud provider – does the customer have the most protection and control possible in the cloud.

China backs off legal push that would force foreign tech companies to hand over encryption keys

China backs off legal push that would force foreign tech companies to hand over encryption keys

“They have decided to suspend the third reading of that particular law, which has sort of put that on hiatus for the moment,” White House Cybersecurity Coordinator Michael Daniel said earlier this week, asnoted by Reuters. “We did see that as something that was bad not just for U.S. business but for the global economy as a whole, and it was something we felt was very important to communicate very clearly to them.”

If China has pressed forward, it could have put Apple in an impossible position. China is one of the company’s most important markets, but chief executive Tim Cook has staunchly opposed any attempts to violate the privacy of Apple’s customers.

While there are “rumors of us keeping backdoors and providing data to third parties,” Cook is said to have told top Chinese internet regulator Lu Wei during a meeting last year, the company has “never had any backdoors and never will.”

Cook was even more emphatic during an appearance at the White House’s Summit on Cybersecurity and Consumer Protection, held last month at Stanford University.

“If those of us in positions of responsibility fail to do everything in our power to protect the right of privacy, we risk something far more valuable than money,” Cook said. “We risk our way of life.”

Personal privacy is especially important “in a world in which that information can make the difference between life and death,” he added.

A similar set of Chinese government regulations aimed at companies competing for large-scale infrastructure projects has not been affected. Those guidelines call not only for backdoors, but also for companies interested in selling software or hardware to turn over their source code to the government.

Building backdoors into encryption isn’t only bad for China, Mr President

Building backdoors into encryption isn't only bad for China, Mr President

Want to know why forcing tech companies to build backdoors into encryption is a terrible idea? Look no further than President Obama’s stark criticism of China’s plan to do exactly that on Tuesday. If only he would tell the FBI and NSA the same thing.

In a stunningly short-sighted move, the FBI – and more recently the NSA – have been pushing for a new US law that would force tech companies like Apple and Google to hand over the encryption keys or build backdoors into their products and tools so the government would always have access to our communications. It was only a matter of time before other governments jumped on the bandwagon, and China wasted no time in demanding the same from tech companies a few weeks ago.

As President Obama himself described to Reuters, China has proposed an expansive new “anti-terrorism” bill that “would essentially force all foreign companies, including US companies, to turn over to the Chinese government mechanisms where they can snoop and keep track of all the users of those services.”

Obama continued: “Those kinds of restrictive practices I think would ironically hurt the Chinese economy over the long term because I don’t think there is any US or European firm, any international firm, that could credibly get away with that wholesale turning over of data, personal data, over to a government.”

Bravo! Of course these are the exact arguments for why it would be a disaster for US government to force tech companies to do the same. (Somehow Obama left that part out.)

As Yahoo’s top security executive Alex Stamos told NSA director Mike Rogers in a public confrontation last week, building backdoors into encryption is like “drilling a hole into a windshield.” Even if it’s technically possible to produce the flaw – and we, for some reason, trust the US government never to abuse it – other countries will inevitably demand access for themselves. Companies will no longer be in a position to say no, and even if they did, intelligence services would find the backdoor unilaterally – or just steal the keys outright.

For an example on how this works, look no further than last week’s Snowden revelation that the UK’s intelligence service and the NSA stole the encryption keys for millions of Sim cards used by many of the world’s most popular cell phone providers. It’s happened many times before too. Ss security expert Bruce Schneier has documented with numerous examples, “Back-door access built for the good guys is routinely used by the bad guys.”

Stamos repeatedly (and commendably) pushed the NSA director for an answer on what happens when China or Russia also demand backdoors from tech companies, but Rogers didn’t have an answer prepared at all. He just kept repeating “I think we can work through this”. As Stamos insinuated, maybe Rogers should ask his own staff why we actually can’t work through this, because virtually every technologist agrees backdoors just cannot be secure in practice.

(If you want to further understand the details behind the encryption vs. backdoor debate and how what the NSA director is asking for is quite literally impossible, read this excellent piece by surveillance expert Julian Sanchez.)

It’s downright bizarre that the US government has been warning of the grave cybersecurity risks the country faces while, at the very same time, arguing that we should pass a law that would weaken cybersecurity and put every single citizen at more risk of having their private information stolen by criminals, foreign governments, and our own.

Forcing backdoors will also be disastrous for the US economy as it would be for China’s. US tech companies – which already have suffered billions of dollars of losses overseas because of consumer distrust over their relationships with the NSA – would lose all credibility with users around the world if the FBI and NSA succeed with their plan.

The White House is supposedly coming out with an official policy on encryption sometime this month, according to the New York Times – but the President can save himself a lot of time and just apply his comments about China to the US government. If he knows backdoors in encryption are bad for cybersecurity, privacy, and the economy, why is there even a debate?