RSA or Ed25519: Which SSH Key Should You Choose?

Advice to replace ssh-keygen -t rsa with ssh-keygen -t ed25519 is often reduced to one sentence: Ed25519 is newer, shorter, and faster. That explanation misses the important parts. Key lengths from different cryptosystems cannot be compared directly, RSA did not become unsafe on a single date, and some reports that “RSA was disabled” actually refer only to old RSA signatures using SHA-1. Choosing an SSH key depends on mathematics, but also on server versions, hardware tokens, and the rules of the infrastructure where the key will be used.

RSA made public-key cryptography practical

Whitfield Diffie and Martin Hellman published the idea of public-key cryptography in 1976, but their work did not provide a general ready-to-use system for both encryption and signatures. The following year, MIT researchers Ron Rivest, Adi Shamir, and Leonard Adleman proposed the method named from their initials. Their paper, “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems”, appeared in Communications of the ACM in February 1978.

RSA starts with two large primes, p and q, whose product becomes the modulus n. Multiplying chosen primes is easy, while recovering them from a sufficiently large n is believed to be computationally difficult. That asymmetry allows one part of the key to be published while the other remains secret.

Textbook explanations often reduce RSA to modular exponentiation, but that operation alone does not form a secure modern system. Encryption needs an encoding scheme such as OAEP, while signatures combine hashing with a defined signature construction such as PSS or PKCS #1 v1.5. In SSH, an RSA key normally does not encrypt the whole connection. The client signs session data to prove possession of the private key, while separately negotiated symmetric keys protect the actual traffic.

RSA has survived for more reasons than age and familiarity. Its formats are supported by older SSH servers, network appliances, smart cards, HSMs, and enterprise policies whose approved algorithm lists change slowly. RSA with a suitable modulus and modern signature algorithm remains usable, although its keys and signatures are much larger and its generation and private-key operations are more expensive than those of modern elliptic-curve schemes.

From Curve25519 to Ed25519 without confusing their jobs

In 2006, Daniel J. Bernstein introduced Curve25519 as a fast and implementation-friendly primitive for Diffie-Hellman shared-secret agreement. The corresponding function is now commonly called X25519. It helps two peers derive a shared secret, but does not itself create digital signatures or replace an authentication algorithm.

Five years later, Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang published “High-speed high-security signatures”, describing Ed25519 as a concrete form of EdDSA. Ed25519 uses the twisted Edwards curve edwards25519 over the field defined by the prime 2²⁵⁵ − 19. That curve is equivalent to Curve25519 under a change of coordinates, so their discrete-logarithm problems are related, but the protocols and key encodings remain distinct.

The distinction matters in practice. X25519 establishes a secret that can later protect data, while Ed25519 signs a message and lets someone verify the signature with a public key. An ssh-ed25519 line cannot simply be used as an X25519 key without a defined conversion and protocol, just as a signature does not replace key agreement because both names contain 25519.

What Ed25519 improved for signatures

Published in January 2017, RFC 8032 describes EdDSA, the Ed25519 parameters, and test vectors. An Ed25519 public key encodes to 32 bytes, a signature occupies 64 bytes, and the scheme targets about 128 bits of classical security. In the comparable-strength table in NIST SP 800-57 Part 1 Rev. 5, RSA needs a 3072-bit modulus for the same approximate 128-bit level, while RSA-2048 is assessed at roughly 112 bits. Calling Ed25519 “equivalent to RSA-4096” is therefore at most a rough shorthand, not a precise equality.

Ed25519 also avoids requiring a fresh random nonce for every signature because that value is derived deterministically from the private key and message. This removes a class of failures in which poor signing-time randomness exposed private keys in other schemes. Complete point-addition formulas also make it easier to write code without exceptional branches for special points.

The algorithm does not make every implementation automatically resistant to side channels. RFC 8032 still instructs implementers to avoid branches and memory accesses that depend on secret values. Ed25519's design makes constant-time code easier, but a concrete library must do that work correctly. Performance comparisons need similar care: Ed25519 key generation and signing are generally fast and predictable, while RSA verification with a small public exponent can also be extremely fast. No algorithm wins every operation on every platform.

What actually changed in OpenSSH

OpenSSH 6.5, released on January 30, 2014, added Ed25519 as a user and host key type. The current ssh-keygen manual identifies Ed25519 as the default. It is a practical choice for a new key when both ends run modern implementations, but old servers and closed network devices still require a compatibility check.

RSA followed a different transition. OpenSSH 7.2 added RSA signatures using SHA-256 and SHA-512 in 2016, then OpenSSH 8.8 disabled the SHA-1-based ssh-rsa signature algorithm by default in 2021. Its release notes explicitly say that most users do not need to replace existing RSA keys: the same key automatically uses rsa-sha2-256 or rsa-sha2-512 when the other side supports them.

The practical rule is consequently straightforward. Start with Ed25519 for new access between modern systems. Use RSA when the target server, token, or policy lacks Ed25519 support, choose a sufficient modulus, and confirm that the connection negotiates RSA/SHA-2 instead of restoring RSA/SHA-1 merely to accommodate obsolete software.

The sizes in the table describe the raw public value or modulus. An OpenSSH line, private-key container, and surrounding format data always occupy more space. Neither RSA nor Ed25519 is post-quantum: a sufficiently capable quantum computer threatens both mathematical problems, so moving between these two algorithms does not solve post-quantum migration.

What the browser Key Pair Generator does

Key Pair Generator calls the Web Crypto API directly in the open page and offers Ed25519, RSA-2048, or RSA-4096. For RSA, the implementation creates an RSA-PSS key with SHA-256 and public exponent 65537. It then assembles an ssh-ed25519 or ssh-rsa public line, calculates the familiar SHA256 fingerprint over the SSH blob, and lets the user copy or download the result.

The private part is exported as unencrypted PKCS#8 PEM. This is not the private-key container normally written by ssh-keygen, so the private file's compatibility must be checked in the target program; the OpenSSH public line and the PKCS#8 private container serve different consumers. Keys exist only in page memory, and the current implementation neither transmits them to a server nor writes them to storage. Generating again replaces the previous pair.

Those properties make the tool useful for learning the formats, comparing sizes, and creating temporary keys in a compatible environment, but they do not remove the need for caution. The unencrypted private key is displayed on screen and downloaded without a passphrase, while online generation also depends on the integrity of the page code, browser, and device. For persistent access to production servers, prefer running ssh-keygen -t ed25519 locally, protect the file with a passphrase, or use a hardware-backed key. If RSA compatibility is required, choose its parameters from the target system's requirements rather than from the apparent length of a generated string.

Related tools

Key Pair GeneratorGenerate Ed25519 or RSA (2048/4096) key pairs with the Web Crypto API — OpenSSH public key, PEM private key, SHA256 fingerprint, and downloadable files, all client-side.Shamir's Secret SharingSplit a secret into N shares with a K-of-N threshold and recover it from any K. Shares export as text or QR codes and a ZIP archive, all client-side over GF(256).JWT InspectorDecode a JWT into readable header and payload, inspect expiry and issued-at times, and verify HS256, RS256 or ES256 signatures locally.Encryption ToolboxIdentify an unknown cipher from its charset, index of coincidence, frequencies and Kasiski repeats; encode one message with every reversible cipher at once with round-trip checks; encrypt with AES-256-GCM; and solve Caesar, Vigenère, Playfair, ADFGX, Bifid or rail fence in the workbench — all in the browser.