Pick the wrong signature algorithm for a new SSH fleet, TLS deployment, or blockchain wallet in 2026 and you’re stuck rotating keys across thousands of endpoints two years later. That’s the practical stakes behind the Ed25519 vs ECDSA question, and it comes up constantly: in SSH key generation, in JWT signing libraries, in FIDO2 security key firmware, and in the signature scheme underneath chains like Solana and Ethereum. Both are elliptic-curve digital signature algorithms. Both were formally approved by NIST in the same document, FIPS 186-5, on February 3, 2023. And yet they behave differently enough in practice that the choice still matters.
This comparison walks through the real numbers: signature and key sizes in bytes, signing and verification throughput from OpenSSL and libsodium benchmarks, the nonce-handling flaw that let researchers extract Sony’s PlayStation 3 signing key in 2010, and where each algorithm actually ships today across SSH, TLS, WebAuthn, JWT, and major blockchains. By the end you’ll have a specs table, a pricing comparison for managed key services, a migration checklist, and a verdict backed by data rather than vibes.
What Ed25519 and ECDSA actually are
Both algorithms build digital signatures on top of elliptic curve math, but they use different curve shapes and different signing procedures. ECDSA (Elliptic Curve Digital Signature Algorithm) runs on Weierstrass curves, most commonly the NIST curves P-256, P-384, and P-521. It has been part of the federal cryptographic toolbox since FIPS 186-3 in 2009, and it’s the algorithm behind Bitcoin’s secp256k1 signing scheme, most TLS certificates issued by public certificate authorities, and the ES256 algorithm mandated by the FIDO2 WebAuthn specification.
Ed25519 is a specific instantiation of EdDSA (Edwards-curve Digital Signature Algorithm), built on the twisted Edwards curve Curve25519. It was designed in 2011 by a team including Daniel J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and Bo-Yin Yang, with an explicit goal stated in their paper: fast, small, and hard to implement incorrectly. RFC 8032 standardized the algorithm in 2017, and NIST folded it into FIPS 186-5 as an approved digital signature technique alongside RSA and ECDSA. OpenSSH added Ed25519 support in version 6.5, released in January 2014, and by late 2024 had flipped its own default signature preference from ECDSA to Ed25519.
The practical difference isn’t really about the math being “better” in one direction. It’s about what happens when the implementation is sloppy, and about how the two schemes perform on the hardware people actually deploy in 2026: cloud VMs, IoT devices, hardware security keys, and blockchain validator nodes.
Timeline: how we got two competing elliptic curve signature standards
Neither algorithm appeared in a vacuum. The gap between them exists because ECDSA had a fifteen-year head start in government and commercial standards before Ed25519 caught up on paper, and it’s still catching up in some corners of the ecosystem today.
| Date | Milestone |
|---|---|
| 2009 | NIST publishes FIPS 186-3, formally standardizing ECDSA for federal use |
| December 2010 | Fail0verflow and George Hotz extract Sony’s PS3 ECDSA signing key via nonce reuse |
| 2011 | Bernstein, Duif, Lange, Schwabe, and Yang publish the Ed25519 design paper |
| January 2014 | OpenSSH 6.5 adds Ed25519 support for user and host keys |
| 2017 | RFC 8032 formally standardizes EdDSA, including Ed25519 and Ed448 |
| 2018 | OpenSSL 1.1.1 adds Ed25519/Ed448 support for TLS and X.509 certificates |
| November 2, 2021 | GitHub cuts off new RSA SSH keys using SHA-1 signatures |
| February 3, 2023 | NIST publishes FIPS 186-5, approving EdDSA (Ed25519/Ed448) alongside RSA and ECDSA |
| Late 2024 | OpenSSH switches its ssh-keygen default and first-preference signature algorithm to Ed25519 |
| November 7, 2025 | AWS KMS adds native Ed25519 (EdDSA) signing support |
| 2026 | OpenSSH 10.4 adds experimental composite post-quantum signatures pairing ML-DSA-44 with Ed25519 |
Ed25519 vs ECDSA specs table: sizes, security levels, standards status
Here’s the side-by-side on the numbers that matter for capacity planning, storage, and bandwidth: key sizes, signature sizes, and where each stands with NIST.
| Property | Ed25519 (EdDSA) | ECDSA P-256 | ECDSA P-384 |
|---|---|---|---|
| Curve family | Twisted Edwards (Curve25519) | NIST Weierstrass | NIST Weierstrass |
| Public key size | 32 bytes | 65 bytes uncompressed / 33 compressed | 97 bytes uncompressed / 49 compressed |
| Private key size | 32 bytes | 32 bytes | 48 bytes |
| Signature size (raw) | 64 bytes (fixed) | 64 bytes raw / ~70-72 bytes DER | 96 bytes raw / ~100+ bytes DER |
| Security strength | ~128-bit | ~128-bit | ~192-bit |
| Nonce generation | Deterministic (hash of key + message) | Random by default; RFC 6979 deterministic variant optional | Random by default; RFC 6979 deterministic variant optional |
| NIST/FIPS status | Approved in FIPS 186-5 (Feb 3, 2023) | Approved since FIPS 186-3 (2009) | Approved since FIPS 186-3 (2009) |
| OpenSSH support since | Version 6.5 (Jan 2014) | Version 5.7 (2010) | Version 5.7 (2010) |
| WebAuthn/FIDO2 status | Optional (COSE alg -8) | Mandatory (ES256, COSE alg -7) | Supported, not mandated |
| Public Web PKI (Let’s Encrypt) certs | Not issued for browser-trusted certs | Issued and widely supported | Issued, less common than P-256 |
| Deterministic against weak RNG | Yes, by design | No, unless RFC 6979 explicitly used | No, unless RFC 6979 explicitly used |
| Quantum resistance | None (broken by Shor’s algorithm) | None (broken by Shor’s algorithm) | None (broken by Shor’s algorithm) |
Two rows tend to surprise people who assume Ed25519 wins on every axis. First, at the 128-bit security level, Ed25519 and ECDSA P-256 are roughly tied in raw signature size (64 bytes each, before ECDSA’s DER encoding overhead). The size advantage people cite for Ed25519 usually comes from comparing it to RSA, not to ECDSA. Second, neither algorithm offers any quantum resistance. Both rely on the elliptic curve discrete logarithm problem, and Shor’s algorithm breaks that problem on a sufficiently large quantum computer just as easily as it breaks RSA factoring. NIST’s post-quantum signature replacements, ML-DSA and SLH-DSA, exist precisely because neither Ed25519 nor ECDSA survives that transition.
Benchmarks: signing and verification speed compared
Performance numbers for these two algorithms vary a lot by CPU, library, and whether the implementation uses assembly-optimized field arithmetic. Rather than pick one number and present it as gospel, here’s what three separate benchmark sources report, so you can see the range rather than a single cherry-picked figure.
| Source | Ed25519 sign | Ed25519 verify | ECDSA P-256 sign | ECDSA P-256 verify |
|---|---|---|---|---|
| Ed25519 design paper (2.4 GHz Westmere Xeon) | ~108,000 ops/sec | ~71,000 ops/sec | Not tested in this paper | Not tested in this paper |
| NIST performance study (eBACS cycle conversion) | ~56,473 ops/sec | ~18,920 ops/sec | ~29,938 ops/sec | ~11,842 ops/sec |
| libsodium x86-64 benchmark | ~46,500 ops/sec | ~15,300 ops/sec | Library does not implement P-256 for this test | Library does not implement P-256 for this test |
The pattern holds across every credible source: Ed25519 signs roughly 1.5x to 2x faster than ECDSA P-256, and verifies roughly 1.5x to 1.6x faster, on the same hardware. Part of that gap comes from Ed25519’s constant-time, branch-free reference implementation, which was a design priority from the start. Part of it comes from Edwards curve arithmetic being cheaper per operation than Weierstrass curve arithmetic at the same security level. Neither algorithm is “slow” in absolute terms. Both handle tens of thousands of operations per second on a single CPU core, which is why the choice between them rarely comes down to raw throughput for typical SSH or TLS handshake volumes. It starts to matter at scale: a certificate authority issuing millions of signatures a day, or a blockchain validator verifying every transaction in a block within a tight slot window, feels a 1.5x-2x gap directly in infrastructure cost.
ECDSA P-384 trails both in throughput because its field arithmetic operates on 384-bit values instead of 256-bit values, which roughly triples the multiplication cost per operation. That’s the tradeoff for its higher 192-bit security margin, and it’s why P-384 shows up mostly in high-assurance government and defense contexts rather than general-purpose web infrastructure.
The nonce problem: why Sony’s PS3 signing key got extracted
The single biggest operational difference between these two algorithms isn’t speed or key size. It’s what happens when the random number generator behind the signature is weak, biased, or reused.
Standard ECDSA signing requires a fresh, unpredictable random number, called a nonce, for every single signature. If that nonce is ever reused across two different messages signed with the same private key, an attacker who observes both signatures can solve two linear equations for one unknown and recover the private key directly, no advanced cryptanalysis required. That’s exactly what happened to Sony in December 2010. The PlayStation 3’s firmware-signing implementation used ECDSA but failed to generate a fresh nonce for each signature, using a fixed or predictable value instead. The Fail0verflow research group and hacker George Hotz combined signatures from different pieces of signed firmware, solved for Sony’s private signing key, and published it. From that point forward, anyone could sign arbitrary code to run as trusted firmware on the console. Sony never designed a way to revoke and reissue that root key across already-shipped hardware.
Ed25519 was built specifically to make that failure mode structurally impossible. Instead of pulling a nonce from a random number generator, EdDSA derives it deterministically by hashing part of the private key together with the message being signed. Sign the same message with the same key twice, and you get the identical signature both times; there’s no external randomness step to fail. RFC 6979 later brought a similar deterministic-nonce approach to ECDSA as an optional variant, and FIPS 186-5 references it, but adoption depends entirely on whether a given library or device implements it. Plenty of ECDSA deployments in the field still use non-deterministic nonces, meaning the PS3-style failure mode remains a live risk wherever the underlying RNG can’t be trusted, think embedded devices, smart cards, and cheap IoT hardware with weak entropy sources.
This isn’t a purely historical concern. A 2025 security advisory for the widely used npm elliptic library documented a nonce-handling flaw in its ECDSA implementation (affecting versions up to 6.6.0) where malformed inputs could trigger equivalent internal representations for different messages, opening the door to the same style of private-key-recovery attack the PS3 suffered fifteen years earlier. The fix, shipped in version 6.6.1, added validation to guarantee a strict one-to-one mapping between messages and nonces. Ed25519 doesn’t eliminate implementation bugs entirely, its own ecosystem has had point-validation issues, but it removes an entire category of them by design.
Where each algorithm is actually required: SSH, TLS, WebAuthn, JWT
Theory aside, the two algorithms occupy very different territory depending on which protocol you’re implementing.
SSH: Ed25519 is now the default
OpenSSH changed its ssh-keygen default key type to Ed25519 and switched its first-preference signature algorithm from ECDSA to Ed25519 in recent release cycles, a shift documented in the project’s own changelogs. GitHub and GitLab both point new users toward Ed25519 in their SSH key documentation, reserving RSA-4096 as the fallback for legacy systems that can’t handle the newer key type. GitHub’s own security post on Git protocol changes describes a hard cutoff, RSA keys created after November 2, 2021 could no longer authenticate using SHA-1 signatures and had to use SHA-2 instead, part of a broader industry push away from older, weaker signature configurations. ECDSA never became the SSH default at either platform; Ed25519 effectively skipped past it.
TLS certificates: ECDSA dominates, Ed25519 stays niche
Flip to public-facing TLS and the picture reverses completely. Let’s Encrypt, by far the largest certificate authority by volume, issues RSA and ECDSA (P-256, P-384) certificates only. Ed25519 and X25519 are not offered as public-key algorithms for browser-trusted certificates from Let’s Encrypt or from most major commercial CAs, largely because the CA/Browser Forum’s Baseline Requirements haven’t added Ed25519 as an approved algorithm for public Web PKI certificates. OpenSSL has supported generating and signing Ed25519 X.509 certificates since version 1.1.1, but that capability mostly gets used for internal or private PKI, since neither Chrome nor Firefox will negotiate an Ed25519-signed certificate for ordinary HTTPS. If you’re issuing a public TLS certificate in 2026, ECDSA P-256 is the modern default, and Ed25519 isn’t on the table.
WebAuthn and FIDO2 security keys: ECDSA is mandatory
The W3C WebAuthn specification requires that FIDO2-compliant authenticators support ES256, ECDSA using curve P-256 with SHA-256, as the baseline signature algorithm (COSE algorithm identifier -7). EdDSA (COSE identifier -8) is registered in the same standard but remains optional, and most commercial hardware security keys on the market in 2026 implement ECDSA P-256 as their primary or only signing algorithm. Ed25519 support in FIDO2 authenticators is still spotty and vendor-specific. If you’re building anything that needs to work with the broadest possible set of existing hardware security keys, ECDSA is the algorithm your relying party needs to support, full stop.
JWT and JOSE: both live here, but adoption differs
In the JSON Object Signing and Encryption (JOSE) ecosystem that underlies most JWT-based auth systems, ES256 (ECDSA P-256 with SHA-256) is the long-established, broadly supported choice, and Okta’s own OAuth documentation for private_key_jwt client authentication lists RS256/384/512 and ES256/384/512 without mentioning EdDSA at all. EdDSA support does exist, RFC 8037 defines it, and libraries like Nimbus JOSE+JWT and Authlib implement Ed25519-based JWT signing, but production identity platforms still lean on ES256 as the safe, universally-compatible default. If interoperability with third-party identity providers is a requirement, ECDSA remains the path of least resistance in 2026, even though Ed25519 is technically available.
Git commit signing: SSH Ed25519 keys vs GPG RSA keys
Git added native SSH-based commit signing in version 2.34, giving developers an alternative to the older GPG workflow for proving a commit actually came from them. GitHub’s own documentation confirms you can sign commits locally using GPG, SSH, or S/MIME, and GitLab’s docs list ED25519, ED25519_SK, and RSA as supported SSH signing key types. The typical setup for SSH-based signing points user.signingkey at an Ed25519 public key rather than an RSA one, for the same speed and determinism reasons that drive the SSH authentication choice.
Adoption tells a more nuanced story than the tooling alone suggests. Academic research analyzing over 1.1 million signed commits found that roughly 98.9% used PGP keys (historically RSA-based) and only about 1.1% used SSH keys for signing, even though SSH signing has been available for several release cycles. The same research reported that both signature types were highly reliable in practice: 82% of PGP-signed commits and 90% of SSH-signed commits validated correctly. Separately, a GitHub dataset covering more than 71,000 active users found that roughly 89% had authored at least one signed commit at some point, though that’s a “used it once” figure, not a measure of what fraction of all commits get signed day to day. The takeaway: SSH signing with Ed25519 is real, it’s supported, and it’s growing, but GPG with RSA still dominates by sheer volume of already-signed history.
Library and language support: where each algorithm actually compiles
Neither algorithm is useful without a library that implements it correctly. Here’s how mainstream cryptographic libraries and language standard libraries stack up as of 2026.
| Library / runtime | Ed25519 support | ECDSA support | Notes |
|---|---|---|---|
| OpenSSL | Since 1.1.1 (2018) | Since 0.9.8 era | Both usable for X.509 certs; only ECDSA accepted by public Web PKI |
| libsodium | Core feature since inception | Not implemented | Ed25519-first library; no NIST curve ECDSA support by design |
| BoringSSL (Google) | Supported | Supported | Powers Chrome’s TLS stack; used for internal Google services |
| Go standard library | crypto/ed25519 package | crypto/ecdsa package | Both first-class in the standard library, no external dependency |
| Node.js | Native since Node 12+ (OpenSSL-backed) | Native, long-standing | Both exposed through the built-in crypto module |
| Python (cryptography package) | Supported | Supported | Both available via cryptography.hazmat.primitives.asymmetric |
The practical gap isn’t in mainstream server-side languages, both algorithms are well supported everywhere that matters. It shows up at the edges: older embedded toolchains, hardware security modules that shipped before Ed25519 existed, and FIPS-validated cryptographic modules where every algorithm addition requires a fresh validation cycle. A FIPS 140-3 security policy for one OpenSSL-based module explicitly lists Ed25519 and Ed448 among its approved algorithms, but that validation is specific to that module and version, not a blanket guarantee that “OpenSSL is FIPS-validated for Ed25519” everywhere it’s deployed. Check your specific compliance boundary before assuming support.
Cloud KMS and HSM pricing: what signing actually costs
If you’re offloading signing operations to a managed key service instead of handling keys yourself, the pricing structure matters more than the underlying algorithm’s raw speed. None of the three major cloud providers expose Ed25519 as a distinct pricing tier, since none of them support it as a key type in their primary KMS products, they bill EC and RSA operations instead. Here’s what that looks like as of 2026.
| Provider | Key type billed | Monthly key fee | Sign/verify cost |
|---|---|---|---|
| AWS KMS | RSA-2048 | $1.00 per key/month | ~$0.03 per 10,000 requests |
| AWS KMS | ECC (and RSA-3072/4096) | $1.00 per key/month | ~$0.15 per 10,000 requests |
| Azure Key Vault | RSA-2048 | $1.00 per key/month | ~$0.03 per 10,000 transactions |
| Azure Key Vault | ECC / RSA-3072/4096 (“advanced”) | $5.00 per key/month (first 250 keys) | ~$0.15 per 10,000 transactions |
| Google Cloud KMS | EC key versions | Billed hourly per active key version | Bundled into per-hour key version rate |
AWS KMS announced native Ed25519 (EdDSA) support on November 7, 2025, letting customers create asymmetric KMS keys or data key pairs specifically for Ed25519 signing and verification. AWS’s own announcement frames the appeal in terms directly relevant to this comparison: 128-bit security equivalent to NIST P-256, faster signing performance, and compact 64-byte signatures with 32-byte public keys, positioning it for IoT and blockchain workloads where every byte and every millisecond of signing latency counts. As of this writing, Azure Key Vault and Google Cloud KMS have not announced equivalent native Ed25519 support in their primary managed-key products, so a multi-cloud deployment that needs consistent EdDSA support across providers may need to fall back to self-managed HSMs or software-based signing (libsodium, OpenSSL) rather than relying on the cloud vendor’s KMS layer everywhere.
Real-world examples: who actually uses which algorithm
Abstract comparisons are easier to reason about with concrete deployments attached to them. Here are five production examples that illustrate how the choice plays out in practice.
- Bitcoin and Ethereum both sign transactions with ECDSA over the secp256k1 curve, a choice baked into both networks at launch and effectively frozen in place by the cost of a consensus-breaking signature scheme change across a live, high-value blockchain.
- Solana uses Ed25519 for every transaction signature; Solana’s own documentation specifies a fixed 64-byte Ed25519 signature per signer, and the network runs a dedicated “ed25519 program” precompile to batch-verify signatures efficiently inside its runtime.
- GitHub and GitLab both steer new users toward Ed25519 SSH keys in their documentation, while continuing to accept ECDSA and RSA-4096 for backward compatibility with older client tooling.
- Let’s Encrypt, which issues the majority of TLS certificates on the public internet by volume, signs certificates using RSA and ECDSA P-256/P-384 exclusively, with no Ed25519 option for browser-trusted certificates.
- AWS KMS added Ed25519 signing support in November 2025 specifically to serve IoT device fleets and blockchain integrations where AWS customers had been asking for smaller, faster signatures than RSA or standard EC keys could offer.
Migration guide: moving from ECDSA to Ed25519
If your infrastructure currently runs ECDSA and you’re considering a move to Ed25519, here’s a practical rollout sequence rather than a big-bang cutover, which is how most teams avoid locking themselves out of production systems.
- Audit where signatures are verified, not just where they’re generated. A key rotation only works if every downstream verifier can already parse the new signature format. Check load balancers, API gateways, mobile app binaries, and any hardcoded public keys before touching the signing side.
- Confirm library support across your stack. OpenSSL 1.1.1+, libsodium, Go’s standard crypto/ed25519 package, and most modern language runtimes support Ed25519 natively. Older systems, embedded firmware, or anything pinned to OpenSSL 1.0.x will need an upgrade first.
- Generate new Ed25519 keys in parallel, don’t convert existing ECDSA keys. The two algorithms use fundamentally different curve math; there’s no mathematical conversion from an ECDSA P-256 keypair to an equivalent Ed25519 keypair. You’re issuing new keys, not migrating old ones.
- Roll out dual-signing during the transition window. For SSH, add the Ed25519 public key alongside the existing ECDSA or RSA key in
authorized_keysrather than replacing it immediately. For JWT-issuing services, support both ES256 and EdDSA verification simultaneously while you migrate client SDKs. - Check compliance and FIPS module requirements before removing ECDSA. If you operate under FIPS 140-3 validation requirements, confirm your specific cryptographic module has completed Ed25519 validation. Not every FIPS-validated OpenSSL build supports Ed25519 yet, and pulling ECDSA support prematurely can break compliance attestations.
- Leave WebAuthn/FIDO2 authentication on ECDSA. Since ES256 is the mandatory baseline in the WebAuthn spec and most deployed hardware security keys only implement ECDSA, there’s no practical migration path here in 2026, this is one area where ECDSA stays put regardless of your preference elsewhere.
- Monitor for legacy client failures for at least one full release cycle before decommissioning ECDSA verification paths, since older SSH clients, outdated mobile app versions, and unpatched embedded devices are the most common source of migration breakage.
Ed25519 pros and cons
Pros: Deterministic signing eliminates the nonce-reuse failure class entirely, removing the exact bug class that doomed Sony’s PS3 signing key. Faster signing and verification than ECDSA P-256 across every benchmark source cited above. Fixed, compact 64-byte signatures and 32-byte keys simplify storage and bandwidth planning. Modern default for SSH across GitHub, GitLab, and OpenSSH itself. NIST-approved under FIPS 186-5 since February 2023, so it’s no longer an outsider algorithm from a standards perspective.
Cons: Not supported for browser-trusted TLS certificates by Let’s Encrypt or the CA/Browser Forum Baseline Requirements. Optional, not mandatory, in WebAuthn/FIDO2, so most hardware security keys don’t implement it. Weaker support across identity platforms and JWT tooling compared to the well-established ES256. Not yet universally available in every cloud KMS (Azure and GCP lag AWS here). Offers no quantum resistance, same as ECDSA, so it’s not a forward-looking choice against a cryptographically relevant quantum computer.
ECDSA pros and cons
Pros: Mandatory baseline in WebAuthn/FIDO2 (ES256), so it works with essentially every hardware security key on the market. Universal support in public TLS certificates via Let’s Encrypt and every major commercial CA. Longest track record of the two, standardized since FIPS 186-3 in 2009. Broadest JWT/JOSE ecosystem support, including identity platforms like Okta that don’t yet document EdDSA support. Backs the two largest blockchain networks by market capitalization, Bitcoin and Ethereum, via secp256k1.
Cons: Requires a high-quality random nonce for every signature; a weak, biased, or reused nonce directly exposes the private key, as Sony’s PS3 signing key demonstrated in 2010. Slower than Ed25519 for both signing and verification across every benchmark cited here. DER-encoded signatures carry variable-length overhead compared to Ed25519’s fixed 64-byte format. Deterministic ECDSA via RFC 6979 exists but isn’t universally implemented, so the nonce-reuse risk persists in many real deployments. No longer the default choice for new SSH keys at GitHub, GitLab, or in OpenSSH itself.
5 use cases and which algorithm fits
- New SSH key for a developer or server: Ed25519. It’s the modern default across GitHub, GitLab, and OpenSSH, faster to generate, faster to use, and immune to the nonce-reuse failure class.
- Public-facing TLS certificate for a website: ECDSA P-256. Let’s Encrypt and every major CA issue it, and every browser supports it; Ed25519 simply isn’t an option here yet.
- FIDO2 hardware security key deployment for enterprise login: ECDSA P-256 (ES256). It’s the mandatory WebAuthn baseline, and most keys your employees already own only implement this algorithm.
- IoT device fleet or blockchain wallet signing: Ed25519. Its compact 32-byte keys and 64-byte signatures reduce bandwidth and storage on constrained hardware, and AWS KMS explicitly built its November 2025 EdDSA support with this use case in mind.
- JWT-based API authentication integrating with a third-party identity provider: ECDSA (ES256), unless you’ve confirmed every party in the chain, including the identity provider, supports EdDSA. ES256 remains the safer interoperability default in 2026.
Common migration mistakes to avoid
A handful of mistakes show up repeatedly when teams move between these two algorithms. The first is assuming key conversion is possible, it isn’t. Ed25519 and ECDSA use different curve math entirely, so you generate new keys rather than converting old ones. The second is pulling ECDSA support before confirming every client and every verifier in the chain has been upgraded, which tends to lock out exactly the legacy device or outdated mobile app version nobody remembered still existed. The third is trying to force Ed25519 into a WebAuthn or public TLS deployment where the surrounding ecosystem, browsers, certificate authorities, and hardware security keys, simply doesn’t support it yet, regardless of how compelling the performance numbers look on paper. The fourth is confusing signing keys with encryption keys. Ed25519 is a signature algorithm, and Diffie-Hellman key exchange on the same underlying curve family uses the separate X25519 function, related but not interchangeable.
Quick decision matrix
If you just need the short answer for a specific protocol, here it is in one table.
| Context | Use this | Why |
|---|---|---|
| New SSH key | Ed25519 | OpenSSH, GitHub, and GitLab default here now |
| Public TLS certificate | ECDSA P-256 | Ed25519 not issued by Let’s Encrypt or accepted by browsers |
| FIDO2/WebAuthn login | ECDSA P-256 (ES256) | Mandatory baseline; most hardware keys only support this |
| Git commit signing | Ed25519 (via SSH) or RSA (via GPG) | Both work; Ed25519 is faster but GPG/RSA still dominates by volume |
| JWT for third-party identity integration | ECDSA (ES256) | Broadest support across Okta and other identity platforms |
| IoT device or blockchain signing | Ed25519 | Smaller keys/signatures, faster ops, AWS KMS support since Nov 2025 |
| FIPS 140-3 regulated environment | Verify your specific module first | ECDSA has broader FIPS-validated coverage; Ed25519 validation is module-specific |
The verdict: which one should you actually use
There’s no single winner here because the two algorithms occupy different, largely non-overlapping territory in 2026’s cryptographic stack. Ed25519 wins decisively on SSH keys (the modern default at GitHub, GitLab, and OpenSSH), on raw performance (1.5x to 2x faster than ECDSA P-256 across every benchmark cited above), and on implementation safety (deterministic signing structurally rules out the nonce-reuse bug that cost Sony its PS3 signing key). If you’re generating a new SSH keypair, building an IoT signing pipeline, or working with a blockchain that already uses EdDSA like Solana, Ed25519 is the better default, full stop.
ECDSA P-256 wins where standards mandate it or where ecosystem breadth matters more than raw speed: public TLS certificates, FIDO2 hardware security keys, and JWT-based identity systems that need to interoperate with platforms like Okta that haven’t documented EdDSA support. Both algorithms sit on equal footing at NIST, both were approved in the same FIPS 186-5 document in February 2023, and neither survives a cryptographically relevant quantum computer. The honest answer for most teams building new infrastructure in 2026 is to default to Ed25519 wherever the surrounding ecosystem allows it, and fall back to ECDSA P-256 only where a standard, a piece of hardware, or a third-party integration specifically requires it.
Frequently asked questions
Is Ed25519 more secure than ECDSA?
At the 128-bit security level, Ed25519 and ECDSA P-256 offer comparable cryptographic strength against brute-force attacks. Ed25519’s real security advantage is operational: its deterministic nonce generation removes the entire class of private-key-exposure bugs that come from weak or reused random numbers in ECDSA, the exact failure that let researchers extract Sony’s PS3 signing key in 2010.
Can I use Ed25519 for a public HTTPS certificate?
No. Let’s Encrypt and other public certificate authorities issue only RSA and ECDSA certificates for browser-trusted HTTPS, because the CA/Browser Forum’s Baseline Requirements don’t yet include Ed25519 as an approved algorithm, and neither Chrome nor Firefox will negotiate Ed25519-signed TLS certificates for ordinary web traffic.
Why did OpenSSH switch its default from RSA and ECDSA to Ed25519?
OpenSSH’s own release notes cite Ed25519’s smaller key and signature sizes, faster signing and verification, and its deterministic, side-channel-resistant design as the reasons for making it the default key type in ssh-keygen and the first-preference signature algorithm in recent releases.
Does Ed25519 work with FIDO2 security keys?
Sometimes, but not reliably. The WebAuthn specification registers EdDSA as COSE algorithm -8, but ES256 (ECDSA P-256) is the only mandatory baseline algorithm under FIDO2. Most commercial hardware security keys implement ECDSA as their primary or only signing algorithm, and Ed25519 support varies by vendor and model.
Is Ed25519 quantum-resistant?
No. Ed25519 relies on the elliptic curve discrete logarithm problem, the same mathematical foundation as ECDSA, which Shor’s algorithm breaks on a sufficiently powerful quantum computer. Neither algorithm offers post-quantum security. NIST’s ML-DSA and SLH-DSA are the standardized replacements for signature use cases that need quantum resistance.
Which blockchains use Ed25519 instead of ECDSA?
Solana uses Ed25519 for all transaction signatures, with a dedicated on-chain program to batch-verify them efficiently. Bitcoin and Ethereum, the two largest blockchains by market capitalization, use ECDSA over the secp256k1 curve instead, a design decision made at each network’s launch that would require a consensus-breaking change to alter.
Can I convert an existing ECDSA key to Ed25519?
No. The two algorithms use different underlying curve math (Weierstrass versus twisted Edwards), so there’s no mathematical transformation from one keypair to the other. Migrating means generating a brand-new Ed25519 keypair and distributing the new public key to every verifier, not converting the old one.
Does AWS support Ed25519 in its managed key service?
Yes, as of November 7, 2025, AWS KMS supports Edwards-curve Digital Signature Algorithm (EdDSA) with the Ed25519 curve, letting customers create KMS keys or data key pairs specifically for Ed25519 signing and verification. Azure Key Vault and Google Cloud KMS had not announced equivalent native Ed25519 support in their primary offerings as of this writing.
