Why Ed25519 Is Replacing RSA — SSH Key Algorithms Compared, Plus the Shell Escape Trap
The first thing ssh-keygen asks when you're registering a new SSH key on a server is which algorithm to use. It used to be an easy, thoughtless pick of RSA 2048-bit, but these days GitHub and most other services recommend Ed25519 by default. If you just look at key length, RSA 2048-bit looks much bigger — so why is the shorter Ed25519 considered "more secure"? And why does putting special characters in a comment cause problems when building the command? Let's walk through both, grounded in how the SSH Key Generator actually behaves.
1. Two algorithms built on completely different math problems
RSA's security comes from the difficulty of factoring large integers. The bigger the key (2048-bit, 4096-bit), the more computation factoring requires — and that growth is exponential, which is how RSA maintains its security margin. Ed25519, by contrast, is a digital signature algorithm (a concrete implementation of EdDSA) based on the elliptic curve discrete logarithm problem. For the same number of bits, elliptic curve cryptography rests on a problem that's far harder to solve than integer factorization, which lets it reach an equal or higher security level with a much shorter key. The intuition that "shorter key = weaker" is a misunderstanding that comes from comparing two different math problems on the same yardstick.
2. Why 256 bits beats 2048 bits
In cryptography, "security level" is expressed as the number of operations an attacker needs to break the key, given as a power of two. Roughly, based on NIST guidance, the correspondence looks like this:
| Algorithm / key length | Estimated security level | Underlying problem |
|---|---|---|
| RSA 2048-bit | ~112 bits | Integer factorization |
| RSA 3072-bit | ~128 bits | Integer factorization |
| RSA 4096-bit | ~140-150 bits | Integer factorization |
| Ed25519 (256-bit) | ~128 bits | Elliptic curve discrete logarithm |
In other words, Ed25519 at 256 bits reaches roughly the same security level as RSA at 3072 bits — using less than an eighth of the key size. It's more secure than RSA 2048-bit while producing much shorter keys and signatures, which speeds up not just storage but key generation, signing, and verification alike. RSA has to keep growing its keys to stay secure (RSA 1024-bit is already effectively retired, and that's without even factoring in the threat of quantum computers), while elliptic curves reach the same goal through a mathematically more efficient structure at a much smaller size.
3. Where the speed difference actually shows up
Generating an RSA key requires finding two large prime numbers, and that primality testing itself is a heavy computation. Build a 4096-bit RSA key command with the SSH Key Generator and run it yourself — it can take anywhere from a few seconds to tens of seconds, while Ed25519 finishes almost instantly. Signature verification is faster with Ed25519 too. This difference barely matters to an individual user generating a key once, but it adds up as perceptible latency in server environments or CI/CD pipelines where SSH connections — and signatures — happen constantly.
4. The trap when pasting the command into a shell
Separately from the algorithm choice, a common mistake when building a ssh-keygen command is putting characters that the shell treats specially — directly, unescaped — into the comment (-C) or file path (-f). For example, if a comment contains double quotes, like John "Desktop" Kim, and you insert it unescaped as -C "John "Desktop" Kim", the shell sees mismatched quotes and either throws a syntax error or cuts the command off somewhere you didn't intend. A $ is similarly interpreted as a variable reference and can get silently substituted with an unwanted value, and backticks execute whatever's inside them as a separate command.
escShellDouble() function chains replace() calls in the order backslash → $ → double quote → backtick to auto-escape input. Enter John "Desktop" Kim as the comment, and the generated command becomes -C "John \"Desktop\" Kim" — pasted straight into a terminal, the shell reads it as exactly one correctly-formed string.
5. When you should still reach for RSA
Ed25519 is the better choice in most situations, but some very old legacy servers or certain network equipment (management consoles on older routers/switches, for instance) don't support EdDSA at all and only accept RSA. It's reasonable to fall back to RSA — and at least 3072-bit when you do — only when that kind of compatibility constraint is confirmed. For reference, this tool supports only RSA 2048-bit, RSA 4096-bit, and Ed25519, and doesn't offer ECDSA separately; that's because EdDSA is designed to be more resistant to implementation mistakes (such as nonce reuse) than ECDSA, which is why it's ranked as the preferred choice in practice.
Frequently Asked Questions
Q. Can I use an Ed25519 key alongside an existing RSA key?
Yes. You can keep multiple keys in ~/.ssh/ at once, and register different keys for different servers/services. Use a distinct filename (e.g. id_ed25519_github) so you don't overwrite an existing key.
Q. Does a longer key always mean more security?
Generally true within the same algorithm, but the comparison stops making sense once you cross algorithms. RSA 4096-bit is numerically far larger than Ed25519 256-bit, yet their security levels are similar — and in some assessments, Ed25519 is even rated higher.
Q. Is it safe to put special characters in the passphrase too?
The passphrase is entered through a separate prompt during ssh-keygen execution, so it never becomes part of the command string — shell escaping isn't a concern there. If anything, a long passphrase mixing in special characters is the recommended, more secure choice.
Q. Is it okay to leave the comment blank?
Yes. The comment is just an identifying string tacked onto the end of the public key file — it has no bearing on the key's actual security, so omitting it causes no problem with key generation.