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.
| Property | Ed25519 | RSA-2048 | RSA-4096 |
|---|---|---|---|
| Algorithm family | EdDSA (Edwards curve) | RSA (integer factorization) | RSA (integer factorization) |
| Key size (bits) | 256 | 2,048 | 4,096 |
| Public key (bytes) | 32 | 256 | 512 |
| Private key storage (bytes) | ~119 (PEM) | ~1,679 (PEM PKCS#8) | ~3,243 (PEM PKCS#8) |
| Signature size (bytes) | 64 | 256 | 512 |
| Security bits (classical) | ~128 | ~112 | ~140 |
| Signing speed (ops/sec) | 50,000–100,000 | 1,000–2,000 | 200–500 |
| Verification speed (ops/sec) | 20,000–30,000 | 30,000–50,000 | 8,000–15,000 |
| Key generation time | <1ms | ~100ms | ~400ms |
| Deterministic signing | Yes (no random nonce) | Yes (PSS) / No (PKCS#1) | Yes (PSS) / No (PKCS#1) |
| TLS server cert support | Not yet (CA/B Forum) | Full support | Full support |
| SSH support (OpenSSH) | Since v6.5 (Jan 2014) | Since v1.0 | Since v1.0 |
| NIST-approved (FIPS 186-5) | Yes (EdDSA, 2023) | Yes | Yes |
| Quantum-resistant | No | No | No |
| Node.js support | Since v12.0.0 (Apr 2019) | All versions | All versions |
| NIST acceptable through | Until 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.
| Algorithm | Signs/sec | Verifies/sec | Key gen time | Signature (bytes) |
|---|---|---|---|---|
| Ed25519 | 50,000–100,000 | 20,000–30,000 | <1ms | 64 |
| RSA-2048 | 1,000–2,000 | 30,000–50,000 | ~100ms | 256 |
| RSA-3072 | ~300–700 | ~15,000–25,000 | ~250ms | 384 |
| RSA-4096 | 200–500 | 8,000–15,000 | ~400ms | 512 |
| ECDSA P-256 | 8,000–15,000 | 4,000–8,000 | <5ms | 64–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.
| Measurement | Ed25519 | RSA-2048 | RSA-4096 |
|---|---|---|---|
| Raw public key (bytes) | 32 | 256 | 512 |
| Raw private key seed (bytes) | 32 | ~1,190 (PKCS#1 incl. CRT params) | ~2,350 |
| Signature (bytes) | 64 | 256 | 512 |
| SSH public key file (characters) | ~68 | ~380 | ~724 |
| PEM private key file (bytes) | ~119 | ~1,679 | ~3,243 |
| JWT signature (Base64 chars) | 86 | 342 | 683 |
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 bits | Symmetric key equivalent | RSA key size | Elliptic curve key size | Ed25519 equivalent |
|---|---|---|---|---|
| 80 | 3DES-112 | 1,024 bits | 160–223 bits | No (too weak) |
| 112 | 3DES-168 | 2,048 bits | 224–255 bits | Partial (legacy only) |
| 128 | AES-128 | 3,072 bits | 256 bits | Yes (Ed25519 = 128-bit) |
| 192 | AES-192 | 7,680 bits | 384 bits (P-384) | No (below P-384) |
| 256 | AES-256 | 15,360 bits | 512 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_keysfiles. 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 / Protocol | How Ed25519 / Curve25519 is used | Year adopted |
|---|---|---|
| Tor v3 onion services | Ed25519 keys for .onion address identity and descriptor signing | 2017 |
| Signal Protocol (X3DH) | Ed25519 signs the signed pre-key; Curve25519 for Diffie-Hellman | 2016 |
| Solana blockchain | Ed25519 for all transaction and validator signatures | 2020 |
| Monero | Edwards-curve arithmetic (same family) for key generation and ring signatures | 2014 |
| Matrix / Element | Ed25519 for device identity keys in Olm/Megolm end-to-end encryption | 2016 |
| OpenSSH | Host keys, user keys, SSH certificates | 2014 |
| DNSSEC (RFC 8080) | DNS zone signing as Algorithm 15 | 2017 |
| WireGuard VPN | Curve25519 (X25519) for handshake key exchange | 2018 |
| Age encryption tool | X25519 for recipient key exchange, Curve25519 identities | 2021 |
| Git commit signing (GitHub) | Ed25519 SSH key signing for Git commits | 2022 |
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.
| Property | Ed25519 | ECDSA P-256 | RSA-2048 |
|---|---|---|---|
| Security bits | ~128 | ~128 | ~112 |
| Signature size (bytes) | 64 | 64–72 (DER encoded) | 256 |
| Public key (bytes) | 32 | 33 (compressed point) | 256 |
| TLS server certificate support | No (2026) | Yes (universal) | Yes |
| SSH support | Yes (recommended) | Yes (ecdsa-sha2-nistp256) | Yes |
| Deterministic signing | Yes | No (requires secure RNG) | Depends on padding |
| Nonce reuse risk | None | Critical (key exposure) | None (RSA-PSS) |
| Implementation complexity | Low | Medium (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 bytesContrast 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 bytesFor 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.
Latest news
CybersecuritySQL Injection Prevention in Node.js: 12 Steps [2026]Jun 21, 2026
CybersecurityFortiBleed: 86,644 Fortinet Firewalls Exposed in 194 Countries [2026]Jun 21, 2026
CybersecurityPalo Alto GlobalProtect CVE-2026-0257: CVSS 7.8 Auth Bypass Exploited [2026]Jun 21, 2026
Cybersecuritynpm audit: 12 Steps to Fix Node.js Vulnerabilities [2026]Jun 20, 2026