ECDSA vs EdDSA: Choosing the Right Signature Algorithm for Each Key

ECDSA and EdDSA both give you small, fast elliptic curve signatures, but they fail in different ways and are accepted in different places, so picking one by habit leaves keys exposed or certificates rejected. ECDSA on the NIST P-curves is what public certificate authorities issue and what most FIPS-validated hardware signs with. EdDSA, usually Ed25519, removes the per-signature randomness that has leaked ECDSA keys in real products, and it is the modern default for SSH. This guide compares the two algorithm by algorithm: threat model, how each one works, how each one breaks, the controls that matter, and which to pick for TLS certificates, SSH, code and artefact signing, tokens and email. For curve mathematics and the wider ECC picture, start with the Elliptic Curve Cryptography guide; this page goes deeper on the choice between the two signature schemes.

Key takeaways

• Short answer: use ECDSA P-256 (or P-384) wherever a public CA, a browser or a FIPS-validated module is in the path, and Ed25519 where you control both signer and verifier, such as SSH, internal signing and DKIM alongside RSA.
• The nonce is the real difference. Classic ECDSA needs a fresh secret per signature and leaks the private key if that value repeats or is biased; EdDSA derives it deterministically, and RFC 6979 gives ECDSA the same property without changing verifiers.
• Public WebPKI is ECDSA-only for EC keys. The CA/Browser Forum Baseline Requirements and the Mozilla Root Store Policy allow ECDSA on P-256, P-384 and P-521; Mozilla lists Curve25519 and Curve448 as not currently supported for server certificates.
• Verification rules matter as much as signing. EdDSA verifiers must reject non-canonical S values, and protocols now prefer fully specified algorithm identifiers (COSE Ed25519 and ESP256) over the older polymorphic EdDSA and ES256 labels.
• Both are on the same quantum clock. ECDSA and EdDSA are equally exposed to a large quantum computer, so the choice between them should never delay planning for ML-DSA or SLH-DSA.

The short answer and the comparison at a glance

Most organisations end up running both algorithms. The decision is per key population, not per company, and it is driven more by who must verify the signature than by raw security: at the 128-bit level both are strong when implemented well.

ECDSA in depth: threat model, architecture and failure modes

How it works, in words

An ECDSA private key is a number d; the public key is the curve point d times the base point G. To sign, the signer picks a secret per-signature value k, computes the point k times G, takes its x-coordinate modulo the group order as r, and combines r, the message hash and d into s. The pair (r, s) is the signature, usually DER-encoded in X.509 and TLS and raw-concatenated in JOSE and COSE. Verification uses only the public key. Everything about ECDSA's security depends on k staying secret, unique and uniformly random, or being derived deterministically as RFC 6979 specifies.

Threat model

• Nonce reuse or bias: two signatures with the same k reveal d with simple algebra; even a small, consistent bias across many signatures allows lattice-based recovery. The attacker needs only public signatures and the public key.
• Weak randomness at signing time: cloned virtual machines, embedded devices at first boot and broken random number generators produce predictable k values.
• Side channels: timing or power leakage of k during scalar multiplication. RFC 6979 notes that determinism may help some side-channel attacks and says implementations should use defensive measures.
• Verifier mistakes: accepting explicit curve parameters or unvalidated points, the class of bug behind CVE-2020-0601 described in the Elliptic Curve Cryptography guide.

Failure mode in practice: biased nonces in an SSH client

CVE-2024-31497 is the clearest recent lesson. PuTTY 0.68 to 0.80 generated ECDSA nonces deterministically by hashing with SHA-512 and reducing modulo the group order. For P-521 the order is longer than 512 bits, so the reduction did nothing and the top 9 bits of every k were zero. The PuTTY advisory estimates that around 60 signatures plus the public key are enough to recover the private key. Version 0.81 moved all DSA and ECDSA keys to RFC 6979, but that does not undo leakage: the project's advice is to revoke every P-521 key ever used with PuTTY or Pageant, remove it from authorized_keys files and generate a new pair. Ed25519 keys and other ECDSA sizes were not affected. The lesson: home-grown nonce derivation is a key-exposure risk, and fixing the code never fixes keys already leaked.

Controls that make ECDSA safe

• Deterministic or hedged k: require RFC 6979 (or a validated module's approved method) for every software signer. Signatures stay compatible with any ECDSA verifier.
• Keys in validated hardware: HSMs, TPMs and cloud KMS keep k generation inside a tested boundary. See the HSM Deployment and Operations Guide.
• Low-s normalisation where malleability matters: if signatures are used as identifiers (transaction IDs, deduplication keys), require the low-s form or hash the message instead of the signature.
• Named curves only: verifiers accept only P-256, P-384 and P-521 by OID, matching the encodings the Mozilla policy lists.

EdDSA in depth: threat model, architecture and failure modes

How it works, in words

EdDSA hashes the 32-byte seed (for Ed25519) to produce both the signing scalar and a secret prefix. For each message it hashes that prefix with the message to get the nonce r, computes R = rB, then computes S from a hash of R, the public key and the message. The signature is R followed by S, 64 octets for Ed25519. Because the nonce depends only on the secret and the message, signing needs no randomness at all, which RFC 8032 section 8.2 presents as protection against weak random number generators during signing. Key generation still needs good randomness.

Threat model

• Verifier disagreement: RFC 8032 requires verifiers to reject S values not below the group order L, otherwise a second valid signature can be made by adding L. It also explains cofactored and cofactorless verification: the cofactored equation keeps implementations agreeing on exactly which signatures are valid. Libraries that differ here can split consensus in systems that compare signatures across nodes.
• Side channels and faults: RFC 8032 section 8.1 asks for constant-time execution and notes that its own example code does not provide it. Deterministic schemes are a known target for fault injection on hardware an attacker can touch, so smart cards and embedded signers need countermeasures from the vendor.
• Variant confusion: RFC 8032 recommends against the prehashed variants Ed25519ph and Ed448ph, and asks that contexts be constant protocol strings rather than used opportunistically. RFC 8410 covers only the pure variants for X.509.
• Ecosystem gaps: the risk most teams hit is operational: a verifier, HSM or CA that rejects Ed25519 forces a less tested fallback key, often held in software and never rotated. Decide the verifier set before the algorithm.

Controls that make EdDSA safe

• Strict, well-reviewed libraries: require canonical S checks and a documented verification equation; never implement curve arithmetic in application code.
• Fully specified identifiers: in COSE use Ed25519 (-19) rather than the polymorphic EdDSA (-8) value, which the IANA registry now marks deprecated with a reference to RFC 9864.
• Separate keys by purpose: RFC 8032 says one key can be used across Ed25519, Ed25519ctx and Ed25519ph without trivial collisions, but key hygiene still argues for one key per protocol and per environment so revocation stays simple.

Standards, CA support and FIPS status

FIPS nuance: an algorithm being in FIPS 186-5 is not the same as your HSM or library being validated for it. Check the module's FIPS 140-3 certificate and security policy for EdDSA before writing a policy that depends on it. See the FIPS 140-3 and Cryptographic Module Validation Guide and, for Linux hosts, the Linux System-Wide Crypto Policies and FIPS Mode Guide.

Choosing per use case

For each population, the deeper guides are the SSH Key Management Guide, the Code Signing Security Guide, the JWT Security Guide, the DMARC, SPF and DKIM Guide and the FIDO2 and WebAuthn Internals Guide.

Worked scenario: one company, three key populations

A mid-sized software company runs a public website, a Kubernetes platform with internal mTLS, about 4,000 engineer and automation SSH keys, and signs container images and a desktop agent.

1. Public site: it moves from RSA-2048 to an ECDSA P-256 certificate from its public CA, keeping an RSA certificate configured for old clients for one quarter while it watches handshake failures. Ed25519 is not an option here because public CAs do not issue it.
2. Internal mTLS: the private CA could issue Ed25519 leaves, but two network appliances and a legacy Java service fail to parse RFC 8410 keys in testing. The team standardises on ECDSA P-256 with keys in the cloud KMS, and records Ed25519 as a future option once the appliances are replaced.
3. SSH: new keys are Ed25519 by policy. An inventory finds 37 P-521 keys historically used with PuTTY; all are revoked and replaced under the CVE-2024-31497 advice, and the remaining ECDSA keys are left to rotate naturally. Bastion hosts in a FIPS enclave keep ECDSA P-256 host keys because the validated module there does not list EdDSA.
4. Signing: image and agent signatures stay on ECDSA P-256 in an HSM because the customer-side verifiers are fixed. The agent's verifier goes into the post-quantum inventory, since deployed verifiers are the slowest to change.

Post-quantum migration context

Switching between ECDSA and EdDSA does not change quantum risk: both rely on the elliptic curve discrete logarithm problem. NIST IR 8547, final in October 2026, sets out the deprecation and disallowance of these quantum-vulnerable signatures; the dates and federal milestones are tracked in the Post-Quantum Cryptography Deadlines Tracker.

• Do not run a classical-to-classical migration for its own sake. Moving a large estate from ECDSA to Ed25519 only for "better crypto" spends the change budget you will need for ML-DSA.
• Use the choice to build agility. Supporting two signature algorithms cleanly (algorithm pinning per key, inventory of key type, tested rotation) is the same capability you need for a post-quantum or composite signature. See the Crypto-Agility Guide.
• Long-lived verifiers first. Firmware, boot chains and code-signing roots have the longest lead time. See the ML-DSA and SLH-DSA Post-Quantum Signatures Guide and the PQC Code Signing Guide. On SSH, OpenSSH 10.0 already uses the hybrid mlkem768x25519-sha256 key agreement by default, but its signatures (host and user keys) remain classical; see the PQC SSH Migration Guide.

Where identity fits

Almost every ECDSA or Ed25519 private key in an estate belongs to a non-human identity: a server's TLS key, a workload's mTLS certificate, a deploy key, a CI signer, an automation account's SSH key. The algorithm choice is therefore an identity governance input. Record the algorithm and curve as an attribute of each machine identity, tie each key to an owner, and treat algorithm exceptions (a software-held ECDSA key next to an HSM-held Ed25519 key) as entitlements that need review. Theft of these keys maps to ATT&CK T1552.004 Private Keys, and misuse of a stolen signing key to T1553.002 Code Signing. See the Post-Quantum Migration for NHIs Guide.

Rolling out an algorithm policy

1. Inventory: list every signing key and certificate with algorithm, curve, storage location, owner and verifier set, using scans of certificates, SSH authorized_keys files and KMS key lists. See the Cryptographic Inventory and CBOM Guide.
2. Write the policy: allowed algorithms per use case (the table above is a starting point), required nonce method for ECDSA (RFC 6979 or validated hardware), banned items (P-192, binary curves, DSA, prehashed EdDSA unless a protocol mandates it).
3. Test verifiers before signers: stand up a test CA or signing key in the new algorithm and run it against every relying party, appliance and library version in a staging ring.
4. Pilot one population: new SSH keys or one internal service; measure failures and support tickets for two to four weeks.
5. Enforce for new keys only: configure CAs, KMS key policies and SSH key generation tooling to reject disallowed types; let existing keys rotate on schedule.
6. Roll back: keep the previous algorithm's certificate or key available and re-enable it per service if handshake or verification failures exceed the agreed threshold; record each rollback as a time-limited exception.

Small and large organisations: a small team can adopt platform defaults (Ed25519 for SSH, ECDSA P-256 from its public CA and cloud KMS) and focus on inventory and patching. A large organisation needs certificate linting in the issuing CA, key-type controls in KMS policy and an exception register reviewed by the PKI owner.

Detection and measurement

• Repeated r values: where signatures are logged (signing services, transparency logs), alert on any repeated ECDSA r value for the same key; one repeat means the key is exposed.
• Library and tool versions: track signer software against advisories such as CVE-2024-31497, and flag keys used with affected versions for rotation, not just patching.

Common failure patterns

• Patching the signer but not rotating the key: after a nonce bug, the leaked signatures are already public; only revocation and replacement close the exposure, as the PuTTY advisory makes explicit.
• Choosing Ed25519 for a public certificate: it fails at issuance or in clients; root programme policy, not cryptography, decides this.
• Trusting the algorithm header: JWT or COSE verifiers that accept whatever algorithm the message names invite downgrade and confusion; pin the algorithm per key.
• Assuming FIPS 186-5 means your module is approved: EdDSA in the standard does not mean EdDSA in your validated module's certificate.
• Lax EdDSA verification: skipping the canonical S check allows malleable signatures, which matters wherever signatures act as identifiers.

Framework mapping

Practitioner checklist

• Inventory every signing key with algorithm, curve, storage, owner and verifier set.
• Publish a per-use-case algorithm policy: ECDSA P-256 or P-384 for public TLS and FIPS paths, Ed25519 where all verifiers support it.
• Require RFC 6979 or validated hardware nonce generation for every ECDSA signer.
• Require canonical S checks in EdDSA verifiers and low-s handling where ECDSA signatures act as identifiers.
• Pin the expected algorithm per key in token and signature verifiers.
• Confirm EdDSA appears in your HSM or library's FIPS 140-3 certificate before relying on it in a FIPS context.
• Revoke and replace, not just patch, any key used with a signer later found to leak nonces.
• Record a post-quantum path for every long-lived verifier, starting with firmware and code-signing roots.

Standards and references

• NIST: FIPS 186-5 Digital Signature Standard
• IETF: RFC 8032 Edwards-Curve Digital Signature Algorithm (EdDSA)
• IETF: RFC 6979 Deterministic Usage of DSA and ECDSA
• IETF: RFC 8410 Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for Use in the Internet X.509 PKI
• IETF: RFC 8709 Ed25519 and Ed448 Public Key Algorithms for SSH
• CA/Browser Forum: Baseline Requirements for TLS Server Certificates
• Mozilla: Root Store Policy
• NIST: IR 8547 Transition to Post-Quantum Cryptography Standards

Related NHI Mgmt Group resources: Elliptic Curve Cryptography · Digital Signatures Guide · SSH Key Management Guide · Post-Quantum Cryptography Migration Guide