emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47222: closed (Serious bug in Nettle's ecdsa_verify)


From: GNU bug Tracking System
Subject: bug#47222: closed (Serious bug in Nettle's ecdsa_verify)
Date: Mon, 08 Aug 2022 17:13:02 +0000

Your message dated Mon, 08 Aug 2022 18:11:05 +0100
with message-id <CM0TBR948W8B.2JY3QM6WIGB4A@guix-aspire>
and subject line 
has caused the debbugs.gnu.org bug report #47222,
regarding Serious bug in Nettle's ecdsa_verify
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
47222: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47222
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Serious bug in Nettle's ecdsa_verify Date: Wed, 17 Mar 2021 20:21:54 -0400
FYI...

-------------------- Start of forwarded message --------------------
From: nisse@lysator.liu.se (Niels Möller)
To: nettle-bugs@lists.lysator.liu.se
Subject: ANNOUNCE: Serious bug in Nettle's ecdsa_verify
Date: Tue, 16 Mar 2021 09:07:56 +0100

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
understanding.

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
secp521r1.

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
the weekend.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

_______________________________________________
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
-------------------- End of forwarded message --------------------



--- End Message ---
--- Begin Message --- Subject: Date: Mon, 08 Aug 2022 18:11:05 +0100
We now have nettle 3.7.3, so this isn't an issue anymore. Closing.

    -- (


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]