DEV Community: Aditee Niraula

Inside Shor's Algorithm: The Exact Math That Breaks RSA

Aditee Niraula — Sat, 12 Sep 2026 12:07:06 +0000

The first article in this series claimed that a quantum computer running Shor's algorithm would break RSA. The second showed you how to find RSA in the wild. This one shows you exactly how the break works, no hand-waving, no "quantum tries all answers at once." By the end you will be able to trace the full attack: from a public key, through period-finding and quantum interference, to the private key.

The short version

Shorʼs algorithm and RSA were first introduced in their respective articles. While the second article elaborated on the essence of RSA, this article describes the breaking mechanism of RSA without the need of vague descriptions or magical phenomena, where quantum computers “try all the possible answers at the same time.” After studying this article, you will be able to comprehend and outline the entire process of the attack from the quantum public key to the quantum private key achieved through interference and period finding.

The concise description

Shor’s algorithm does not employ the mechanism of “guessing the keys at an incredible speed.” What is done is far more precise, as it converts the RSA resting on the hard problem of factoring, which is, more or less, impossible to solve, into period finding, which, as a matter of fact, quantum computers do in an astonishing manner. Everything else in the process of breaking RSA is simple mathematics and does not require a quantum computer to be performed.

The anatomy of “breaking RSA”

As a quick reminder, the public RSA key is constructed of n and e, where n is the product of the two secret prime numbers p and q. The equation defining the private key exponent d is as follows:

e · d ≡ 1 (mod φ(n)), where φ(n) = (p − 1)(q − 1)

Once an attacker discovers the values of the secret primes p and q, φ(n) can be computed, and subsequently, d can also be calculated. Therefore, breaking RSA is completely equivalent to factoring n. Shor’s attack targets this particular problem.

Step 1. Convert factoring into period finding (classical phase of the attack)
Here is the pivot that makes the whole algorithm possible, and it involves no quantum anything. Pick any random number a less than n that shares no factor with n. Now look at this sequence:

a¹, a², a³, a⁴, … (mod n)
Because we are working mod n, this sequence must eventually repeat. The period r is the smallest positive exponent where:

aʳ ≡ 1 (mod n)
Once you know r, and if r is even, you can compute:

gcd(a^(r/2) − 1, n) and gcd(a^(r/2) + 1, n)
and — with good probability — those two gcd computations hand you p and q. That is not obvious, so let me show it on a real (tiny) number.

Worked example: factoring 15
Let n = 15, pick a = 7. Compute powers mod 15:

7¹ = 7
7² = 49 ≡ 4
7³ = 343 ≡ 13
7⁴ = 2401 ≡ 1 ← back to 1
The period is r = 4. It is even, so compute a^(r/2) = 7² = 49 ≡ 4 (mod 15). Then:

gcd(4 − 1, 15) = gcd(3, 15) = 3
gcd(4 + 1, 15) = gcd(5, 15) = 5
And 3 × 5 = 15. We just factored n by finding a period. No factoring algorithm was used, only "how long until this sequence loops?"

What you just learned: factoring is secretly a question about the period of a repeating sequence. The entire difficulty of RSA has been re-expressed as "find r." A classical computer finds r by grinding through the powers one at a time, hopeless when r is astronomically large (as it is for a 2048-bit n). This is where the quantum machine enters.

Step 2: Why a classical computer can't find r and a quantum one can
For a real RSA modulus, the period r can be on the order of n itself, a number hundreds of digits long. You cannot list that many powers before the heat death of the sun. So the problem is not "compute a period," it's "find the period of a function without evaluating it a catastrophic number of times."

A quantum computer sidesteps this using the machinery — amplitudes, superposition, and interference. Here is the honest mechanism, in four moves.

Move 1: Prepare every input at once (superposition)
Load a register of qubits into an equal superposition of all integers x from 0 up to some large Q. Using the amplitude language from before, the state is a sum over every x with equal amplitude:

(1/√Q) · Σ |x⟩
This is not magic "parallel universes." It is one arrow in a very high-dimensional space that happens to lean equally toward every basis direction |x⟩.

Move 2: Compute the sequence into a second register
Apply the function f(x) = aˣ mod n to a second register. The registers are now entangled: each input x is paired with its output aˣ mod n. Crucially, we never read this yet.

Move 3: The heart — the Quantum Fourier Transform
Now measure the output register. Because f is periodic with period r, many different inputs x produce the same output. The input register collapses to a superposition of only those x-values that map to the measured output and those surviving values are spaced exactly r apart:

|x₀⟩ + |x₀ + r⟩ + |x₀ + 2r⟩ + |x₀ + 3r⟩ + …
We now have a superposition whose structure is the period but we can't read it directly, because that random offset x₀ scrambles the answer. This is where the Quantum Fourier Transform (QFT) does the decisive work.

The QFT is an interference machine. It rotates the state so that amplitudes reinforce (crest meets crest) only at values related to Q/r, and cancel (crest meets trough) everywhere else, exactly the constructive/destructive interference, applied on purpose. The offset x₀ only affects phases that wash out. When you now measure, you get, with high probability, an integer close to a multiple of Q/r.

Move 4: Extract r classically
From that measured value c ≈ k·(Q/r), a classical technique called continued fractions recovers r. Then you're back in Step 1's worked example: even r → two gcds → the factors. Verify p × q = n on a normal computer. Done.

What you just learned: the quantum computer's only job is Move 3 — using interference to read off a period that is invisible to classical machines. Superposition sets up the interference; the QFT performs it; everything before and after is textbook number theory. "Quantum breaks RSA" precisely means "the QFT finds the period."

Step 3: Walking the full attack chain
Put the whole series together. Here is the complete path from public data to private key:

public n → [quantum: period-finding via QFT] → r
r → gcd(a^(r/2) ± 1, n) → p, q
p, q → φ(n) = (p−1)(q−1) → φ(n)
φ(n), e → solve e·d ≡ 1 (mod φ(n)) → d (the private key)

Notice something important: only the first arrow is quantum. The attacker literally re-runs RSA's own key-generation procedure in reverse. This is why the threat is so total, it doesn't exploit a bug or a weak implementation; it dissolves the foundational assumption itself.

How hard is this in practice?

If it's just one quantum step, why isn't RSA already dead? Because that one step is brutally demanding on real hardware.

Factoring a 2048-bit RSA key needs roughly 4000+ logical qubits running a coherent computation involving on the order of billions of gates.
A logical qubit is not a physical qubit. Today's physical qubits are noisy; you need quantum error correction, which may cost 1000 or more physical qubits per logical qubit. That pushes real estimates into the millions of physical qubits.

The computation must stay coherent, interference is fragile; a stray interaction with the environment (decoherence) collapses the delicate amplitude pattern before the QFT can finish.

Current devices have on the order of hundreds to low-thousands of physical, noisy qubits with no full error correction. That's the gap. Most public estimates put a cryptographically relevant machine a decade or more out which is exactly the reasoning behind "Harvest Now, Decrypt Later" from the first article. The machine isn't here, but the math is certain, so the migration starts now.

Grover, briefly — why symmetric survives

The first article promised symmetric encryption mostly survives. Now you can see why in one line: Grover's algorithm searches an unstructured space of N keys in about √N steps instead of N. That turns AES-128's 2¹²⁸ effort into ~2⁶⁴ — uncomfortable — but AES-256 into ~2¹²⁸, which remains infeasible. Double the key, restore the margin. There is no period to exploit in AES, so Shor simply does not apply; the best quantum attack is the far weaker Grover speedup.

Key takeaways

Shor doesn't brute-force keys. It reduces factoring to period-finding, a problem quantum interference solves efficiently.
The reduction (Step 1) and the extraction (continued fractions, gcd) are classical. The only quantum part is the QFT finding the period.
Once you have the period → the factors → φ(n) → the private key d. The attacker runs key generation in reverse.
The obstacle is error-corrected scale: thousands of logical qubits, likely millions of physical ones, held coherent. That's the runway we're migrating across.

Avoiding the 5 Mistakes Most Tutorials Make When Creating a File Encryption Tool

Aditee Niraula — Sat, 08 Aug 2026 09:24:02 +0000

Why “it encrypts” doesn't equate to “it’s secure”

If you want to find a tutorial for encrypting files in code, your search results will provide dozens of tutorials. Most of these tutorials will produce code that, on the surface, performs encryption. Users can provide plaintext, receive ciphertext, and the code also performs decryption.

Unfortunately, the phrase “the output looks scrambled” is an unsecure way to test a program for security. These tutorials fail to incorporate security practices, which will result in these tools being rejected in real life security assessments.

By identifying these mistakes, we can reason about the validity of these encryption schemes. This article covers the correct way to build a file encryption tool and the mistakes that beginner encryption tools include. These mistakes will help you learn the correct way to build an encryption tool.

SecureVault (Node.js, packaged with no dependencies) is a command-line tool that is referenced throughout to help provide context to the design decisions that were made for this tool.

Prerequisite mindset: When designing secure systems, always assume that the attacker knows more than you. Do you really think that your adversary will only submit the inputs you assumed they would submit? They will submit corrupted inputs, they will submit old ciphertexts, and they will do anything you thought was impossible. You need to have a secure design. You must think "what malicious inputs can I handle here?".

The goal: three guarantees, not one

Before you even think about writing code, you need to know exactly what you mean by that something is secure. A good file encryption tool must provide three guarantees. Most of the tutorials that I have seen think only about the first one.

Confidentiality - the attacker that steals the file should not be able to read the file.
Integrity - If the attacker alters the encrypted file, you will know.
Authenticity - The file can only be generated by a user that knows the password, and ciphertext of a wrong key cannot be generated at all.

Keep these three in mind. The mistakes that I will show you are all failures to protect one of these three guarantees.

Mistake #1: Using the password directly as the key

This is the most common mistake. The code asks for a password, and let's say that the password is password123, and the program is using the password directly as the key.

Why it's dangerous:

The keys to the encryption must be a certain size and must be very long and must be very high entropy . A password less than the required size is very predictable and can be easily guessed. This means that there is no protection against brute force. If verifying a certain password is cheap, the attacker can try billions of them per second.

The fix: a Key Derivation Function (KDF).

KDFs take a weak passphrase and, through intentional repetition, stretch that passphrase into a strong key. SecureVault implements PBKDF2 with 200,000 iterations of SHA-256:

function deriveKey(password, salt) {
  return crypto.pbkdf2Sync(
    password,
    salt,
    200000,        // iterations — deliberately slow
    32,            // 32 bytes = a 256-bit key
    'sha256'
  );
}

There are two reasons why this is secure. First, the output is a full-strength 256-bit key no matter how short the password was. Second, and more cleverly, running the hash 200,000 times makes malicious password attempts much slower. You hardly notice the 200,000 iterations when you log in, but an attacker is trying to test a billion passwords, so they will suffer that cost a billion times over. This is a case where the slowness is a feature, not a bug.

Modern implementations like scrypt and Argon2 go further by also consuming a lot of memory, which defeats specialized cracking hardware. PBKDF2 is the well understood baseline; the principle — make guessing deliberately expensive — is what counts.

Mistake #2: No (or a constant) salt

Let's say two users choose the password summer2024. If you derive the key from the password, they would get the same key; an attacker would compute a huge "password → key" table and instantly crack every account. These tables are known as rainbow tables.

The solution is: a random unique salt with every file.

A salt is a random value that is appended to the password when computing the key. It is not required to be kept secret, but it must be different for each password. The same password with a different salt leads to a different key, so:

The attacker would need a different unique salted table for each salt.
Two users selecting the same password will not collide.

const salt = crypto.randomBytes(16);   // fresh, random, per file
const key = deriveKey(password, salt);

The salt is stored in the clear alongside the ciphertext — that's fine and expected. Secrecy isn't its job; uniqueness is.

Mistake #3: Reusing the IV (or hardcoding it)

Block ciphers like AES need a second input besides the key: an IV (Initialization Vector), sometimes called a nonce. Its job is to make sure that encrypting the same plaintext twice produces different ciphertext.

Beginner code often hardcodes the IV to all zeros, or reuses one fixed value. This is catastrophic.

Why it's dangerous:

With a repeated IV, encrypting the same message always yields the same ciphertext. An attacker who sees two identical ciphertexts learns the two plaintexts are identical — a real information leak.
For some cipher modes, IV reuse is fatal — with AES-GCM specifically, reusing an IV with the same key can let an attacker recover the authentication key and forge messages. It doesn't just weaken the scheme; it collapses it.

The fix: a fresh random IV for every single encryption.

const iv = crypto.randomBytes(12);     // new every time, never reused with a key
const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);

Like the salt, the IV isn't secret. Store it with the file. The rule is simply: never reuse an IV under the same key. The easy way to guarantee this is to generate it randomly every time.

Thus, in SecureVault's tests, encrypting the same input twice is a security test, not a triviality, if the outputs differ — it means the IV is actually doing its job.

Mistake #4: Encrypting without integrity (the big one)

This is the largest mistake on the list because the code almost looks right. A lot of tutorials will go over how to use AES in the CBC or CTR mode to encrypt the data and that is the end of the road. Congrats, you've achieved confidentiality. Now, integrity is still nonexistent.

Why it's dangerous:

While the data may be concealed, it does not prevent an attacker from changing it. Bit flipping is a perfect example of how this is performed in a mode of encryption that does not support integrity — and it is done, on many occasions, without the attacker even having access to the key. This is an actual attack that is known as the padding oracle. Your program would decrypt the tampered file and give the attacker the data, while the victim remains unaware of what has happened.

In conclusion, integrity is a must. You think the file is protected, but really, anyone in the middle can rewrite it.

The fix: authenticated encryption (AEAD)

Use encryption modes that provide both secrecy and integrity. Standard choice is AES-GCM (GCM = Galois/Counter Mode). When encrypting, GCM provides an additional output called the authentication tag: a cryptographic fingerprint of the ciphertext. It also allows the receiver to detect any modification of the ciphertext. If the tag verification fails, the ciphertext will be discarded and an empty message will be sent to the receiver.

Remember: state size of AES-GCM (Galois/Counter Mode) is 128 bits, therefore, its throughput is 128 bits. AES-GCM supports arbitrary-length messages. However, the size of the authentication field is fixed and limited to 64 bits. That offers a lot of protection, but in general, the integrity of longer messages is usually more vulnerable.

"an empty message will be sent to the receiver." should be explained in more detail.

const cipher = crypto.createCipheriv('aes-256-gcm', key, iv);
const ciphertext = Buffer.concat([cipher.update(plaintext), cipher.final()]);
const authTag = cipher.getAuthTag();   // 16-byte integrity fingerprint

On decryption, you supply that tag back, and GCM verifies it before giving you any plaintext:

const decipher = crypto.createDecipheriv('aes-256-gcm', key, iv);
decipher.setAuthTag(authTag);
// If the password is wrong OR the file was modified, .final() throws:
return Buffer.concat([decipher.update(ciphertext), decipher.final()]);

If even a single byte of the ciphertext were to be changed, or if the incorrect key is applied, the tag won't match and decryption will be quiet and return destructive data. That single mechanism provides integrity and authenticity for free.

If you ever need to combine a separate cipher and MAC, the right order is Encrypt-then-MAC: first, you encrypt and then you authenticate the ciphertext. But the modern advice is simpl and clearer — use AEAD and don’t invent anything.

Mistake #5: Failing "open" instead of "closed"

This last mistake is more of a behavioral than a functional problem, and it deals with the user experience of your tool.

What does your tool do in the case of an incorrect password, or if the file is corrupted, or the input malforms.

Insecure code usually fails open: the error is catched and returned, and whatever it partially produced to the output file is returned (most likely garbage). The user thinks they got their data; in reality it's nonsense or attacker influenced.

The fix: fail closed. If the verification of whatever condition fails, you do not produce output. And, in a clear and detailed manner, you state the error:

try {
  return Buffer.concat([decipher.update(ciphertext), decipher.final()]);
} catch (err) {
  throw new Error(
    'Decryption failed — wrong password, or the file has been corrupted or tampered with.'
  );
}

A secure tool either produces absolutely correct output or no output at all. This is the same as the lock that, when picked, remains jammed shut instead of springing open.

Putting it together: the file format

The right decisions give a design that almost completes itself. Each piece of material that is non-secret and necessary for decryption is included in the file; only the password is retained in the user's head. The layout of the vault in SecureVault is as follows:

[ MAGIC | salt | iv | authTag | ciphertext ]
   4      16    12     16        N bytes

MAGIC — 4 signature bytes to recognize its own format to help ignore junk early.
salt — changes the key with the password (Mistake #2 fixed).
iv — changes the key with the password (Mistake #3 fixed).
authTag — changes the key with the password (Mistake #4 fixed).
ciphertext — changes the key with the password (Mistake #1 fixed by KDF).

Taking that format and reading it back means slicing the buffer in order and KDF the key with the password and salt and letting GCM check the tag and return it.

Properties understated: knowing if you accomplished the goal

Functional tests check "does encrypt-then-decrypt return the original?" Security tests check the properties an attacker cares about. These only matter:

Confidentiality: the ciphertext does not contain the plaintext bytes.
Wrong key rejected: using the wrong key should throw an error and never return garbage.
Tamper detection: modifying the ciphertext means decryption will throw an error.
IV uniqueness: the same input should never result in the same ciphertext.

Meeting those four challenges guarantees the three goals outlined are met.

Understanding Limitations

Successful security means you get to state what you don't protect. Even a well-constructed tool has limits and we should talk about them:

Handling passwords. The command line won’t usually protect a password. It will show up in the shell’s command history as a visible answer. Quality tools will prompt you for a password or fetch it from a secured vault.
Handle large files? Memory scales to the size of the file loaded. When a file is too big to fit into memory, you have to design a tool to load a file in segments instead.
File size & existence. Encryption will hide the contents of files, but not the size or existence of files.

These don't justify not making a quality product, though. An honest scope statement that introduces a security tool is likely to engender some amount of trust and goodwill.

Key Takeaways

Most insecure crypto tutorials stop at “It scrambles the bytes.” The boring reality of real crypto correctly applied isn't magic, it's just the consistent application of a handful of phenomena and design principles. These include, but are not limited to, key stretching, salting, IV reuse, authentication, and ensuring the system fails to an unwanted state.

It is worth noting that at no point throughout the design process are you required to think up new and inventive ciphers (which is typically a bad idea anyway). Everything you need is already at hand and battle tested. The only difference between novelty and security is knowing which pieces go where in a system and constructing everything correctly.

The entire SecureVault source code is concise enough that you can read it all at once. Since SecureVault is a fully functioning and cryptographically correct application, reading SecureVault is a great way to learn and internalize the patterns that will help you improve your own code. Building your own version will help you learn immensely. Deliberately implementing one of the known security flaws, and then observing the security test fail will help solidify the lesson you learned.

How to Determine If a Website is Quantum Threat Proof

Aditee Niraula — Sat, 25 Jul 2026 11:09:46 +0000

An easy tutorial to understand basic encryption by analyzing how a quantum computer can break it. Using free tools, this should take less than 20 minutes.

What to Know Before You Begin

In an earlier article, I described how and why quantum computers can break encryption on the internet and the subsequent roll-out of new, post-quantum cryptography, as a defense mechanism. This article is designed to be an active and practical appendage to that article. Here, you will have the opportunity to experience the quantum encryption threat by examining real websites.

You do not have to be a cryptography or security expert to do this. There are no complicated steps and this can be accomplished by anyone with basic computer skills. By the end of this you should be confident your ability to critically analyze a given website and understand where its vulnerabilities to quantum attacks lie, and communicate your findings to the public in a meaningful and simple manner.

What you'll need:

A web browser.
A terminal (Command Prompt or PowerShell on Windows, Terminal on Mac/Linux)
That's all. Everything in this guide is free, and there is no risky software installation.

A 30-second refresher

Secure website connections (the padlock in your browser) use TLS — the protocol behind HTTPS. TLS handles two main parts of secure connections:

For the first part, a server and a browser agree to use a shared secret to encrypt the rest of the session. Generally, this step has many forms of public-key cryptography. RSA and various forms of elliptict-curve cryptography (like ECDH) are most popularly used.
For the second part, a shared secret is used, and the remaining session data is encrypted using a symmetric encryption scheme, like AES.

The important part for our investigation is that the first step of the connection is quantum-vulnerable. When quantum computers are functional, RSA and ECDH will bite the dust, while AES will remain practically unbreakable, and therefore quantum-safe. Because of this, when we look at a website, we are asking “How does this website perform a key exchange, and what will a quantum computer be able to do about it?”

Let's go on!

Method 1 — The easy way (browser, no tools)

Have a look at what you have on hand.

Access any secure webpage, as an example, https://www.wikipedia.org.
Click on the padlock icon located in the address bar.
Look at the section "Connection is secure" → "Certificate details" (the wording is different based on the browser).

In the Public Key field or the Signature Algorithm, you will see something like the following:

RSA 2048 — encryption based on providing large numbers to the key. Quantum vulnerable.
ECDSA / EC (P-256) — vulnerable to the same quantum computing issue as above. Quantum-vulnerable.

What you just learned: the certificate is telling you about the public key algorithm used in the site, and right now it is almost always a quantum vulnerable one used either RSA or EC.

Method 2 — The detailed way (free online scanner)

A browser can give you some info, but a dedicated scanner can show you everything, including the key-exchange method.

Go to SSL Labs' free SSL Server Test (ssllabs.com/ssltest).
Enter a domain (you can use wikipedia.org or even your own page).
Wait for the scan to finish, then go to the "Cipher Suites" section.

Now your entries should look similar to this one:


TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

You can decode this entry, and it contains the following information:

ECDHE → the key exchange is done via Elliptic-Curve Diffie-Hellman. This is the quantum step in the chain of vulnerabilities.
RSA → the server's authentication employs RSA. Also quantum-vulnerable.
AES_256_GCM → the bulk data is encrypted by AES-256. This is considered quantum-safe.
SHA384 → the hashing algorithm. Safe.

You can identify which quantum computer would likely breach this cipher, namely ECDHE and RSA, while which component would remain safe, namely AES-256. This is a useful skill, seeing as most people are unable to even make sense of a cipher suite.

What you just learned: the ability to read a TLS cipher suite and determine which parts are quantum-safe bulk encryption and which parts are quantum-vulnerable key exchange and authentication.

Method 3 - The hands-on way (terminal with OpenSSL)

With this method, you move from “reader” to “inspector.” OpenSSL is a free tool that is pre-installed on most Mac and Linux computers, and is available for Windows.

Find out if you have it: Open your terminal and run openssl version. If it returns a version number, you are all set. If it does not, for Windows the easiest way is to run it in Git Bash that comes with Git for Windows, or install OpenSSL for Windows.

You can now connect directly to a website’s encryption layer and see what it negotiates. Run:

openssl s_client -connect wikipedia.org:443 </dev/null

This will print a wall of text. It may look daunting, but you should only look for a few lines that contain the following.

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit

And somewhere in the negotiation details, look for:

Negotiated TLS1.3 group: X25519

Here’s how to interpret what you see.

Server public key is 2048 bit with an RSA certificate → is quantum authentication and is therefore vulnerable.
Negotiated group: X25519 → is the key-exchange method which is an elliptic-curve algorithm. This is also the prime quantum target.
TLS_AES_256_GCM → is quantum-safe bulk encryption.

You’ve done a security engineer’s job: you connected to a live server and found out what cryptography it’s using. You can now say, “X25519 is what a quantum computer would break first.”

What you learned: how to access a live server and find out what key-exchange group it’s using, which is the most quantum-relevant piece of information.

What "quantum-ready" would really mean

What would you hope to find as a post-quantum-ready server? A server that is post-quantum-ready does a hybrid key exchange — a combination of a traditional key exchange and a post-quantum key exchange. In a server key exchange group, this would look something like:


X25519MLKEM768

The MLKEM is the post-quantum key exchange algorithm that is combined with the standard key exchange X25519. If you see a group like this, you are looking at a server that is starting to defend against quantum computing.

Try this: run Method 3 against a few of the bigger company’s domains (in this case, a Cloudflare-securing domain). See what you find. Some will only support X25519, while others will support the new hybrid MLKEM. That difference is the entire migration, happening in real time, visible to you in one command.

You now have a simple, repeatable way to determine any website's quantum exposure.
1) Browser padlock. Check the certificate's public key algorithm. RSA / EC = vulnerable.
2) SSL Labs scan. Check cipher suites and find the key exchange method.
3) OpenSSL. Check the group set for key exchange.
4) Look for a hybrid 'MLKEM' group. That's a quantum-ready server.
Try it on your website, your employer's website, and your bank's website. You'll discover the same thing that the security teams are facing. Almost everything is quantum vulnerable, and the post-quantum migration has only just started.

Why this matters and how to apply it

The first step in solving a problem is knowing how to identify it. Running this audit and finding only classical algorithms (which you will almost always find) means you can use the following guidance:

It’s not an emergency, but it’s a deadline. Data protected by these algorithms can be obtained and stored for future use when quantum computers become available (this is referred to as "Harvest Now, Decrypt Later").
Monitor your vendors. Ask if the services you depend on have plans to post-quantum migrate. A number of large providers already have plans in place.
Look for hybrid key exchange in the tools, browsers, and servers you use. This will provide evidence that the upgrades are being implemented.

Overall, quantum computing will not be able to break the internet as it is being adjusted. Now you don't just know it's happening, you're able to prove it on every site in under five minutes!

Why Quantum Computers Could Break the Internet's Encryption and What's Replacing It

Aditee Niraula — Sat, 20 Jun 2026 04:43:23 +0000

The short version

Almost everything private you do online like logging into your bank, sending a message, entering a password, paying for something is protected by encryption. That encryption works because certain math problems are too hard for today's computers to solve in any reasonable amount of time.

Quantum computers change that assumption. A large enough quantum computer could solve some of those "too hard" problems quickly and break a big chunk of the encryption the internet relies on.

That machine doesn't exist yet. But the threat is already here, for a reason we'll explain. And the world's security agencies are already rolling out replacement encryption designed to survive quantum attacks. This article explains, what the threat is, why it matters today, and what's being done about it.

How encryption protects you right now

When you see the padlock in your browser, two different kinds of encryption are working together.
Symmetric encryption uses a single shared secret key to lock and unlock data. It's fast and strong. The catch: both sides need the same key so how do they agree on a secret key over the open internet without anyone seeing it?

Public-key encryption (also called asymmetric encryption) solves that. Everyone has two mathematically linked keys:

A public key they share openly, anyone can use it to lock a message to them.
A private key they keep secret, only it can unlock those messages.

The magic is that knowing the public key doesn't let you figure out the private key. This is what lets two strangers establish a secure connection without ever having met. The most common public-key systems are RSA and ECC (elliptic-curve cryptography), and they protect almost every secure website, VPN, and messaging app today.

Here's the key insight: public-key encryption is secure only because of one assumption that deriving the private key from the public key requires solving a math problem so hard it would take today's computers millions of years. For RSA, that problem is factoring a very large number into its prime components. Easy to multiply two big primes together; effectively impossible to reverse.

That single assumption is what quantum computers threaten.

What a quantum computer actually does differently

A normal computer stores information in bits, each either a 0 or a 1. It checks possibilities one effective path at a time.

A quantum computer uses qubit, which exploit two strange properties of quantum physics:

Superposition — a qubit can represent a blend of 0 and 1 at the same time, so a group of qubits can encode an enormous number of combinations simultaneously.
Entanglement — qubits can be linked so they act as a coordinated system rather than independent parts.

The result isn't "a faster regular computer." It's a fundamentally different machine that can attack certain specific problems by exploring many possibilities in a coordinated way, instead of plodding through them one by one.

Crucially, quantum computers are not better at everything. They're dramatically better at a small set of problems and, unluckily for us, the math behind RSA and ECC is on that list.

The two algorithms that change the game

Two known quantum algorithms are the reason cybersecurity experts are paying attention.

Shor's algorithm — the serious threat.
In 1994, mathematician Peter Shor showed that a sufficiently powerful quantum computer could factor large numbers (and solve the related elliptic-curve problem) efficiently. That's precisely the "impossible" problem RSA and ECC depend on. In plain terms: Shor's algorithm would break the public-key encryption protecting the internet today. Not weaken it but actually break it.

Grover's algorithm — the manageable threat.
Grover's algorithm speeds up brute-force searching, which affects symmetric encryption (like AES). But it only provides a "square-root" speedup roughly, it halves the effective strength. The fix is simple: use bigger keys. AES-256 remains considered safe against quantum attacks. So symmetric encryption survives with minor adjustments; it's public-key encryption that needs replacing.

So, the headline is narrower and more precise than "quantum breaks everything": quantum computers primarily break the public-key encryption used to set up secure connections, while symmetric encryption mostly survives by using larger keys.

Why this is a problem today, not in 20 years

The obvious objection: today's quantum computers are small and error-prone. Experts estimate it may be a decade or more before one is powerful enough to run Shor's algorithm against real keys. So why worry now?

The answer is a strategy called “Harvest Now, Decrypt Later."

An attacker doesn't need a quantum computer today to benefit from one tomorrow. They can record encrypted data now intercepted traffic, stolen encrypted databases, captured communications and simply store it. When a capable quantum computer eventually exists, they decrypt everything they saved.

This matters enormously for any data that must stay secret for years: medical records, state secrets, financial data, intellectual property, and the long-lived encryption keys baked into hardware and infrastructure. Data you send today could be decrypted in ten years. For a lot of sensitive information, that's well within its required secrecy lifetime.

That's why governments and major companies are migrating now, before the threat is live. The migration itself takes years, so waiting for the quantum computer to arrive is already too late.

The fix: post-quantum cryptography

The solution is post-quantum cryptography (PQC) new public-key encryption algorithms built on math problems that both regular and quantum computers find hard. PQC runs on the ordinary computers and phones we already use; it doesn't require any quantum hardware. It simply swaps the underlying math for something Shor's algorithm can't unravel.

Most leading PQC schemes are based on problems involving structured lattices. Think of a vast multidimensional grid where finding the shortest path or nearest point is brutally hard to do in reverse, even for a quantum computer.

In 2024, the U.S. National Institute of Standards and Technology (NIST) finalized the first official PQC standards after an eight-year worldwide competition. The headline algorithms:

ML-KEM (originally called Kyber) — for securely establishing shared keys, the job RSA/ECC do today during connection setup.
ML-DSA (originally Dilithium) and SLH-DSA (SPHINCS+) — for digital signatures, which prove authenticity and integrity.

These are now real, published standards. Major platforms have already started deploying them. For example, modern versions of secure messaging and web browsers have begun using hybrid schemes that combine a traditional algorithm with a post-quantum one, so you're protected even if one of them is later found weak.

What this means for you and your organization

You don't need to panic, and you don't need a quantum physics degree. But if you work in or around technology, here's the practical takeaway:

Awareness is the first step. Quantum is no longer science fiction in security circles, it's an active migration project at every serious institution.
Inventory your cryptography. Organizations are being advised to find out where and how they use public-key encryption, because you can't replace what you can't see. This is the unglamorous but essential first move.
Prioritize long-lived secrets. Data that must remain confidential for many years is most exposed to "Harvest Now, Decrypt Later," so it should migrate first.
Favor "crypto-agility." Build systems so the encryption algorithm can be swapped out without rebuilding everything. The lesson of this whole episode is that no algorithm is forever.
Adopt the standards, don't invent your own. The NIST PQC standards exist precisely so individual teams don't roll their own. Use vetted libraries.

The takeaway

Quantum computing isn't going to break the internet overnight, and the sky is not falling. But it represents a rare event in cybersecurity: a predictable future threat, visible years in advance, against which we can prepare deliberately rather than react in a panic.

The story is genuinely optimistic. We understood the threat (Shor's algorithm) decades before the machine to exploit it exists. We ran a global, open competition to design defenses. And we now have published, standardized, deployable replacements. The remaining work is migration — careful, large-scale, and already underway.

The internet's encryption is being quietly rebuilt to survive the quantum age. Now you have the context to understand the shift and keep your third eye vigilant.