When you run ssh-keygen without arguments, OpenSSH still defaults to RSA on most distributions. That's a historical artifact, not a recommendation. RSA, ECDSA, and Ed25519 each rest on different math, and they have aged differently. In 2026, the choice is mostly settled — but understanding why matters when you're rotating keys, supporting legacy systems, or evaluating a security policy.
RSA: The Default You Inherited
RSA, published in 1977, was the first widely deployed public-key algorithm. Its security rests on the difficulty of factoring the product of two large prime numbers. Pick two primes p and q, multiply them to get n, and the factoring problem says nobody can recover p and q from n in reasonable time — provided n is large enough.
"Large enough" has been a moving target for fifty years. In the 1990s, 512-bit RSA was thought sufficient. It was publicly factored in 1999. 768 bits fell in 2009. NIST's current minimum for new RSA keys is 2048 bits, and a growing chorus of cryptographers recommends 3072 or 4096 bits for keys expected to live more than five years.
The problem is that RSA security scales sub-exponentially with key size. Doubling key length doesn't double effective security — it adds maybe 16 bits. To match the strength of a 256-bit elliptic curve key, you need roughly 15,360-bit RSA. Nobody uses 15,360-bit RSA, which is why most deployments accept 2048 or 3072 bits and the resulting ~112-128 bit security margin.
If you need RSA for compatibility, use 4096 bits. 2048 still meets current minimums but provides no margin against improvements in factoring algorithms over the lifetime of the key.
ECDSA: Elliptic Curves, With Caveats
ECDSA replaces integer factoring with the elliptic curve discrete logarithm problem. The math is harder to attack per bit, which is why 256-bit ECDSA gives roughly the same security as 3072-bit RSA, with far smaller keys and signatures.
OpenSSH supports three NIST curves for ECDSA: P-256, P-384, and P-521. They work. They're standardized. They're broadly compatible.
They also have two problems worth knowing about.
First, the curve parameters. The NIST P-curves were generated with seed values nobody has fully explained, and post-Snowden, there's persistent skepticism about whether they're free of backdoors. There's no public evidence of weakness, but the lack of nothing-up-my-sleeve construction has soured a generation of cryptographers on them.
Second, the signature scheme is brittle. ECDSA signatures require a per-signature nonce that must never be reused and must be drawn from a cryptographically strong RNG. If you sign two different messages with the same nonce, an attacker can recover your private key from the two signatures — the math is straightforward. This is how Sony's PlayStation 3 code-signing key was extracted in 2010, and how an early Bitcoin wallet implementation leaked thousands of private keys.
Implementations have largely moved to deterministic nonces (RFC 6979) to eliminate the RNG dependency, but the underlying scheme remains unforgiving.
Ed25519: The Modern Default
Ed25519, designed by Daniel J. Bernstein and collaborators in 2011 and standardized in RFC 8032, is the algorithm most security-conscious deployments now prefer. It uses a specific elliptic curve (Curve25519) selected for transparent, mathematically justified design choices rather than NIST committee output.
The key advantages over ECDSA:
- Deterministic signatures by default — the nonce is derived from the private key and message hash, so there's no RNG dependency at signing time
- Constant-time implementations are straightforward — sidechannel attacks via timing are much harder to introduce by accident
- Smaller artifacts — 32-byte public keys, 64-byte signatures, regardless of message size
- Faster signing and verification than equivalent-strength ECDSA on most hardware
Ed25519 has been the OpenSSH-recommended default since version 7.0 (2015). Every modern SSH server supports it. The only meaningful reasons to use anything else are interoperability with legacy systems (some FIPS-bound corporate environments still mandate RSA or NIST ECDSA) or organizational policy lag.
Side-by-Side
| Property | RSA 4096 | ECDSA P-256 | Ed25519 |
|---|---|---|---|
| Effective security | ~140 bits | ~128 bits | ~128 bits |
| Public key size | ~800 bytes | ~91 bytes | ~68 bytes |
| Signature size | ~512 bytes | ~72 bytes | 64 bytes |
| Key generation | Slow (seconds) | Fast (ms) | Fast (ms) |
| Nonce required at signing? | No | Yes (critical) | No (deterministic) |
| Curve transparency | n/a | Disputed | Documented |
| Quantum resistance | Broken by Shor | Broken by Shor | Broken by Shor |
What About Quantum Computers?
None of the three is quantum-resistant. A sufficiently large fault-tolerant quantum computer running Shor's algorithm would break all of them. As of 2026, no such machine exists, and credible estimates for when one might exist range from "never" to "fifteen years." NIST is in the process of standardizing post-quantum signature schemes (ML-DSA, formerly Dilithium, was standardized as FIPS 204 in 2024), but adoption in SSH is early and the artifacts are much larger.
For SSH specifically, the threat model is favorable: SSH sessions are short-lived, and a captured-now-decrypt-later attack against an Ed25519 host key only matters if you reuse that key for years and the attacker is recording your handshakes. For most operators, classical algorithms remain fine for the next several years.
Practical Recommendations
For new keys in 2026, generate Ed25519:
ssh-keygen -t ed25519 -a 100 -C "your@email"
The -a 100 flag increases the KDF rounds used to encrypt your private key on disk, making offline brute-force of the passphrase more expensive. (It's only relevant if your key is encrypted with a passphrase — which it should be.)
Use RSA 4096 only when you must talk to a system that doesn't support Ed25519. That set is small in 2026: very old SSH servers, some embedded devices, and certain hardware tokens. If you're in a FIPS-mandated environment, RSA 3072 or ECDSA P-384 are the typical compromises.
Avoid ECDSA on the NIST curves unless you specifically need it. There's no upside over Ed25519 for SSH, and the historical brittleness of the signature scheme means your operational risk is higher.
One last thing: rotate your keys. The argument that "my key is strong, so I never need to rotate" misses that the more interesting risk is the private key file leaking from a backup, a stolen laptop, or a developer who left the company. Rotation limits the blast radius. Two years is a reasonable upper bound for personal keys; CI/CD and shared service accounts should rotate faster.
The Underlying Pattern
Cryptography defaults inherit slowly. RSA's continued prevalence isn't because it's better — it's because tutorials, automation, and policy documents written in 2010 still get copied forward. Ed25519 is what informed implementers reach for now. If you're standing up new infrastructure, that's the choice that ages best. For deeper context on key derivation and the broader cryptographic stack, see our piece on HKDF and the comparison of password hashing functions.