RSA is dead: Why you should migrate to elliptic curve cryptography today

I still see RSA keys everywhere. On servers I get handed to audit, in CI pipelines, in authorized_keys files that have not been touched since 2018. People generate RSA-4096 keys and feel good about it. "Four thousand and ninety six bits," they tell themselves, "that should be enough."

It is not enough. Or rather, it is enough security-wise for now, but it is the wrong algorithm entirely. Elliptic curve cryptography does everything RSA does, with smaller keys, faster operations, and better security per bit. There is no good reason to generate an RSA key in 2026.

The numbers

The comparison between RSA and ECC key sizes comes from NIST SP 800-57, and the disparity is almost comical:

To match 256-bit ECC security with RSA, you would need a 15360-bit key. Nobody uses 15360-bit RSA keys. The commonly deployed RSA-4096 sits at roughly 140 bits of security strength — decent, but you are paying dearly for it in CPU cycles and key size when a 256-bit ECC key surpasses it.

RSA-1024 is deprecated by every standards body and provides only 80-bit security. Nobody has publicly factored a 1024-bit RSA modulus — the record is 829 bits — but it falls well below the 112-bit minimum that NIST has required since 2015. If you still have RSA-1024 keys in your infrastructure, that is your first priority.

Why RSA is slow and ECC is not

RSA relies on modular exponentiation with very large integers. The bigger the key, the more expensive every operation gets. ECC works on elliptic curves over finite fields, achieving equivalent security with dramatically smaller numbers.

Here are approximate benchmarks on modern hardware with OpenSSL:

ED25519 keygen is over a thousand times faster than RSA-4096. Signing is two orders of magnitude faster. When you are running CI/CD pipelines that open dozens of SSH sessions, or automated deployments that touch hundreds of nodes, this difference stops being theoretical.

I noticed it firsthand when migrating a fleet of build runners from RSA to ED25519. SSH connection setup time dropped measurably. Not life-changing on a single connection, but across thousands of git clones and deploys per day, it added up.

What about quantum

Both RSA and ECC fall to Shor's algorithm on a sufficiently powerful quantum computer. Neither is quantum-resistant. This is worth stating clearly because it is the obvious rebuttal: "Why migrate to ECC if quantum will break it too?"

Two reasons. First, no quantum computer today can factor anything close to a production key. The largest quantum-assisted factorization is around 90 bits — astronomically far from the 2048-bit keys in real use. Current estimates put the hardware requirements for breaking RSA-2048 at under one million noisy qubits running continuously for days. Hardware roadmaps do not target that capability before the early 2030s.

Second, the migration path has two stages, not one. Right now, you move from RSA to ECC for immediate, tangible benefits: smaller keys, faster operations, better security per bit. Later, as post-quantum standards mature, you migrate again to ML-KEM and ML-DSA — NIST published its first three PQC standards in 2024. Moving to ECC today is not wasted effort. It is the correct intermediate step, and it gets your infrastructure out of the habit of treating RSA as the default.

Migrate your SSH keys

Generating an ED25519 key is one command:

ssh-keygen -t ed25519 -C "your_email@example.com"

The resulting public key is a single short line, easy to copy and manage. The private key is smaller. Operations are faster. ED25519 was designed with constant-time arithmetic, which reduces the timing side-channel risks that have plagued RSA implementations for years.

Deploy the new public key to your servers, Git hosting, and any other service that accepts SSH authentication. Then remove the old RSA keys. Do not leave them as fallback — that defeats the purpose.

Enforce it organization-wide

Generating your own ED25519 key is the easy part. The hard part is making sure nobody else on your team is still generating RSA keys. If you do not enforce it, developers will keep doing what they have always done.

GitLab

GitLab lets administrators restrict which key algorithms are accepted. Under Admin Area > Settings > General > Visibility and access controls, you can disable RSA entirely or set the minimum RSA key size to something impractically large. Enable ED25519 and optionally disable DSA and ECDSA as well.

Once the restriction is active, existing RSA keys are disabled — users can not push or pull with them, but the keys are not deleted. Anyone trying to authenticate with an RSA key gets rejected. This is the forcing function you need.

sshd_config

On your servers, restrict the accepted algorithms directly. OpenSSH 8.5+ renamed the directive from PubkeyAcceptedKeyTypes to PubkeyAcceptedAlgorithms — the old name still works as an alias:

PubkeyAcceptedAlgorithms ssh-ed25519,sk-ssh-ed25519@openssh.com

sudo systemctl restart sshd

This rejects RSA, DSA, and ECDSA at the server level. Any key that is not ED25519 or a hardware-backed FIDO2 key (sk-ssh-ed25519) will not authenticate. Test this in staging first — you do not want to lock yourself out because you forgot to deploy your new key somewhere.

ECC in TLS

The same shift applies to TLS, though it is further along. Most modern TLS deployments already use ECDHE for key exchange, even if the certificate itself is RSA-signed.

TLS 1.3 separates cipher suite selection from key exchange entirely. The cipher suites — TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 — define symmetric encryption and hashing. Key exchange is negotiated via the supported_groups extension, and in practice ECDHE with X25519 or P-256 dominates. This gives you perfect forward secrecy: even if the server's private key is compromised later, past sessions remain protected.

If you are issuing new TLS certificates, consider ECDSA (P-256 or P-384) instead of RSA. The certificates are smaller, the handshake is faster, and every modern client supports them. The only reason to keep RSA certificates is compatibility with pre-2015 clients, and if you are still supporting those, you have bigger problems than key algorithm choice.

RSA works, but it is the wrong choice in 2026. ED25519 is faster by orders of magnitude, the keys are short enough to read at a glance, and every tool you care about supports it.

Post-quantum is a separate problem. NIST published its first PQC standards in 2024, but the tooling is not ready for production yet. When it is, you migrate again. For now, stop generating RSA keys.