Ed25519 vs ECDSA

Compare the two dominant elliptic-curve signature families — EdDSA/Ed25519 over an Edwards curve and ECDSA over NIST curves — across nonce handling, malleability, performance and curve trust, and decide which fits an agent system.

Track

Fundamentals

Module

2 · Applied cryptography for agents

Prerequisites

Digital signatures · Public-key cryptography

Both ECDSA and Ed25519 produce short signatures from an elliptic-curve key pair, and both are widely deployed and standardized. The differences are not about raw security level — both target ~128-bit security — but about engineering safety: how the nonce is generated, whether signatures are malleable, how the curve was chosen, and how easy each is to implement without catastrophic footguns. For an agent system, where signing authority is the backbone, those engineering differences matter more than a benchmark.

The headline design split is how each scheme generates the per-signature nonce (the secret random value, sometimes called k or r).

ECDSA — random nonce

Each signature needs a fresh, uniformly random secret nonce k. If k is ever reused across two signatures, or even slightly biased/predictable, the private key can be recovered algebraically. This has caused real-world key compromises.

Ed25519 — deterministic nonce

The nonce is derived by hashing (a secret prefix of the key || the message), so it is unique per message with no randomness needed at signing time. There is nothing to reuse and nothing to bias.

Malleability

ECDSA signatures are malleable: from a valid (r, s) an attacker can compute a second valid (r, L−s) on the same message without the key. Ed25519 mandates a canonical encoding with range checks, so it is non-malleable.

Placing the two sign operations side by side shows where the risk lives. In ECDSA the nonce k is an independent secret per signature; in Ed25519 it is a deterministic hash.

ECDSA vs Ed25519 signing (schematic)
# --- ECDSA over a curve of order n, private key d, generator G ---
Sign(d, m):
  k = random in [1, n-1]        # MUST be unique & unbiased, else key leaks
  R = k*G ;  r = R.x mod n
  s = k^-1 * (H(m) + r*d) mod n
  signature = (r, s)            # (r, n-s) is also valid  -> malleable

# --- Ed25519 over edwards25519, order L, secret scalar a, prefix ---
Sign(a, prefix, M):
  r = H(prefix, M)              # deterministic nonce, no RNG needed
  R = r*B
  s = (r + H(R, A, M)*a) mod L
  signature = (R, s)            # canonical encoding, range-checked -> non-malleable

The ECDSA key-recovery risk is concrete: with two signatures sharing the same k, the two s-equations have only two unknowns (k and d) and solve directly for d. Even a few leaked bits of many nonces suffice via lattice attacks. RFC 6979 specifies deterministic ECDSA (derive k by HMAC from the key and message) to neutralize this — worth using if you are stuck with ECDSA.

1. 1Default to Ed25519 for new internal agent-to-agent and control-plane signing: deterministic nonces remove the most dangerous footgun, encoding is non-malleable, and verification is simple and fast.
2. 2Choose ECDSA (P-256) when you must interoperate with an ecosystem that mandates it — many TLS/PKI stacks, hardware HSMs, secure enclaves, government (FIPS) procurement, or existing certificate chains.
3. 3If you use ECDSA, insist on RFC 6979 deterministic nonces (or a vetted RNG), and add an explicit low-s / canonical-signature check to kill malleability.
4. 4If an external identifier or chain must be unique per message (e.g. a transaction hash), never let malleability change that identifier; bind it to non-malleable fields or use Ed25519.
5. 5Whichever you pick, keep the private key in a KMS/HSM, pick one scheme per trust domain, and apply domain separation so a signature cannot cross contexts.

synthetic — malleability breaking an id assumption
# A system that dedupes signed orders by hashing the WHOLE signed blob:
order_id = SHA256( msg || sig )

# With ECDSA, attacker takes a legitimately signed (msg, (r,s))
sig2 = (r, L - s)                 # still verifies, no key needed
order_id2 = SHA256( msg || sig2 ) # DIFFERENT id for the SAME order
# -> the "already processed" check is bypassed; order replays once more.

# Fixes: dedupe by a key inside msg (a nonce), not the signature bytes;
#        enforce low-s canonical form; or use Ed25519 (non-malleable).

This is the classic malleability pitfall: the signature verifies honestly, but a system that derived an identity or uniqueness key from the raw signature bytes is fooled. The defect is in trusting malleable bytes, and it disappears when uniqueness is bound to fields the signer actually controls, or when the scheme is non-malleable.

In an agent fleet, signing is a hot path on the authorization boundary: a control plane signs intents, workers verify them, and audit records are signed. Ed25519 fits this well — fast verification, small 64-byte signatures and 32-byte public keys, deterministic signing that needs no entropy source inside a constrained worker, and non-malleable signatures that make "dedupe/replay by signature" bugs structurally impossible. ECDSA remains the right call when agents must present certificates or terminate TLS in an ecosystem that expects P-256, or when keys live in an HSM that only speaks ECDSA. Many real systems run both: Ed25519 for internal signed authority, ECDSA where external PKI dictates it.

• ▸ECDSA with a reused or biased nonce leaks the private key outright — a repeatedly exploited failure. Use RFC 6979 deterministic nonces if you cannot switch schemes.
• ▸ECDSA malleability breaks any logic that treats the raw signature bytes as a unique identifier; enforce canonical low-s form and bind uniqueness to in-message fields.
• ▸Curve trust differs: the NIST P-curves have unexplained seed constants that have drawn scrutiny, while Curve25519 was designed with public, rigidity-oriented criteria. This is about provenance/confidence, not a known break of the NIST curves.
• ▸Ed25519 has interoperability edge cases — strict vs cofactored verification and historically inconsistent acceptance of non-canonical encodings across libraries; pin a library that follows RFC 8032 and test cross-implementation.
• ▸Both are classical ECC and fall to a large-enough quantum computer; neither is post-quantum. Plan migration to standardized PQ signatures (e.g. ML-DSA / SLH-DSA) over the long term.
• ▸A correct signature in either scheme authenticates bytes, not judgement — it never proves the authorized action was wise or safe.

Expected direction: First, mandate RFC 6979 deterministic nonce generation (or a well-vetted RNG) — this prevents private-key recovery from reused or biased nonces. Second, enforce a canonical / low-s signature check on verify — this prevents signature malleability from producing a second valid signature that bypasses dedup/replay logic. (Bonus: keep the key in an HSM and apply domain separation.)

What is the single most dangerous footgun in ECDSA, and how does Ed25519 avoid it?

A reused or biased random nonce k leaks the private key. Ed25519 derives the nonce deterministically by hashing the key prefix and message, so there is no randomness to reuse or bias.

What does signature malleability mean for ECDSA, and why can it matter?

From a valid (r, s) anyone can compute another valid (r, n−s) on the same message without the key. It matters when a system keys identity/uniqueness off the raw signature bytes, allowing a second "distinct" but equivalent signature.

When is ECDSA still the appropriate choice over Ed25519?

Mainly for interoperability: existing TLS/PKI certificate chains, FIPS procurement, or HSMs/enclaves that mandate NIST curves like P-256.