Cryptography

Schnorr Signatures: A Cleaner Path Than ECDSA

July 22, 2026 10 min read Haven Team

For most of the 1990s and 2000s, a patent kept one of the simplest digital signature schemes out of the mainstream. The industry built ECDSA partly to route around it. The patent expired in 2008, and in 2021 Bitcoin's Taproot upgrade adopted Schnorr signatures directly. It is worth understanding what the detour cost, and why the older design keeps coming back.


Claus Schnorr described his signature scheme in the late 1980s and patented it (US patent 4,995,082). It was clean, provably secure under standard assumptions, and easy to reason about. It was also encumbered. The US government wanted a royalty-free standard, so NIST built DSA around the same discrete-log math while steering clear of Schnorr's specific claims. When elliptic curves became practical, ECDSA inherited that lineage. The result is that the world's most deployed signature algorithm carries design decisions made to avoid a patent, not to be the best available answer.

What a signature has to guarantee

A digital signature ties a message to the holder of a private key. Anyone with the matching public key can confirm two things: the message came from that key, and it has not changed since signing. It does this without ever exposing the private key. The security rests on a hard math problem. For both Schnorr and ECDSA, that problem is the elliptic-curve discrete logarithm: given a public point P = xG, recovering the secret scalar x is infeasible.

If you are new to the curve arithmetic underneath all of this, our piece on elliptic-curve cryptography covers the group operations that the rest of this post takes for granted.

How Schnorr signing works

Start with a private key x and its public key P = xG, where G is the curve's base point and n is the group order. To sign a message m:

  1. Pick a random secret nonce k and compute the commitment R = kG.
  2. Compute the challenge e = H(R ‖ P ‖ m), a hash of the commitment, the public key, and the message.
  3. Compute the response s = k + e·x (mod n).

The signature is the pair (R, s). To verify, a recipient checks whether s·G equals R + e·P. The algebra falls out directly: s·G = (k + e·x)·G = kG + e·xG = R + e·P. If the equation holds, the signer knew x without revealing it. That is the entire scheme. There is no modular inversion, no special-casing, no branch that leaks timing.

Compare that to ECDSA, which computes s = k⁻¹(H(m) + r·x) mod n, needs a modular inverse of the nonce, and mixes the message hash and a coordinate of R in a way that has no clean security proof under the same simple assumptions. ECDSA works, and decades of scrutiny have hardened it. But it is the more fragile object to implement.

Linearity is the reason people care

The feature that makes Schnorr more than a tidier ECDSA is that its response is linear in the secret. Because s is just k + e·x, signatures and keys add together in predictable ways. That property unlocks constructions that ECDSA can only imitate with heavy machinery:

None of these are impossible with ECDSA. They are just awkward, and awkward cryptography is where bugs live.

The nonce decides everything

The random value k is the most dangerous part of any Schnorr or ECDSA implementation. It must be unique and secret for every signature. If it leaks, the private key falls out immediately: from s = k + e·x, an attacker who knows k solves for x in one step. Worse, you do not even need to leak k directly.

The reused-nonce trap

Sign two different messages with the same k and you produce s₁ = k + e₁·x and s₂ = k + e₂·x. Subtract them and k cancels: x = (s₁ − s₂) / (e₁ − e₂). The private key is now arithmetic. This is the same class of failure that broke the PlayStation 3's ECDSA code-signing in 2010, where a fixed nonce let researchers extract Sony's master key.

The modern defense is to stop trusting the random number generator for this value. RFC 6979 specifies deterministic nonces derived from the private key and the message hash, so two signatures over different messages can never collide. EdDSA, the Edwards-curve variant of Schnorr, bakes this in: Ed25519 computes its nonce as a hash of a secret key half and the message, with no runtime randomness at all. A weak or backdoored RNG cannot ruin a signature it never touches. If you want the broader picture, we covered this failure mode in nonce reuse vulnerabilities.

Schnorr versus ECDSA at a glance

Property Schnorr / EdDSA ECDSA
Security proof Provable under standard assumptions (ROM) No proof under the same simple assumptions
Signing math One hash, one multiply, one add Requires modular inversion of the nonce
Signature linearity Yes (enables aggregation, threshold, batch) No (workarounds are complex)
Deterministic nonce Built into Ed25519 Optional, via RFC 6979
Deployment history Newer in the mainstream (Ed25519, BIP 340) Decades of ubiquity (TLS, X.509, older chains)

Where you already meet it

Ed25519, published by Daniel J. Bernstein and colleagues in 2011, is a Schnorr-family signature over a carefully chosen Edwards curve. It is fast, resistant to a range of implementation mistakes, and now common in SSH keys, TLS certificates, package signing, and modern messaging protocols. Bitcoin's BIP 340 brought a secp256k1 Schnorr scheme to that chain in the 2021 Taproot activation, which is why multisignature spends there can now hide as ordinary payments.

Haven's group messaging sits on the same foundation. The MLS ciphersuite we pin (MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519) uses Ed25519 for the signatures that authenticate every group operation. When a member is added or removed, the commit that changes the group is signed by a real member's key, and the scheme verifying that signature is a direct descendant of the design a patent once kept on the shelf.

The lesson underneath the history is a practical one. Cryptographic choices made for legal or commercial reasons can outlive their reasons by decades, and the simpler primitive is usually the one that ages well. Schnorr signatures were the cleaner answer in 1989. They are still the cleaner answer now.

Try Haven free for 15 days

Encrypted email and chat in one app. No credit card required.

Get Started →