unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: 47222@debbugs.gnu.org
Subject: bug#47222: Serious bug in Nettle's ecdsa_verify
Date: Wed, 17 Mar 2021 20:21:54 -0400	[thread overview]
Message-ID: <87blbhia4i.fsf@netris.org> (raw)
In-Reply-To: cpfh7lbmsgz.fsf@slartibartfast.lysator.liu.se

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




       reply	other threads:[~2021-03-18  0:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cpfh7lbmsgz.fsf@slartibartfast.lysator.liu.se>
2021-03-18  0:21 ` Mark H Weaver [this message]
2021-03-21 19:47   ` bug#47222: [Niels Möller] ANNOUNCE: Nettle-3.7.2 Mark H Weaver
2021-03-25  9:51     ` bug#47222: Serious bug in Nettle's ecdsa_verify Ludovic Courtès
2021-03-25 16:21       ` Niels Möller
2021-03-25 18:16         ` Leo Famulari
2021-04-16 20:46         ` Ludovic Courtès
2021-04-06 11:09   ` Léo Le Bouter via Bug reports for GNU Guix
2022-08-08 17:11   ` bug#47222: paren--- via Bug reports for GNU Guix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87blbhia4i.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=47222@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).