RelicRELIC
Developer cheat sheets

Ed25519 vs RSA

For a new SSH key or signing key, Ed25519 is the better default: smaller keys, faster operations, and a design that sidesteps whole classes of RSA mistakes. RSA is still worth keeping for one reason, which is that some old or regulated systems will not accept anything else. This is the comparison, without the hand-waving.

Jordan Gibbs July 10, 2026 8 min read

Both Ed25519 and RSA are public-key algorithms: you hold a private key, you hand out a public key, and the math links them so a signature made with the private key verifies against the public one. That is what lets an SSH server trust you without ever seeing your secret. The two differ in the kind of math underneath, and that difference shows up in key size, speed, and how easy each is to use safely.

The recommendation

Generate Ed25519 unless a specific system forces RSA on you. It is smaller, faster, and harder to misconfigure. Reach for RSA only when you hit a device, appliance, or compliance regime that predates Ed25519 support or will not accept it. If you do use RSA, use at least 3072 bits, and prefer 4096 for long-lived keys.

Side by side

PropertyEd25519RSA
Key sizeFixed 256-bit2048, 3072 or 4096-bit
Public key length (SSH)About 68 charactersAbout 400 to 750 characters
Security levelAbout 128-bit2048-bit is about 112-bit; 3072-bit about 128-bit
Signing / verifying speedFast, constant timeSlower, key-size dependent
Key generation speedNear instantSlow at 4096-bit
SignaturesDeterministic (no RNG at sign time)Needs correct padding and randomness
OpenSSH supportSince 6.5 (2014)Universal, including legacy systems
FIPS / older HSM contextsSometimes unsupportedWidely accepted

Key size and why it matters

RSA gets its strength from the difficulty of factoring a large number, so security scales with key length, and the keys get big. An RSA-3072 key is thousands of bits. Ed25519 is built on an elliptic curve (Curve25519), where the hard problem is steeper, so a fixed 256-bit key reaches roughly the same security as RSA-3072. That is the headline trade: a 256-bit Ed25519 key delivers what takes RSA about 3072 bits.

The practical upshot is a public key you can actually eyeball. An Ed25519 public key is around 68 characters, so the whole thing fits on one line of an authorized_keys file. An RSA-4096 public key runs several hundred characters. Both work fine; the smaller one is just easier to handle and paste.

Security margin, in plain numbers

Security levels are approximate, stated plainly. RSA-2048 sits around the 112-bit security level, which is still considered safe today but sits right at the floor rather than a comfortable margin. RSA-3072 lands near 128-bit. Ed25519 is designed for roughly the 128-bit level. So Ed25519 and RSA-3072 are in the same class, and RSA-2048 is a step below both. This is why 2048 is being phased out of higher-assurance guidance in favour of 3072 and up.

Deterministic signatures

This is Ed25519’s quiet advantage. Ed25519 signatures are deterministic: the signature is derived from the message and the private key alone, with no random number generated at signing time. That matters because a bad random number generator has historically broken signature schemes that depend on fresh randomness per signature. Ed25519 removes that failure mode entirely.

RSA works fine, but it has more sharp edges. RSA signing and encryption depend on choosing the right padding scheme, and older padding modes have well-documented weaknesses. None of this is a problem when you use a modern library correctly, but “used correctly” is doing real work in that sentence. Ed25519 gives you fewer knobs to set wrong. If the split between hiding data and proving identity is fuzzy, our explainer on hashing vs encryption draws the line, and what a hash function is covers the digest step that every signature is built on.

Compatibility: the one reason to keep RSA

OpenSSH has supported Ed25519 since version 6.5, released in early 2014, so any current Linux, macOS, or Windows OpenSSH client and server handles it. The gaps are at the edges: some older network appliances, certain hardware security modules, some Git hosting on dated software, and a few FIPS-constrained environments still expect RSA. If you administer a fleet that includes anything old or regulated, keeping an RSA key on hand costs nothing and saves a bad afternoon.

A useful rule: default to Ed25519 for your personal and server keys, and only generate RSA for the specific host that rejects it. There is no benefit to using RSA everywhere just because one box needs it.

Generating each key

The commands are nearly identical. For Ed25519, key size is fixed, so there is no length to specify.

Generate an Ed25519 key
ssh-keygen -t ed25519 -C "you@example.com"

For RSA, set the length explicitly. Do not accept a default that might be 2048; ask for 4096 for a long-lived key.

Generate an RSA key
ssh-keygen -t rsa -b 4096 -C "you@example.com"

Both write a private key and a matching public key (the .pub file) into your ~/.ssh directory. You add the public key to the server; the private key never leaves your machine. Protect the private key with a passphrase at the prompt, and if you need a strong one, our password generator produces one that runs entirely in your browser.

The bottom line

Ed25519 wins on size, speed, and safety-by-default, and it is supported everywhere current. RSA earns its place only as the fallback for systems that will not take anything else, and when you use it, 3072 bits is the floor and 4096 the safer choice. Pick Ed25519 first, keep an RSA key for the stubborn hosts, and move on. For more references like this, the regex cheat sheet and the rest of our developer cheat sheets cover the other syntax you look up between the times you need it.

Written by
Jordan GibbsFounder, Relic

Jordan Gibbs is the founder of Relic, an end-to-end encrypted, permanent, searchable memory for everything you copy. He writes widely about AI, agents, and practical tooling on Medium, where he is read by tens of thousands, and builds privacy-first software. Here he covers how everyday tools like the clipboard actually work, and how to use them without handing your data to someone else.

MediumGitHubLinkedIn
Part of
Developer cheat sheets
Keep reading
Pillar·9 min

Regex cheat sheet

The regex pieces you actually reach for, character classes through lookarounds, with the flavor differences that bite you and a handful of patterns worth saving.

Read
8 min

JSONPath examples

JSONPath is XPath for JSON. One small store document, threaded through wildcards, slices, filters and recursive descent, with the honest note on how implementations vary.

Read
8 min

jq cheat sheet

jq is sed for JSON. The filters you use most, built up against one API response so every command has a visible result, from map and select to group_by and raw output.

Read
developersecurityencryption