All Things Quantum - Quantum Security Series - Part 3
Reading time: 11 minutesSecrets are no longer secret. Communications have been breached. Information exchange is no longer safe. Digital apocalypse has arrived on the scene.
Governments accusing each other, companies facing billion-dollar lawsuits due to their users' privacy being compromised, the stock market crashing, cryptocurrency wallets hacked, password managers broken, blockchains filled with false yet valid transactions, DNS security broken, data leaks everywhere, the list goes on.
While this may sound crazy and far from reality, it could be our future in fifteen or twenty-five years, and most certainly if we don't have cryptography implemented that's difficult enough to protect us.
But using computers to break encryption isn't anything new at all. Computers were widely used for code-breaking activities in the early days of their modern history, in the discovery of secretly transmitted communications during World War II.
Source: Wikipedia - A Colossus Mark 2 codebreaking computer being operated by Dorothy Du Boisson (left) and Elsie Booker (right), 1943
The cat-and-mouse history of encryption creators and breakers has a solid background, and as the crypto community tells us, as computers evolved, stronger and stronger algorithms were broken.
- How safe are current encryption algorithms?
- Quantum algorithms
- Quantum computer programming using Qiksit
- What's actually state-of-the-art about post-quantum security?
- Post-quantum web server
- Post-quantum cURL
- Post-quantum web browser
- Conclusions
How safe are current encryption algorithms?
Pretty safe actually. Cryptography research is always ahead of its time, around 20 years ahead in fact. This is good news, as your web searches will remain private. Even so, some cryptographers claim that current encryption algorithms could be even safer than we think, especially when we compare them with several yet-to-be-proven post-quantum algorithms currently available. That's because encryption algorithms' strength and confidence are earned by repeated exposure to testing and analysis by the crypto community.
Below is a table that compares the state of the current algorithm's security level against resistance to a quantum powered cryptanalysis (more is better). Details include how many bits of security it has and the algorithm that can compromise or lessen its security:
Source: Post-quantum cryptography –dealing with the fallout of physics success
As you can see, some algorithms are going to be broken due to Shor's algorithm, which we briefly covered in "Quantum Security Series Part 1". But just how easy is it to break a code using Shor? We'll show you in this next section.
Quantum algorithms
First, let's showcase the two algorithms responsible for introducing doubt into the community—about the duration of safety for these classical encryption protocols:
-
Grover's quantum algorithm
Grover's search quantum algorithm was designed for searching particular targets through unstructured collections of records, much faster than with classical algorithms.
If you want to explore how it works a little more deeply, here's some nice animation that does the trick.
-
Shor's quantum algorithm
This factoring algorithm has been mentioned before in this series. It's a well-known quantum algorithm that finds prime factors for a determined integer. For this integer to be factored, it's expected to be an odd number greater than 2.
Quantum computer programming using Qiksit
One incredible difference between the early days of classical computing and contemporary quantum computing is the ability to use one of these machines remotely, to make simulations and even run your own experiments. This would be impossible without the advances of the Internet and traditional computation, cloud computing access, API access to connect scripts, and more.
What follows is a very simple example of the use of a Shor() function with Qiskit, an open source SDK for working with IBM Quantum processors. This example utilizes the quantum simulator running in the cloud to factorize an integer using prime numbers.
The process of breaking an RSA encryption key should look somewhat similar to this:
#!/usr/bin/env python3
import argparse
import threading
import time
from qiskit import IBMQ
from qiskit.aqua import QuantumInstance
from qiskit.aqua.algorithms import Shor
# Setup an argument parser for the CLI
parser = argparse.ArgumentParser()
parser.add_argument("number", type=int, nargs=1, choices=range(3,31,2), default=15,
metavar='[3-29]', help="Choose an odd number between 3 and 29")
args = vars(parser.parse_args())
number = args["number"]
print('\n --------------------------------------------')
print(' [+] Executing Shor\'s Algorithm')
print(' --------------------------------------------')
print(' [-] Accessing IBM API')
# Configure your IBM Account (https://quantum-computing.ibm.com/)
YOUR_IBM_API_KEY = 'Complete this with your Q-IBM API KEY'
IBMQ.enable_account(YOUR_IBM_API_KEY) # Enter your API token here
def factor(number):
result = ''
print(' [-] Accessing IBM Quantum Hardware/Simulator')
provider = IBMQ.get_provider(hub='ibm-q')
backend = provider.get_backend('ibmq_qasm_simulator') # Specifies the quantum device
print(' [-] Factoring number ' + str(number) + ' using Shor() ...')
factors = Shor(number) # Function to run Shor's algorithm
results = factors.run(QuantumInstance(backend, shots=1, skip_qobj_validation=False, timeout=120))
print(' [-] End of factoring ...')
result = results['factors']
if result:
print(' [>] Factoring result -> ' + str(result[0]))
else:
print(' [>] Result is empty, server timeout or maybe a prime number?')
return
# Start thread
result_dict = threading.Thread(target=factor,args=number)
result_dict.start()
# Animation setup
animation = "|/-\\"
idx = 0
while result_dict.isAlive() == True:
print(" [" + animation[idx % len(animation)] + "]", end="\r")
idx += 1
time.sleep(0.1)
print('\n [+] The End =)')
Code based on Shor's algorithm with code work.
There is also an excellent and in-depth explanation available as a Jupyter notebook, so you can play with the code and see the resulting quantum circuit yourself, in this link.
Execution of this script should look like this:
python3 shor-tutorial.py 21
--------------------------------------------
[+] Executing Shor's Algorithm
--------------------------------------------
[-] Accessing IBM API
[-] Accessing IBM Quantum Hardware/Simulator
[-] Factoring number 21 using Shor() ...
[-] End of factoring ...
[>] Factoring result -> [3, 7]
[+] The End =)
At this time you won't be able to run this function using large integers, but for educational purposes you can get an idea of how easy it could be to write a key-cracking app using Qiskit.
What's actually state-of-the-art about post-quantum security?
The National Institute of Standards and Technology (NIST) has a special chapter devoted to cryptography, in which they have open contests for people to present new encryption algorithms that addresses special needs—in this case quantum secure encryption algorithms.
So far, post-quantum crypto standardization has reached its second round with 26 candidate submissions split between public-key encryption, key-establishment, and digital signature algorithms.
Why must encryption algorithms be reviewed and open? Well, there are several horror stories about poorly implemented algorithms that weren't sufficiently checked by the crypto community and were prone to easy attacks. When it comes to encryption, security through obscurity is not a good choice.
Post-quantum web server
Today we'll use docker containers to easily fast-deploy a quantum-safe web server. The openqsafe repository has several pieces of post-quantum encryption-capable software, which you can browse through here and also by checking out the Github repo.
First, we want to pull the openqsafe/nginx-generic container to our OS. This will download the image and keep it ready for future use:
docker pull openqsafe/nginx-generic
Using default tag: latest
latest: Pulling from openqsafe/nginx-generic
[...]
Next, we'll deploy a new instance using "docker run" called "--name nginx-pq" and tell it to become a daemon using "-d". After this, in the same line we'll include a port forwarding between the host machine 4433/tcp and the container's 4433/tcp ports using "-p 4433:4433":
docker run -d --name nginx-pq -p 4433:4433 --restart always openqsafe/nginx-generic
You can check the already included server certificate like this:
../openssl/apps/openssl x509 -in server.crt -noout -text | head -n20
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
0d:12:18:46:0e:01:41:40:b0:a1:ab:fe:f5:bf:0f:81:f5:d4:f0:61
Signature Algorithm: dilithium2
Issuer: CN = oqstest CA
Validity
Not Before: Apr 14 16:16:25 2020 GMT
Not After : Apr 14 16:16:25 2021 GMT
Subject: CN = nginx.server.openquantumsafe.org
Subject Public Key Info:
Public Key Algorithm: dilithium2
dilithium2 Public-Key:
pub:
97:93:da:da:fe:3d:c8:9f:4c:a6:c8:f1:64:82:8f:
00:00:d7:93:e2:26:58:eb:d0:c7:d6:12:c3:94:fe:
19:60:71:c4:de:06:23:29:95:4b:47:f0:af:b6:4b:
55:1c:b5:49:0d:d6:e3:22:ef:33:ea:be:ac:5f:01:
6b:3a:d7:6d:06:8d:30:b4:02:6f:a3:39:04:86:ae:
[...]
Post-quantum cURL
The same procedure can be used to pull or push data into your quantum-safe web server using this fork of the well-known cURL software.
First we download our curl docker image:
docker pull openqsafe/curl:latest
Then we start the image in an interactive-terminal mode and we include --rm for the container to be destroyed after use:
docker run -ti --rm openqsafe/curl
Once we're in the container, we can run the curl program against the previously deployed Nginx server:
curl -v -k https://172.17.0.3:4433
* Trying 172.17.0.3:4433...
* Connected to 172.17.0.3 (172.17.0.3) port 4433 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /opt/oqssa/bin/CA.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=nginx.server.openquantumsafe.org
* start date: Apr 14 16:16:25 2020 GMT
* expire date: Apr 14 16:16:25 2021 GMT
* issuer: CN=oqstest CA
* SSL certificate verify result: certificate signature failure (7), continuing anyway.
You can even do all of this with this one-liner:
docker run -ti --rm openqsafe/curl curl -v -k https://172.17.0.3:4433
Take note that you should replace the https://172.17.0.3:4433 in this example with the URL corresponding to your deployment.
What else can you do? Now that we have a post-quantum web server and a CLI program that speaks the same algorithms, let's get a quantum-safe web browser.
Post-quantum web browser
For this topic, we'll give you access to the instructions needed for building a post-quantum protected web browser, found in this link. This can be a very time-and resource-consuming process, but the output allows you to have a chromium web browser capable of handling post-quantum ciphers to secure your client-server communications.
This will enable you to safely browse your web servers once post-quantum algorithms are deployed. Please remember that all of this software is highly experimental and not at all suited to production environments.
Conclusions
Now we've reached the end of the "Quantum Security Series". We've covered the state of quantum computers at the time of this writing, as well as the related security concerns that should be addressed in the future. Topics that didn't make it into this series, but are definitely worth mentioning, include:
-
Quantum entropy - QRNG's, how to get truly random seeds, and why it's important for cryptography
-
Quantum circuit programming - How to develop algorithms using quantum logic gates that will run in a QPU
-
Quantum Internet - Quantum memory and how to hold state information inside particles longer
-
Other quantum-resistant services and protocols - These include quantum-safe encryption applied in POP, IMAP, SMTP, DNSSEC, DKIM, etc.
These topics will amaze you. And to summarize the topics and subjects we have managed to cover:
-
How quantum-powered cryptanalysis affects the status quo:
- It affects almost all currently in-use encryption (asymmetric key and signature especially due to Shor and Grover algorithms)
- Key rotation is paramount, services that are friendly to easy key rotation shouldn't have any hard issues
- DNSSEC, DKIM, TLS/SSL on HTTPS/POP/IMAP/SMTP, to name a few, should be very easy to upgrade once needed (this depends on client post-quantum support also)
- There are no NIST-declared standards at this time; will have to wait a couple of years until algorithms are well proven
- Post-quantum key length could be an issue, regarding performance and up-to-date protocols supporting them
- Tricky scenarios could be certificate authorities, what to implement and when to do it should require a little more planning, long-lived keys if can be-should be avoided
-
How quantum-cryptography affects security:
- Quantum key distribution protects the secure handshake of communications
- Keys cannot be eavesdropped due to quantum phenomena, information is lost otherwise
- This is in a very early stage, telecommunication links are not very long (2000 km using 32 repeaters), they need repeaters and transmission speed is not very fast
- All quantum teleportation needs confirmation through a traditional channel, such as the common Internet, to work
- There are quantum Internet initiatives to interconnect different networks but they're currently researching how to solve hard problems like quantum memory for repeaters or quantum decoherence
Quantum computers and networks are the future, there's no doubt about that, but even the experts on this topic say that everything could change in the next few years. The result could be completely different from what we do and know today. Quantum mechanics, the foundation of these disciplines, is still a mystery… so the remaining question is...
Are we there yet?
Do you want to discover how exposed to data leaks your company really is? Search your historic records across different protocols such as WHOIS and DNS by taking advantage of our SecurityTrails API and SurfaceBrowser™ tools.
To learn what else we can do for you and check out which of our products can help your security team stay ahead of unwanted threats, contact our sales team and schedule a call today!
