Ed25519 signs a message in roughly 20 microseconds. RSA-2048 takes 667 microseconds for the same operation. That 33x speed gap, combined with signatures that are 4x smaller and keys that shrink from 256 bytes down to 32 bytes, explains why Ed25519 has displaced RSA as the default SSH key type across GitHub, GitLab, and most modern Linux deployments. This comparison covers every dimension: benchmark data, key sizes, security bits, TLS certificate compatibility, real-world adoption, post-quantum risk, and a step-by-step migration guide.

Ed25519 vs RSA: Full Specs Comparison Table

The table below consolidates the core technical differences between Ed25519, RSA-2048, and RSA-4096. Security equivalence follows NIST SP 800-57 Part 1 Rev 5 and NIST SP 800-186, which place Edwards25519 at approximately 128 bits of classical security, matching RSA-3072, not RSA-2048.

PropertyEd25519RSA-2048RSA-4096
Algorithm familyEdDSA (Edwards curve)RSA (integer factorization)RSA (integer factorization)
Key size (bits)2562,0484,096
Public key (bytes)32256512
Private key storage (bytes)~119 (PEM)~1,679 (PEM PKCS#8)~3,243 (PEM PKCS#8)
Signature size (bytes)64256512
Security bits (classical)~128~112~140
Signing speed (ops/sec)50,000–100,0001,000–2,000200–500
Verification speed (ops/sec)20,000–30,00030,000–50,0008,000–15,000
Key generation time<1ms~100ms~400ms
Deterministic signingYes (no random nonce)Yes (PSS) / No (PKCS#1)Yes (PSS) / No (PKCS#1)
TLS server cert supportNot yet (CA/B Forum)Full supportFull support
SSH support (OpenSSH)Since v6.5 (Jan 2014)Since v1.0Since v1.0
NIST-approved (FIPS 186-5)Yes (EdDSA, 2023)YesYes
Quantum-resistantNoNoNo
Node.js supportSince v12.0.0 (Apr 2019)All versionsAll versions
NIST acceptable throughUntil PQC transition (~2035)2030 (112-bit legacy)2035+

Algorithm Basics: How Ed25519 and RSA Work

RSA, published by Rivest, Shamir, and Adleman in 1977, grounds its security in the difficulty of factoring the product of two large prime numbers. A 2048-bit RSA key pairs a 2048-bit modulus n = p x q with a public exponent e and a private exponent d. Every cryptographic operation, whether signing or verifying, performs modular exponentiation on this 256-byte integer. That operation scales roughly with the cube of the key length, so moving from RSA-2048 to RSA-4096 does not double the computation, it multiplies it by roughly 8. RSA-4096 signing runs at 200 to 500 operations per second compared to 1,000 to 2,000 for RSA-2048.

Ed25519, introduced by Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang in 2011, operates on the twisted Edwards curve ax2 + y2 = 1 + dx2y2 over GF(2255 minus 19). The curve is designed to allow addition formulas that work without special-casing the identity point or the point at infinity, eliminating a category of implementation bugs that have caused real-world vulnerabilities in traditional Weierstrass curves such as NIST P-256. The mathematical structure also makes constant-time implementation straightforward, which matters for avoiding timing side-channel attacks.

The most important operational difference between Ed25519 and RSA (or ECDSA) is determinism. Ed25519 signing derives its internal nonce from a hash of the private key and the message, so the same input always produces the same signature. ECDSA requires a cryptographically random nonce per signature. If that nonce is reused or predictably biased, the private key leaks completely. This exact failure compromised the PlayStation 3’s signing key in 2010 and has contributed to multiple cryptocurrency wallet drains since then. Ed25519’s deterministic design rules out that attack class entirely.

Performance Benchmarks: 3 Sources, Real Numbers

Benchmark numbers for ed25519 vs rsa appear consistently across independent test environments. The figures below come from OpenSSL’s built-in speed test (openssl speed ed25519 rsa2048 rsa4096), the libsodium documentation, and IPFS engineering’s published performance analysis. Hardware context: single core on a 2.4 GHz x86-64 processor.

AlgorithmSigns/secVerifies/secKey gen timeSignature (bytes)
Ed2551950,000–100,00020,000–30,000<1ms64
RSA-20481,000–2,00030,000–50,000~100ms256
RSA-3072~300–700~15,000–25,000~250ms384
RSA-4096200–5008,000–15,000~400ms512
ECDSA P-2568,000–15,0004,000–8,000<5ms64–72

The numbers reveal a counterintuitive fact about RSA: verification is faster than signing. Because the public exponent e is typically a small number (65537), verification performs far fewer modular multiplications than signing. Ed25519 behaves differently. Its verification requires two scalar multiplications on the Edwards curve, which takes more work than Ed25519 signing but still comfortably outperforms RSA-4096 verification.

For SSH connections, signing speed determines how fast a client authenticates. A server handling 1,000 concurrent SSH authentications per second would use roughly half the RSA-2048 signing budget on a single core, while Ed25519 handles that load with 95% capacity remaining. For CI/CD systems that generate new SSH keys per ephemeral build container, Ed25519’s sub-millisecond key generation versus RSA-4096’s 400ms startup cost adds up to significant latency at scale.

Signing Speed vs Verification Speed: Why RSA Verification Is Fast

RSA verification uses the public exponent 65537, which is small enough to compute in roughly 17 modular squarings (since 65537 = 2^16 + 1). RSA signing uses the private exponent, which is a full 2048-bit or 4096-bit number, requiring hundreds of modular squarings and multiplications. This asymmetry is structural: RSA is designed to make verification cheap and signing expensive.

In TLS 1.3, the server always signs the handshake transcript and the client always verifies, so server-side signing speed is the performance bottleneck for web traffic. A high-traffic web server choosing between RSA-4096 and Ed25519 certificates would see 100x to 250x fewer CPU cycles per TLS handshake for the signature operation alone. This is part of why Cloudflare, Google, and Meta moved their TLS certificates to ECDSA P-256 years ago, and why Ed25519 is the logical next step once the CA/Browser Forum approves it.

Key Size and Signature Size: The 8x Difference

Key and signature sizes matter in bandwidth-constrained environments, embedded systems, and blockchains where every byte on every transaction counts. Ed25519 compresses what RSA needs 3072 bits to express into just 256 bits, and the practical size difference is dramatic across every representation format.

MeasurementEd25519RSA-2048RSA-4096
Raw public key (bytes)32256512
Raw private key seed (bytes)32~1,190 (PKCS#1 incl. CRT params)~2,350
Signature (bytes)64256512
SSH public key file (characters)~68~380~724
PEM private key file (bytes)~119~1,679~3,243
JWT signature (Base64 chars)86342683

For SSH authorized_keys files with thousands of entries, the difference between 68-character Ed25519 entries and 724-character RSA-4096 entries translates to a 10x file size difference. For blockchains where each transaction embeds a public key and signature, the savings compound over millions of transactions. Solana, which processes roughly 65,000 transactions per second, uses Ed25519 signatures specifically because their 64-byte footprint fits within tight per-transaction byte budgets.

RFC 8032 defines the Ed25519 private key as a 32-byte secret seed, though some libraries (including Python’s cryptography package) return a 64-byte “signing key” that concatenates the seed with the public key for convenience. The underlying secret is still 32 bytes. RSA private keys in PKCS#1 format store the modulus, public exponent, private exponent, two prime factors, and three precomputed CRT coefficients, which is why an RSA-2048 private key file runs to roughly 1,679 bytes even though the security-relevant mathematical secret is theoretically just the two 1024-bit primes.

Security Bits: What 128-Bit Security Actually Means

Security bits measure the computational work required to break an algorithm using the best known attack. 128-bit security means an attacker needs roughly 2^128 operations, a number no foreseeable classical computer can accomplish. NIST SP 800-57 Part 1 Rev 5 establishes the definitive equivalence table that maps RSA key sizes to elliptic-curve key sizes and symmetric key sizes at the same security level:

Security bitsSymmetric key equivalentRSA key sizeElliptic curve key sizeEd25519 equivalent
803DES-1121,024 bits160–223 bitsNo (too weak)
1123DES-1682,048 bits224–255 bitsPartial (legacy only)
128AES-1283,072 bits256 bitsYes (Ed25519 = 128-bit)
192AES-1927,680 bits384 bits (P-384)No (below P-384)
256AES-25615,360 bits512 bits (P-521)No (below P-521)

The table reveals a critical mismatch that most developers miss. RSA-2048 provides only 112 bits of security, which NIST classifies as “acceptable for legacy processing” but already below the 128-bit threshold recommended for new systems. RSA-3072 reaches 128-bit security, matching Ed25519, but at 3072 bits the RSA modulus is 384 bytes and signing slows to approximately 300 to 700 operations per second, roughly 100x to 300x slower than Ed25519.

NIST SP 800-57 Part 1 Rev 5 states explicitly that RSA-2048, with its 112-bit security level, is acceptable only for protecting data through 2030 and is not recommended for long-lived credentials or data that must remain confidential past that date. For new systems designed in 2026, NIST guidance effectively points away from RSA-2048 and toward either RSA-3072 or elliptic-curve alternatives such as P-256 and Ed25519 that achieve 128-bit security with far smaller keys.

TLS Certificates: The One Area Where RSA Still Wins

Ed25519 is not available for TLS/HTTPS server certificates as of June 2026. Let’s Encrypt issues certificates only for RSA and ECDSA (P-256 and P-384). DigiCert, Sectigo, and other commercial CAs do not offer Ed25519 certificate products. The CA/Browser Forum, which sets the baseline requirements for publicly trusted certificates, has not yet standardized Ed25519 as an approved key algorithm for server certificates.

This is not because Ed25519 is insecure for TLS. RFC 8446 (TLS 1.3) lists EdDSA (including Ed25519) as a valid signature algorithm for client authentication, and TLS 1.3 handshakes can use Ed25519 for that purpose. The gap is specifically in server certificates: the X.509 certificate chain that browsers validate when connecting to a website must use an algorithm the CA/Browser Forum approves, and Ed25519 is not yet on that list. When it eventually is approved, migration will be smooth because the underlying TLS 1.3 protocol already supports it.

For current HTTPS deployments, ECDSA P-256 is the modern alternative to RSA. Cloudflare, Google, and Meta use ECDSA P-256 certificates for their public TLS infrastructure. The P-256 signature is 64 bytes, matching Ed25519’s size. Browser support is universal, and CA pricing is identical to RSA at the same validation level.

DKIM Email Signing: Ed25519 Support Is Partial in 2026

DKIM (DomainKeys Identified Mail) supports Ed25519 as a signature algorithm alongside RSA. Google, Fastmail, and most open-source mail transfer agents (Postfix, Exim, OpenDKIM) can generate and verify Ed25519 DKIM signatures. However, Microsoft 365 and Yahoo Mail do not verify Ed25519 DKIM signatures as of 2026, which means deploying Ed25519 DKIM exclusively risks mail delivery failures to those providers. The safe approach is dual signing: publish both an RSA-2048 DKIM selector and an Ed25519 DKIM selector, letting receiving servers use whichever they support.

SSH Keys: Ed25519 Is the Clear Default in 2026

OpenSSH added Ed25519 support in version 6.5, released in January 2014. By 2026, Ed25519 has been the recommended SSH key type in OpenSSH documentation for over a decade. GitHub and GitLab both recommend Ed25519 SSH keys for all new authentication. The advantages over RSA in the SSH context are concrete and measurable.

  • Shorter authorized_keys entries. A 68-character Ed25519 key versus a 724-character RSA-4096 key in authorized_keys files. For fleet-level systems with hundreds of service accounts, this difference is significant.
  • Faster authentication. On a CPU handling 1,000 SSH logins per second, Ed25519 signs in under 1 millisecond. RSA-2048 takes 0.5–1ms for signing, and RSA-4096 takes 2–5ms. At 10,000 logins per second, RSA-4096 is the bottleneck.
  • No weak key generation risk. RSA key generation requires finding large prime numbers, which can fail silently or take unexpectedly long on VMs with limited entropy during boot. Ed25519 key generation samples 32 random bytes and hashes them, completing reliably in any environment.
  • Deterministic signatures. No ECDSA-style nonce generation required. The private key cannot be extracted through reused or biased nonces.

The only remaining reason to generate RSA SSH keys in 2026 is compatibility with legacy systems running OpenSSH versions earlier than 6.5, released in January 2014. Any server running a 2014-or-newer OpenSSH accepts Ed25519. Any modern cloud VM or hosted service (AWS, GCP, Azure, DigitalOcean) accepts Ed25519 SSH keys without configuration changes.

Real-World Adoption: Who Uses Ed25519 in 2026?

Ed25519 and its sibling Curve25519 (used for key exchange rather than signatures) have spread through the security-critical infrastructure of the modern internet, often as a direct replacement for RSA or DSA.

System / ProtocolHow Ed25519 / Curve25519 is usedYear adopted
Tor v3 onion servicesEd25519 keys for .onion address identity and descriptor signing2017
Signal Protocol (X3DH)Ed25519 signs the signed pre-key; Curve25519 for Diffie-Hellman2016
Solana blockchainEd25519 for all transaction and validator signatures2020
MoneroEdwards-curve arithmetic (same family) for key generation and ring signatures2014
Matrix / ElementEd25519 for device identity keys in Olm/Megolm end-to-end encryption2016
OpenSSHHost keys, user keys, SSH certificates2014
DNSSEC (RFC 8080)DNS zone signing as Algorithm 152017
WireGuard VPNCurve25519 (X25519) for handshake key exchange2018
Age encryption toolX25519 for recipient key exchange, Curve25519 identities2021
Git commit signing (GitHub)Ed25519 SSH key signing for Git commits2022

Notably absent from the Ed25519 list is Ethereum, which uses ECDSA on the secp256k1 curve (Bitcoin’s curve) for account signatures. Bitcoin also uses secp256k1 ECDSA. These systems predate Ed25519’s widespread standardization and changing the signature algorithm in a deployed blockchain requires a hard fork, so both remain on secp256k1 despite Ed25519’s performance and simplicity advantages.

The breadth of Ed25519 adoption across privacy tools (Tor, Signal), distributed systems (Solana, DNSSEC), and infrastructure (OpenSSH, WireGuard) reflects a broad consensus in the cryptographic engineering community. The Curve25519 and Ed25519 constructions have passed extensive public scrutiny over the past decade, and no structural weaknesses have been found.

Post-Quantum Risk: Both Algorithms Lose to Shor’s Algorithm

Neither Ed25519 nor RSA survives a quantum computer running Shor’s algorithm at scale. Shor’s algorithm solves integer factorization in polynomial time (breaking RSA) and the discrete logarithm problem on elliptic curves in polynomial time (breaking Ed25519). Both algorithms face the same existential threat from quantum computing. This is a critical point that marketing around “quantum-safe” alternatives sometimes obscures: Ed25519 is not more quantum-resistant than RSA, and RSA is not more quantum-resistant than Ed25519.

NIST’s post-quantum cryptography standardization process, finalized in 2024, produced two primary post-quantum signature algorithms for deployment:

  • FIPS 204 (ML-DSA, formerly CRYSTALS-Dilithium). A lattice-based signature scheme designed to replace Ed25519 and ECDSA in signature roles. ML-DSA at the 128-bit post-quantum security level produces 2,420-byte signatures and 1,312-byte public keys. Larger than Ed25519, but fast enough for most applications.
  • FIPS 205 (SLH-DSA, formerly SPHINCS+). A hash-based signature scheme with no structural dependence on any algebraic assumption. It is slower than ML-DSA and produces 7,856-byte signatures at the 128-bit security level, but offers the highest confidence in long-term security because its security reduces to the security of the underlying hash function.

NIST’s post-quantum transition guidance targets deprecation of RSA and elliptic-curve algorithms (including Ed25519) from new systems around 2030, with a hard cutoff around 2035. For long-lived signing keys, such as root CA certificates, code signing keys used across decades of software distribution, or credentials protecting data with confidentiality requirements past 2040, the PQC migration should begin now. For short-lived SSH session authentication keys, the urgency is much lower because the signed data (handshake messages) has no value beyond the session.

Ed25519 vs ECDSA P-256: A Third Option Worth Knowing

Developers comparing ed25519 vs rsa often overlook a third option: ECDSA with NIST curve P-256 (also called secp256r1 or prime256v1). P-256 is the algorithm Cloudflare, Google, and Meta use for their TLS server certificates, and it occupies an important position between Ed25519 and RSA.

PropertyEd25519ECDSA P-256RSA-2048
Security bits~128~128~112
Signature size (bytes)6464–72 (DER encoded)256
Public key (bytes)3233 (compressed point)256
TLS server certificate supportNo (2026)Yes (universal)Yes
SSH supportYes (recommended)Yes (ecdsa-sha2-nistp256)Yes
Deterministic signingYesNo (requires secure RNG)Depends on padding
Nonce reuse riskNoneCritical (key exposure)None (RSA-PSS)
Implementation complexityLowMedium (edge cases exist)Medium

For TLS certificates in 2026, P-256 is the best current option. It provides 128-bit security, is universally supported by browsers and CAs, produces 64-byte signatures matching Ed25519’s size, and has been deployed at hyperscaler scale for years without incident.

For SSH and non-TLS signing, Ed25519 is preferable to P-256 for two reasons. First, Ed25519 is deterministic, eliminating the nonce reuse vulnerability that makes ECDSA catastrophic when the random number generator is weak or predictable. Second, Ed25519’s implementation on the Edwards25519 curve avoids the cofactor complications and special-case handling that make P-256 slightly more complex to implement correctly in constant time. The OpenSSH team and most security tooling vendors recommend Ed25519 over ECDSA P-256 for SSH keys precisely because of this robustness difference.

Ed25519 and RSA Implementation in Node.js

Node.js added Ed25519 key generation and signing support in version 12.0.0, released April 23, 2019, through the built-in crypto module which wraps OpenSSL 1.1.1. All Node.js versions from v12 onward support Ed25519 without additional dependencies.

const { generateKeyPairSync, sign, verify } = require('crypto');

// Generate Ed25519 key pair — takes under 1ms
const { privateKey, publicKey } = generateKeyPairSync('ed25519');

// Sign a message
const message = Buffer.from('Hello, shattered.io');
const signature = sign(null, message, privateKey);

console.log('Signature length (bytes):', signature.length); // 64
console.log('Public key type:', publicKey.asymmetricKeyType); // ed25519

// Verify the signature
const isValid = verify(null, message, publicKey, signature);
console.log('Valid:', isValid); // true

// Export keys in PEM format
const privatePem = privateKey.export({ type: 'pkcs8', format: 'pem' });
const publicPem = publicKey.export({ type: 'spki', format: 'pem' });
console.log('Private key PEM length:', privatePem.length); // ~119 bytes
console.log('Public key PEM length:', publicPem.length);   // ~119 bytes

Contrast this with RSA, which requires specifying a modulus length and generates keys that are 10 to 30 times larger in PEM representation:

const { generateKeyPairSync } = require('crypto');

// RSA-2048 key generation — takes ~100ms
const { privateKey: rsaPriv, publicKey: rsaPub } = generateKeyPairSync('rsa', {
  modulusLength: 2048,
  publicKeyEncoding: { type: 'spki', format: 'pem' },
  privateKeyEncoding: { type: 'pkcs8', format: 'pem' }
});

console.log('RSA-2048 private key PEM length:', rsaPriv.length); // ~1,680 bytes
console.log('RSA-2048 public key PEM length:', rsaPub.length);   // ~451 bytes

// RSA-4096 generation — takes ~400ms
const { privateKey: rsa4096Priv } = generateKeyPairSync('rsa', {
  modulusLength: 4096,
  privateKeyEncoding: { type: 'pkcs8', format: 'pem' }
});
console.log('RSA-4096 private key PEM length:', rsa4096Priv.length); // ~3,243 bytes

For JWT signing in Node.js, the jsonwebtoken library supports the algorithm identifier EdDSA for Ed25519 keys. The resulting JWT is significantly smaller than an RSA-signed JWT: the signature component shrinks from 342 Base64 characters (RSA-2048) to 86 Base64 characters (Ed25519), a 4x reduction. For APIs issuing millions of tokens per day, the reduced token size is measurable in network bandwidth and parsing time.

Migration Guide: RSA SSH Keys to Ed25519

Migrating SSH keys from RSA to Ed25519 is safe to do incrementally. Add the Ed25519 key first, verify it works everywhere the RSA key is used, then retire the RSA key. Removing the RSA key before testing Ed25519 access is the only way to lock yourself out.

Step-by-Step SSH Migration

Step 1. Generate a new Ed25519 key pair. The -a 100 flag sets 100 rounds of KDF iteration for the private key passphrase, balancing unlock time with brute-force resistance.

# Generate Ed25519 key (completes in under 1ms)
ssh-keygen -t ed25519 -a 100 -C "[email protected]" -f ~/.ssh/id_ed25519

# Verify the key type and fingerprint
ssh-keygen -l -f ~/.ssh/id_ed25519.pub
# Output: 256 SHA256:... [email protected] (ED25519)

Step 2. Add the Ed25519 public key to all target servers while the RSA key still works.

# Copy to a remote server using ssh-copy-id (RSA key still authenticates)
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

# Or manually append to authorized_keys
cat ~/.ssh/id_ed25519.pub | ssh user@server "cat >> ~/.ssh/authorized_keys"

Step 3. Test Ed25519 login explicitly before removing the RSA key.