Ed25519 vs ECDSA: Why the Nonce Decides Everything

Ed25519 vs ECDSA: Why the Nonce Decides Everything

Tópico: Ed25519 vs ECDSA: Why the Nonce Decides Everything
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
ECDSA and Ed25519 both sign data with elliptic curves, and both produce a 64-byte signature that verifies in a fraction of a millisecond. The difference between them is almost invisible on paper: ECDSA needs a fresh secret random number for every signature, and Ed25519 computes that number instead. That one design choice is the reason real people have lost real private keys.

A digital signature answers a narrow question: did the holder of a specific private key approve this exact message? It is what proves a software update came from its author, what binds a TLS certificate to a domain, and what authorizes a Git commit or an SSH login. Get the math wrong and the signature still verifies, so the failure is silent until someone extracts the key from the signatures themselves.

ECDSA (the Elliptic Curve Digital Signature Algorithm) and Ed25519 are the two schemes you meet most often. Understanding where they differ is less about the curves they run on and more about a single value that ECDSA calls k.

The value that must never repeat

To make an ECDSA signature you pick a per-signature secret number, usually written k and often called the nonce. You multiply it by the curve's base point, take a coordinate of the result, and combine it with a hash of the message and your private key to produce the two halves of the signature, r and s.

The rule is absolute: k must be unique and unpredictable for every signature you ever make with a given key. Break that rule and the algebra unravels. If two signatures reuse the same k, an observer who sees both can solve two equations for the one unknown and recover your private key with arithmetic a pocket calculator could handle. The signatures do not have to be on the same message. They just have to share a nonce.

The core failure. An ECDSA nonce is not a public parameter you can be sloppy with. It is as sensitive as the private key itself. Reuse it once, or generate it predictably, and the key is exposed to anyone holding the signatures.

When the rule was broken in public

This is not a theoretical footgun. Two of the most cited key-recovery incidents in modern security both trace back to a bad k.

In 2010, at the 27th Chaos Communication Congress, the group fail0verflow demonstrated that Sony had signed PlayStation 3 firmware using ECDSA with a constant nonce. The same k appeared on every signature. From two signed messages, the private key that authorized code for the entire console was recoverable. Sony could not fix it by rotating the key on shipped hardware, because the value was baked into the trust chain.

In August 2013, developers discovered that a flaw in Android's SecureRandom implementation could produce repeated output. Bitcoin wallets on affected devices signed transactions with ECDSA, and when two transactions reused a nonce, the signing key was exposed. Coins were stolen directly from the affected addresses. The Bitcoin project issued a security advisory and wallets were patched, but the underlying lesson was old: your signature scheme is only as strong as your random number generator on its worst day.

A cryptosystem that fails when the random number generator hiccups is a cryptosystem that will eventually fail, because random number generators hiccup.

Two ways to make the nonce safe

There are two answers to the nonce problem, and they define the split between modern ECDSA and Ed25519.

The first answer keeps ECDSA but stops trusting the RNG. RFC 6979 specifies deterministic ECDSA: instead of drawing k from a random source, you derive it by running an HMAC construction over the message and the private key. The output is unpredictable to anyone without the key, unique per message, and completely reproducible. No entropy is consumed at signing time, so a broken RNG can no longer leak the key. Well-maintained ECDSA libraries default to this today.

The second answer is to design the scheme so the nonce is deterministic from the start. Ed25519, standardized in RFC 8032, is EdDSA over a twisted Edwards form of Curve25519. Its nonce is derived by hashing the private key material together with the message using SHA-512. There is no random k to reuse and no RNG in the signing path at all. The property that ECDSA had to bolt on with RFC 6979 is native to Ed25519.

Where Ed25519 pulls ahead

Deterministic nonces are the headline, but Ed25519 was engineered to remove several other classes of mistake at once.

Property
ECDSA (NIST P-256)
Ed25519

Per-signature nonce
Random, unless RFC 6979 is used
Deterministic by design

Side-channel resistance
Needs careful constant-time coding
Complete addition formulas, no secret-dependent branches

Signature malleability
Malleable (both s and its negation verify)
Canonical encoding, non-malleable

Key and signature size
32-byte key, 64-70 byte signature (DER)
32-byte key, fixed 64-byte signature

Curve provenance
NIST seed with unexplained origin
Rigid, publicly justified parameters

The side-channel point is easy to underrate. ECDSA on the NIST curves can be implemented safely, but the safe path requires constant-time scalar multiplication and careful handling of the modular inverse. Ed25519's curve arithmetic uses complete addition formulas that work for every input, so there are no special cases and no secret-dependent branches for a timing attack to read. The scheme makes the safe implementation the natural one.

Malleability matters for systems that hash the signature itself. ECDSA's s and its negation both verify, so an attacker can flip a valid signature into a different valid signature for the same message. This is what drove early Bitcoin transaction-malleability problems. Ed25519 pins a single canonical form, closing that door.

So why does anyone still use ECDSA?

Because the ecosystem moves slowly and ECDSA got there first. NIST standardized the P-256, P-384, and P-521 curves years before Ed25519 existed, and those curves are written into a long list of compliance regimes, hardware security modules, smartcards, and government procurement rules. If you need a FIPS-validated module or you are issuing certificates into an old public key infrastructure, ECDSA is often the only option on the menu.

There is also a lingering distrust of the NIST curves themselves. Their parameters were generated from a seed whose origin was never fully explained, which sits uncomfortably next to the Dual EC DRBG episode, where a NIST-blessed random generator turned out to have a plausible backdoor. Curve25519 was designed in the open with every parameter choice justified against published safety criteria, which is a large part of why it spread through the tools that got to choose freely.

Choosing in practice

For anything new where you control both ends, Ed25519 is the straightforward pick. It is fast, small, hard to misuse, and supported by OpenSSH, TLS 1.3, modern signing tools, and most current language libraries. When you must interoperate with a system that only speaks ECDSA, use a library that implements RFC 6979 deterministic nonces and constant-time arithmetic, and verify that it does rather than assuming.

The deeper takeaway generalizes past these two schemes. A good cryptographic design does not merely permit correct use. It removes the ways to be wrong. ECDSA trusted the caller to supply a perfect nonce every time, and that trust was misplaced often enough to fill conference talks. Ed25519 took the decision away. When you evaluate any primitive, the question worth asking is not only whether it can be used securely, but whether it can be used insecurely, and how easily.

Originally published at havenmessenger.com