Opened 4 months ago
Closed 4 months ago
New point version
I've prepared a new bug-fix release of Nettle, a low-level
cryptographics library, to fix a serious bug in the function to verify
ECDSA signatures. Implications include an assertion failure, which could
be used for denial-of-service, when verifying signatures on the
secp_224r1 and secp521_r1 curves. More details in NEWS file below.
Upgrading is strongly recomended.
The Nettle home page can be found at
https://www.lysator.liu.se/~nisse/nettle/, and the manual at
The release can be downloaded from
NEWS for the Nettle 3.7.2 release
This is a bugfix release, fixing a bug in ECDSA signature
verification that could lead to a denial of service attack
(via an assertion failure) or possibly incorrect results. It
also fixes a few related problems where scalars are required
to be canonically reduced modulo the ECC group order, but in
fact may be slightly larger.
Upgrading to the new version is strongly recommended.
Even when no assert is triggered in ecdsa_verify, ECC point
multiplication may get invalid intermediate values as input,
and produce incorrect results. It's trivial to construct
alleged signatures that result in invalid intermediate values.
It appears difficult to construct an alleged signature that
makes the function misbehave in such a way that an invalid
signature is accepted as valid, but such attacks can't be
ruled out without further analysis.
Thanks to Guido Vranken for setting up the fuzzer tests that
uncovered this problem.
The new version is intended to be fully source and binary
compatible with Nettle-3.6. The shared library names are
libnettle.so.8.3 and libhogweed.so.6.3, with sonames
libnettle.so.8 and libhogweed.so.6.
* Fixed bug in ecdsa_verify, and added a corresponding test
* Similar fixes to ecc_gostdsa_verify and gostdsa_vko.
* Similar fixes to eddsa signatures. The problem is less severe
for these curves, because (i) the potentially out or range
value is derived from output of a hash function, making it
harder for the attacker to to hit the narrow range of
problematic values, and (ii) the ecc operations are
inherently more robust, and my current understanding is that
unless the corresponding assert is hit, the verify
operation should complete with a correct result.
* Fix to ecdsa_sign, which with a very low probability could
return out of range signature values, which would be
rejected immediately by a verifier.
This is probably errata worthy. There is no CVE, so I hesitate to assign a security advisory for this. However, one can get incorrect results or application crashes when processing signatures on secp_224r1 and secp521_r1 curves.
Here's some more information from the maintainer. From what I gather, x86_64 is the most affected, and x86 isn't affected at all.
I've been made aware of a bug in Nettle's code to verify ECDSA
signatures. Certain signatures result in the ecc point multiply function
being called with out-of-range scalars, which may give incorrect
results, or crash in an assertion failure. It's an old bug, probably
since Nettle's initial implementation of ECDSA.
I've just pushed fixes for ecdsa_verify, as well as a few other cases of
potentially out-of-range scalars, to the master-updates branch. I haven't
fully analysed the implications, but I'll describe my current
I think an assertion failure, useful for a denial-of-service attack, is
easy on the curves where the bitsize of q, the group order, is not an
integral number of words. That's secp224r1, on 64-bit platforms, and
Even when it's not possible to trigger an assertion failure, it's easy
to produce valid-looking input "signatures" that hit out-of range
intermediate scalar values where point multiplication may misbehave.
This applies to all the NIST secp* curves as well as the GOST curves.
To me, it looks very difficult to make it misbehave in such a way that
ecdsa_verify will think an invalid signature is valid, but it might be
possible; further analysis is needed. I will not be able to analyze it
properly now, if anyone else would like to look into it, I can provide a
bit more background.
ed25519 and ed448 may be affected too, but it appears a bit harder to
find inputs that hit out of range values. And since point operations are
inherently more robust on these curves, I think they will produce
correct results as long as they don't hit the assert.
Advise on how to deal best with this? My current plan is to prepare a
3.7.2 bugfix release (from a new bugfix-only branch, without the new
arm64 code). Maybe as soon as tomorrow (Wednesday, european time), or in
On second thought, I'll issue an SA for this instead of an errata, and I'll point to the email from nettle-bugs instead of a CVE.
Fixed at r24406
Powered by Trac 1.5.3.dev0
By Edgewall Software
© 1998-2021 Gerard Beekmans.