RSA vs Ed25519: Asymmetric Cryptography and Digital Signatures Explained

I once spent a long evening trying to understand why a deploy bot couldn't SSH into a production server after a key rotation. The bot was generating fresh RSA-1024 keys (the old default in some Linux distros), and the server's OpenSSH had quietly stopped accepting them in the upgrade. Switching the bot to Ed25519 fixed it in five minutes. The right asymmetric algorithm is rarely the most exotic one — it is the one whose defaults match the rest of your stack today.

Why Asymmetric Cryptography Exists

Symmetric algorithms like AES-256-GCM are fast and battle-tested, but they have one awkward requirement: every party that wants to read the message has to share the same secret key. The moment you need to communicate with someone you have never met — a new SSH server, a stranger's API, a peer on a public blockchain — symmetric crypto stops being enough. You cannot hand them the key over the same channel you are trying to secure.

Asymmetric cryptography (also called public key cryptography) flips the model. Each party generates a key pair: a private key kept secret and a public key that can be shared freely. Operations performed with one half can only be undone or verified with the other half. From those two primitives — sign/verify and encrypt/decrypt — every modern authenticated channel on the internet is built.

For most production work today, the choice narrows to two algorithms. RSA has been the workhorse since 1977 and is still everywhere — TLS certificates, SSH keys, JWT tokens, code signing. Ed25519is the modern challenger: smaller keys, faster operations, simpler to implement correctly. Most other names you will see (DSA, ECDSA on different curves, EdDSA on Curve448) are either legacy or niche. The question is no longer "RSA or DSA"; it is "RSA or Ed25519, and why?"

RSA in Depth

RSA was published by Rivest, Shamir, and Adleman in 1977 and is built on the practical difficulty of factoring the product of two large primes. Key generation picks two random primes p and q, multiplies them, and derives the rest of the key material from there. Decades of public scrutiny have not produced a polynomial-time factoring algorithm on classical hardware, so RSA at an appropriate key size is still considered safe.

Sign and Verify

서명 (private key):
  msg_hash = SHA-256(message)
  signature = RSA_sign(private_key, msg_hash)   # PSS 패딩 권장

검증 (public key):
  ok = RSA_verify(public_key, msg_hash, signature)
  ok가 true면 메시지 변조 없음 + 서명자가 private_key 보유 입증

Key Sizes

• RSA-1024 — broken in practice for high-value targets, OpenSSH rejects it by default since 8.x. Do not use.
• RSA-2048 — the current minimum. NIST recommends through 2030. The common default for TLS certs.
• RSA-3072 — recommended new default for long-lived keys (CA roots, firmware signing).
• RSA-4096 — common for paranoia or compliance. Slow signing, marginally better security than 3072.

Key length grows much faster than security. Doubling the key size from 2048 to 4096 only adds about 16 bits of effective security, while making sign/verify roughly 5–8× slower. This nonlinear cost is the single biggest reason to consider Ed25519.

Padding Matters

Raw RSA is not safe for signing. The signature scheme has to wrap the hash in a deterministic or randomized padding format before encryption. Use RSA-PSS (Probabilistic Signature Scheme) for new work — it has a formal security proof and is the standard for JWT (`PS256`/`PS384`/`PS512`). RSASSA-PKCS1-v1_5 is older but still everywhere (TLS, JWT `RS256`); it is OK if you cannot pick PSS. Avoid hand-rolled padding at all costs.

Ed25519 in Depth

Ed25519 is an EdDSA signature scheme over Curve25519, designed by a team led by Daniel J. Bernstein in 2011. It was built deliberately to avoid the operational footguns that plague RSA and ECDSA: deterministic nonces (no bad RNG bricking your key), fixed key and signature sizes, and a curve where every well-formed point produces a valid result so you cannot accidentally use a weak parameter.

Numbers Worth Knowing

• Private key: 32 bytes
• Public key: 32 bytes
• Signature: 64 bytes
• Effective security level: ~128 bits (comparable to RSA-3072)

Compare that to RSA-3072: ~384-byte public key, ~384-byte signature, slower sign/verify. For a JWT or a Bitcoin transaction or an SSH handshake, the size difference compounds across thousands of operations per second.

Sign and Verify

서명 (Ed25519, 결정적):
  signature = Ed25519_sign(private_key, message)
  // 같은 메시지·키 → 항상 같은 64-byte 서명 (RNG 불필요)

검증:
  ok = Ed25519_verify(public_key, message, signature)

The deterministic nonce property is the killer feature in operational environments. ECDSA implementations have leaked private keys multiple times because of weak randomness during signing (Sony PS3, Android wallet apps, blockchain bridge bugs). Ed25519 derives its nonce from the message and the secret key via SHA-512, so no random number generator can ruin it.

RSA vs Ed25519 at a Glance

For a brand new system on a modern stack, Ed25519 is the better default. For interoperating with legacy systems or vendors that mandate certificate chains rooted in RSA, RSA-3072 with PSS is still a perfectly defensible choice. You will end up supporting both at some point — most production servers do.

Digital Signatures Are Not Encryption

This is the single most common misconception in code reviews involving public-key crypto: treating signatures and encryption as interchangeable. They share keys but answer different questions.

• Encryption — confidentiality. Anyone with the public key can scramble a message, only the private key holder can read it.
• Signing — authenticity + integrity. The private key holder produces a signature; anyone with the public key can verify the message has not been tampered with and that the signer authorized it.

Ed25519 only signs, by design. RSA can technically do both, but you almost never want to use the same key pair for signing and key exchange — separating roles is a fundamental defense-in-depth practice. Most modern protocols use a signing key (RSA or Ed25519) plus a separate key-exchange key (ECDH on Curve25519, X25519) and derive a fresh symmetric key per session.

Where You Will Actually Encounter These

SSH

OpenSSH supports RSA, ECDSA, and Ed25519 host and user keys. Modern guidance is unambiguous: prefer Ed25519. Run ssh-keygen -t ed25519 for new keys. Use RSA-3072 only when interoperating with a host that does not yet support Ed25519 (rare in 2026 but still happens with some appliances and old enterprise SSO).

JWT

JWT supports several signature algorithms: HS256 (HMAC, symmetric), RS256 (RSA-PKCS1-v1_5), PS256 (RSA-PSS), ES256 (ECDSA), EdDSA (Ed25519). For inter-service tokens where the verifier is different from the issuer, asymmetric (RS/PS/ES/EdDSA) is the right pick — only the issuer can sign, anyone with the public key can verify. EdDSA and PS256 are the modern recommendations.

Git Commit Signing

Both GitHub and GitLab support signed commits via GPG (RSA/Ed25519), SSH (Ed25519 recommended), or sigstore. Configure git config commit.gpgsign true and use Ed25519 keys — the verified badge that appears next to commits is a small but meaningful supply-chain signal.

TLS

Public web certificates are still mostly RSA-2048 and ECDSA-P256, because that is what browsers and root stores have trusted for years. TLS 1.3 supports Ed25519 in theory but certificate authorities do not yet issue Ed25519 leaf certs widely. For internal mTLS within a company, where you control both ends, Ed25519 is fine and faster.

Blockchain

Bitcoin and Ethereum sign with ECDSA on the secp256k1 curve (a different ECDSA from the TLS world). Solana, NEAR, Polkadot, and Cosmos chains use Ed25519 (or Sr25519 in Polkadot). Cross-chain bridges and wallet libraries usually have to support both. The signature format differs but the underlying mental model — sign with private key, verify with public — is identical.

Key Rotation, Revocation, and HSMs

A signing key is only as safe as the system holding it. The main operational practices worth investing in:

• Rotation — define a key lifetime and rotate before it expires. Automating rotation (cert-manager, AWS ACM, HashiCorp Vault) is far safer than manual renewals.
• Revocation — have a fast path to invalidate a compromised key. CRLs and OCSP for X.509, key version markers for application-level signatures, on-chain revocation registries for Web3.
• HSM / KMS — keep private keys inside hardware. AWS KMS, Google Cloud KMS, Azure Key Vault, YubiHSM all support both RSA and Ed25519. The application asks the HSM to sign; the key never leaves.
• Auditing — log every signature operation with timestamp, identity, and digest. A surprise spike in signing requests is often the first signal of compromise.

Pitfalls in Code Reviews

Mixing PEM and OpenSSH formats

The same Ed25519 key is serialized differently for OpenSSH (id_ed25519 format), PEM (-----BEGIN PRIVATE KEY-----), and JWK. Library functions that expect one format will fail on another with confusing error messages. Convert with ssh-keygen -p -f key -m PEM or use a library that auto-detects.

RSA without padding

"Textbook RSA" without OAEP/PSS padding has multiple known attacks. Library defaults usually pick safe padding, but every once in a while you find code that calls the raw modular exponentiation directly. Don't.

Verifying with the wrong key

A surprisingly common bug: code accepts any signature that parses, then forgets to confirm the public key actually belongs to the expected issuer. JWT libraries have had high-severity CVEs for this exact pattern (`alg: none`, key confusion). Always pin the expected algorithm and key explicitly.

Try It with BeautiCode Tools

The fastest way to internalize the differences is to generate a few keys and watch the formats. All tools below run entirely in your browser — keys never leave the device.

• RSA Key Generator — pick 2048, 3072, or 4096 bits and feel the key generation latency. Compare PEM vs OpenSSH formats side by side.
• Ed25519 Key Generator — generate Ed25519 keys instantly, copy the 32-byte public key, and notice how much shorter the OpenSSH line is than RSA-3072.
• Hash Generator — compute the SHA-256 digest that signatures actually operate on. Useful for hand-verifying that two payloads produce the same signature input.
• JWT Decoder — decode a JWT to see the algorithm header (`RS256`, `PS256`, `EdDSA`) and the base64url-encoded signature blob.

Frequently Asked Questions

Should I migrate existing RSA keys to Ed25519?

For SSH user keys: yes, when convenient. For TLS certificates and CA roots: not yet — the ecosystem still expects RSA, and forcing Ed25519 will break interoperability. For new internal services where you control both ends, default to Ed25519 from day one. Migration on existing keys is opportunistic, not urgent.

Is Ed25519 quantum-safe?

No. Both RSA and Ed25519 are broken by Shor's algorithm on a sufficiently large quantum computer. The post-quantum future is signature schemes like ML-DSA (formerly Dilithium) or SLH-DSA (formerly SPHINCS+), standardized by NIST in 2024. For the next few years, the practical move is to plan for crypto-agility — keep the option open to swap algorithms, not bet the farm on one.

Why does my Ed25519 key sometimes look 64 bytes instead of 32?

The 64-byte form is the "expanded" private key: the original 32-byte seed plus the 32-byte public key concatenated for convenience. Most libraries return one form or the other; some accept both. It is the same key.

Can I sign anything with my SSH key?

Yes — modern OpenSSH ships ssh-keygen -Y sign and ssh-keygen -Y verify for arbitrary message signing using your existing SSH keys. Git commit signing with SSH keys uses this internally. It is a great way to leverage a key you already have.

Why does FIPS 140 take so long to approve new algorithms?

FIPS validation is a process certification, not just an algorithm one — vendors have to revalidate their entire cryptographic module each time the approved algorithm list changes. Ed25519 was finally added in FIPS 186-5 (2023). If you sell into U.S. federal or regulated sectors that mandate FIPS-validated modules, check your vendor's certificate before assuming Ed25519 is on the table.