Schnorr vs. ECDSA

tl;dr: It’s 2025. Do you know why Schnorr signatures are always better than ECDSA?

For a while I’ve wanted to summarize my understanding of why Schnorr signatures should always be preferred over ECDSA, which are unfortunately used a lot in cryptocurrencies.

Feel free to suggest other (dis)advantages and similarities!

Preliminaries

There are a few commonly-ocurring variants of Schnorr signatures:

• $(R,s)$-Schnorr, henceforth “vanilla Schnorr”
• $(e,s)$-Schnorr
• EdDSA, with its popular Ed25519 instantiation

There are also variants of ECDSA:

• Vanilla ECDSA, the most common one
• Deterministic ECDSA
• Modified ECDSA

As a result, our discussion below focuses on vanilla Schnorr versus vanilla ECDSA.

Advantages

Thresholdizable

Vanilla Schnorr admits a much more efficient protocol for $t$-out-of-$n$ threshold signatures, compared to ECDSA.

Example of threshold protocols:

• The well-known 4-round robust Schnorr¹ (less efficient)
• Yehuda’s 3-round threshold Schnorr with identifiable abort² (more efficient)
• 2-round FROST³ (even more efficient)

Of course, if you’re looking for the the fastest threshold protocol, you should go for our threshold BLS!

Batch verification

Vanilla Schnorr, as well as the Ed25519 variant, both support efficient batch verification!

In contrast, vanilla ECDSA does not allow for a faster batch verification algorithm, due to the ECDSA conversion function. (A modified ECDSA variant does support it, but most legacy systems do not use it.)

No NSA

The history of (EC)DSA is a bit suspicious, with some worrisome NSA involvment.

In contrast, Schnorr signatures were invented by Claus P. Schnorr, a German computer scientist. (Presumably with no ties to the NSA or other three-letter agencies?)

Furthermore, ECDSA is most often used over NIST curves. It doesn’t have to be, but it is. Some folks suspect these curves could be backdoored⁴.

Hintless pubkey recovery

Like ECDSA, vanilla Schnorr also supports pubkey recovery but without any hints, which are required in ECDSA (and complicate development⁵)!

Variations like $(e,s)$-Schnorr or Ed25519 do not support pubkey recovery!

Simpler, faster & safer

Vanilla Schnorr is arguably slighyly simpler to implement, since ECDSA requires:

• efficient modular inversion to compute $s^{-1}$ and $s^{-1}$
• ensuring that $k,r$ and $s$ are not zero during signing
• ensuring that $r$ and $s$ are not zero during verification

As a result, Schnorr is slightly faster than ECDSA, especially in the batched setting, due to ECDSA’s reliance on field inversions

Schnorr is also arguably slightly safer to implement, since ECDSA’s use of inversion has actually been exploited in practice (see here).

The EdDSA RFC⁶ also argues, albeit without any justification, that EdDSA (slightly different than vanilla Schnorr) is less susceptible to side-channel attacks.

Cleaner security proof

This is a nuanced topic, but the cryptographic analysis of Schnorr signatures is much more straightforward than ECDSA’s.

A few reasons why:

• EECDSA security reductions typically make non-standard assumptions about the conversion function
• …or: work in the generic group model (GGM)
• …or: introduce strange assumptions like the semi-discrete logarithm (SDLP) problem
• In fact, algebraic security reduction for ECDSA “can only exist if the security reduction is allowed to program the conversion function”⁷

A good summary of ECDSA’s (lack of?) provable security (under a realistic model) is given by Eike Kiltz in a PKC’21 presentation⁸ and his recent works⁹$^,$⁷.

Similarities

Signature size

For most choices of underlying elliptic curves $\mathbb{G}\bydef E(\F_q)$ where $p\bydef |E(\F_q)|$ is the order of $\Gr$, both schemes have the same signature sizes, since $p\approx q$:

• Vanilla Schnorr has two group elements in $\Gr$
• ECDSA has a $\Zp$ element and a $\Gr$ element

Perhaps if one were to do ECDSA over curves like BLS12-381, where $q \approx 2^{381}$ but $p \approx 2^{256}$, the signature size of ECDSA would be slightly smaller (i.e., $48 + 32$ bytes for ECDSA, compared to $2\times 48$ bytes for vanilla Schnorr). But, on the other hand, the $(e,s)$-Schnorr variant would have only $2\times 32$ bytes even over BLS12-381.

Malleability

Both schemes can be tricky to implement such that they are non-malleable.

Feeble against nonce bias

Both are vulnerable to attacks if their “nonces” are biased (see here and here).

Both are fixable via deterministic signing though (e.g., EdDSA and Ed25519 are not vulnerable).

Disadvantages

I can’t think of anything else besides the fact that Ed25519, the most popular Schnorr variant these days, does not actually support public key recovery, due to its hashing of the public key as part of the Fiat-Shamir transform.

Can you think of any disadvantages of vanilla Schnorr over vanilla ECDSA?

Conclusion

Schnorr. Always!

There are other aspects that I did not have time to look enough into but the reader may want to consider:

1. Daniel J. Bernstein argues that Ed25519 is more robust against implementation failures

References

For cited works, see below 👇👇