What Breaks — RSA, ECC, PKI, TLS

The phrase “public-key cryptography breaks” can sound remote, as if it belongs only in academic papers or standards meetings. It is not remote. Public-key cryptography is the machinery that lets your browser trust a bank, lets a virtual private network build an encrypted tunnel, lets an administrator log in with Secure Shell, and lets an operating system decide that a software update is genuine. The important idea is a tower: vulnerable algorithms at the bottom, certificate trust in the middle, and everyday protocols at the top. If a large enough quantum computer runs Shor’s algorithm against the bottom layer, the damage rises through the whole structure.

The tower: algorithms, trust, protocols

Most modern security systems are built in layers. At the lowest layer are public-key algorithms: mathematical methods for exchanging keys, encrypting small pieces of data, or proving that a message was signed by a particular private key. Above them is public-key infrastructure, or PKI, the trust system that binds public keys to names such as websites, people, devices, and software publishers. Above that are the protocols people actually touch: Transport Layer Security, or TLS, for the browser padlock; virtual private networks, or VPNs; Secure Shell, or SSH; code signing; and secure email.

A quantum break does not have to attack each application separately. If the shared foundation fails, the applications inherit the failure. That is why the subject is bigger than replacing a few old keys. It is a migration of trust, identity, and connection setup across many systems.

Layer 1: the algorithms that fall

Three families cover most of the public-key exposure. RSA, named for Rivest, Shamir, and Adleman, is the classic public-key algorithm whose security rests on the difficulty of factoring large numbers. Diffie-Hellman, often shortened to DH, lets two parties agree on a shared secret over an open network. Elliptic-curve cryptography, or ECC, performs similar jobs with smaller keys; common forms include Elliptic Curve Digital Signature Algorithm, or ECDSA, for signatures, and Elliptic Curve Diffie-Hellman, or ECDH, for key agreement.

Shor’s algorithm breaks the hard mathematical problems behind all three: factoring for RSA and discrete logarithms for DH and ECC. This is not a small weakening that can be patched by modestly increasing key sizes. For the affected public-key schemes, a sufficiently capable quantum computer can recover the private key from the public information. In practice, that means the attacker can decrypt what depended on that key agreement or produce signatures that verify as if they came from the legitimate private key.

ECC deserves special attention because its efficiency made it the modern default in many places. Smaller keys reduced bandwidth and processing cost, so ECC appears in TLS handshakes, mobile systems, SSH keys, certificates, messaging protocols, and blockchains. That efficiency does not protect it from Shor’s algorithm; elliptic-curve systems are also in scope.

• RSA is used for signatures and, in older designs, encryption or key transport.
• ECDSA is used for digital signatures, including certificates, SSH keys, code signing, and many blockchain wallets.
• ECDH is used for key agreement in TLS, VPNs, messaging systems, and other secure channels.
• Classical Diffie-Hellman is used for key agreement in older or legacy configurations.

Layer 2: why PKI becomes fragile

Public-key infrastructure answers a simple question with high stakes: when your device sees a public key, how does it know whose key it is? A certificate is a signed statement that links an identity to a public key. For example, a website certificate says, in effect, this public key belongs to this domain name. A certificate authority, or CA, signs that statement. Your operating system and browser come with a store of trusted root CAs, and trust flows from those roots through intermediate certificates down to the certificate used by a website or service.

The problem is that the signatures in this chain usually use RSA or ECDSA. If an attacker can derive the private signing key of a trusted CA or intermediate CA, the attacker can create certificates that appear valid to clients. The browser is not “fooled” by a visual trick; it is following the rules it was given. The cryptographic proof has been forged because the signing algorithm underneath it no longer provides security.

This is an authenticity problem, not just a secrecy problem. It affects the ability to prove that a server, device, document, software package, or update is really from the claimed source. Long-lived trust anchors, such as root certificates and firmware signing keys, are especially important because they may remain trusted for many years. They must be moved before a practical quantum attack exists, not after.

Layer 3: what happens to TLS, VPNs, SSH, code signing, and email

Transport Layer Security, or TLS, is the protocol behind HTTPS, the secure version of web traffic. TLS usually does two public-key jobs at the start of a connection: it authenticates the server with a certificate, and it uses a key exchange to create fresh symmetric keys for the session. The actual data is then protected with symmetric encryption such as the Advanced Encryption Standard, or AES. Shor’s algorithm does not directly break AES, but it can break the public-key setup that created or authenticated the session.

For recorded TLS sessions that used RSA key transport or classical DH or ECDH key exchange, a future quantum attacker may be able to recover the session secrets from captured traffic and decrypt the contents. For live sessions after Q-day, the day a cryptographically relevant quantum computer becomes available to an attacker, the danger also includes impersonation: forged certificates can make a malicious endpoint look legitimate.

VPNs face the same pattern. Internet Protocol Security with Internet Key Exchange, often written IPsec/IKE, and many other VPN designs depend on DH or ECDH-style key agreement. WireGuard uses Curve25519, an elliptic-curve key exchange. SSH uses host keys to identify servers and key exchange to protect sessions. Secure email systems such as S/MIME and OpenPGP can expose both encrypted messages and digital signatures. Code signing and firmware signing are even more direct: if the signing key is compromised by quantum attack, malicious code can be made to look authentic.

• HTTPS/TLS: recorded sessions may become readable, and forged certificates can enable live impersonation.
• VPNs: captured tunnel traffic may become decryptable if the key exchange is vulnerable.
• SSH: host identity and session secrecy both depend on public-key mechanisms.
• Code signing: fake updates can verify as genuine if signing keys are broken.
• Secure email: old encrypted mail may be read, and signatures may be forged.
• Blockchain wallets: funds tied to exposed ECDSA public keys can be at risk once the corresponding private keys can be derived.

Two different failures: confidentiality and authenticity

The same quantum capability causes two kinds of harm, but they arrive on different clocks. Confidentiality failure is about reading secrets. An attacker can record encrypted traffic today and store it until a quantum computer can recover the keys later. This is the harvest-now, decrypt-later risk. Its deadline is not Q-day alone; it is Q-day minus the lifetime of the data. If the information must stay secret for ten years, it needs protection before those ten years begin.

Authenticity failure is about believing lies. After Q-day, an attacker may be able to forge signatures, impersonate services, issue convincing certificates, or make malicious software appear signed by a trusted publisher. This is mostly a live risk: the forged proof is used in the moment. But the planning deadline still comes earlier for long-lived keys, root certificates, hardware roots of trust, and firmware ecosystems because they are slow to replace and widely embedded.

The practical split is this: confidentiality migration is driven by how long data must remain secret, while authenticity migration is driven by how long trust anchors and signing keys will remain in use. Both matter, but they should not be measured with the same calendar.

What still stands, and what must change

Not every cryptographic tool collapses. The main break is in today’s widely deployed public-key algorithms. Symmetric encryption, such as AES, is affected differently. Grover’s algorithm can reduce the effective strength of symmetric keys, but larger symmetric key sizes compensate in a straightforward way. AES-256 is generally treated as a strong quantum-resistant choice for bulk encryption. Hash functions, such as the Secure Hash Algorithm family, also remain usable when output sizes are chosen conservatively, for example SHA-384 or SHA-512 in many designs.

The replacements for vulnerable public-key functions are post-quantum cryptography, or PQC: algorithms designed to run on ordinary computers while resisting known quantum attacks. The United States National Institute of Standards and Technology, or NIST, standardized Module-Lattice-Based Key-Encapsulation Mechanism, or ML-KEM, for key establishment, and Module-Lattice-Based Digital Signature Algorithm, or ML-DSA, for general digital signatures. Stateless Hash-Based Digital Signature Algorithm, or SLH-DSA, provides a more conservative hash-based signature option for cases where its larger signatures and performance trade-offs are acceptable.

In real deployments, the near-term pattern is often hybrid operation: combine a classical method with a post-quantum method during the transition. Hybrid key exchange, for example, can protect against a future quantum attacker while preserving compatibility and confidence during rollout. It is not the final destination, but it is a practical bridge.

The decisions leaders and practitioners face

The first decision is inventory. You cannot migrate cryptography you cannot find. Teams need to discover where RSA, ECDSA, ECDH, and DH are used across certificates, TLS endpoints, VPNs, SSH, identity systems, software signing, firmware signing, email, embedded devices, cloud services, and third-party dependencies. This inventory should include key sizes, certificate lifetimes, protocols, libraries, hardware security modules, and owners.

The second decision is prioritization. Long-lived confidential data should move early to quantum-safe key establishment, because recording can happen now. Long-lived signing keys and trust anchors should also move early, because they are hard to rotate quickly and their compromise would damage many systems at once. Public websites may be easier to update than factory devices, medical equipment, satellites, payment terminals, or firmware validation chains that stay in service for a decade.

The third decision is agility. A one-time algorithm swap is not enough. Systems need crypto-agility: the ability to change algorithms, certificate profiles, libraries, key sizes, and policies without redesigning the whole application. The organizations that handle this well will treat the migration as engineering hygiene and risk management, not as a last-minute emergency.

The point to carry forward

The quantum threat is not merely that one algorithm becomes unfashionable. It is that RSA, DH, and ECC sit under the trust model used by the modern internet and enterprise security. Certificates, authorities, handshakes, device identities, software updates, remote access, and secure email all rely on those public-key foundations in different ways.

The clearest mental model is the tower. Break the algorithms, and PKI loses its proof. Break PKI and key exchange, and protocols lose secrecy and identity. Then separate the consequences into two bins: confidentiality, where captured data may be decrypted later, and authenticity, where forged signatures and certificates can deceive systems in real time. That split is what turns a vague quantum concern into a concrete migration plan.

Glossary

RSA

RSA is a public-key algorithm named for Rivest, Shamir, and Adleman whose security depends on the difficulty of factoring large numbers.

Elliptic-curve cryptography

Elliptic-curve cryptography is a family of public-key methods that uses elliptic-curve mathematics to provide signatures and key agreement with smaller keys than RSA.

Shor’s algorithm

Shor’s algorithm is a quantum algorithm that can efficiently solve the factoring and discrete logarithm problems behind RSA, Diffie-Hellman, and elliptic-curve cryptography.

Public-key infrastructure

Public-key infrastructure is the system of certificates, certificate authorities, policies, and trust stores that binds public keys to identities.

Certificate authority

A certificate authority is a trusted organization or service that signs certificates to vouch that a public key belongs to a particular identity.

Transport Layer Security

Transport Layer Security is the protocol that protects HTTPS connections by authenticating endpoints and establishing symmetric session keys.

Virtual private network

A virtual private network is an encrypted tunnel that carries traffic securely across an untrusted network.

ML-KEM

ML-KEM is the NIST-standardized post-quantum key-establishment mechanism used to create shared secrets securely against known quantum attacks.

ML-DSA

ML-DSA is the NIST-standardized post-quantum digital signature algorithm intended for general-purpose signing.