Fedora alert FEDORA-2017-bcdeca9d41 (libgcrypt)


From:
    	       updates@fedoraproject.org 
To:
    	       package-announce@lists.fedoraproject.org 
Subject:
    	       [SECURITY] Fedora 26 Update: libgcrypt-1.7.9-1.fc26 
Date:
    	       Tue,  7 Nov 2017 22:22:21 +0000 (UTC)
Message-ID:
    	       <20171107222221.9543060799F0@bastion01.phx2.fedoraproject.org>
--------------------------------------------------------------------------------
Fedora Update Notification
FEDORA-2017-bcdeca9d41
2017-11-07 21:00:14.744151
--------------------------------------------------------------------------------

Name        : libgcrypt
Product     : Fedora 26
Version     : 1.7.9
Release     : 1.fc26
URL         : http://www.gnupg.org/

Summary     : A general-purpose cryptography library
Description :
Libgcrypt is a general purpose crypto library based on the code used
in GNU Privacy Guard.  This is a development version.

--------------------------------------------------------------------------------
Update Information:

Minor security update release 1.7.9.
--------------------------------------------------------------------------------
References:

  [ 1 ] Bug #1485921 - CVE-2017-0379 libgcrypt: Missing input validation for X25519 curve
        https://bugzilla.redhat.com/show_bug.cgi?id=1485921

--------------------------------------------------------------------------------

This update can be installed with the "dnf" update program. Use
su -c 'dnf upgrade libgcrypt' at the command line.
For more information, refer to the dnf documentation available at
http://dnf.readthedocs.io/en/latest/command_ref.html#upgr...

All packages are signed with the Fedora Project GPG key. More details on the
GPG keys used by the Fedora Project can be found at
https://fedoraproject.org/keys

--------------------------------------------------------------------------------
_______________________________________________
package-announce mailing list -- package-announce@lists.fedoraproject.org
To unsubscribe send an email to package-announce-leave@lists.fedoraproject.org

to post comments

The Curve25519 Key Validation Debate

Posted Nov 9, 2017 10:02 UTC (Thu) by biergaizi (subscriber, #92498) [Link] (1 responses)

This security issue is particularly interesting. Earlier in this year, there were some debates about whether a Curve25519 key should be validated.

Original Discussion:
https://research.kudelskisecurity.com/2017/04/25/should-e...

HackerNews comments:
https://news.ycombinator.com/item?id=14199197

TL;DR, Curve25519 doesn't need input validation, by design. Validation is not only unnecessary, but "adds complexity", such as "const-time code, error-handling, and implementation variance, and is not needed in good protocols." Although, in some cases where "contributory behavior" is required (not ECDH-related), and the author of the original article was skeptical, argued for validation as "defense-in-depth", but "If Moxie, Trevor, and DJB argue that public keys shouldn't be validated, then the debate is over."

This discussion has just became slightly more interesting.

Now as we see, we have a real world timing attack against GnuPG's implementation Curve25519. Since libgcrypt doesn't use constant-time field arithmetic (!), it's possible to inject malicious input with invalid curve points and observe the timings, hence recover the private key "in as few as 11 attempts". The malicious input fails the output checking and triggers an error, this is when the timings have been leaked.

GnuPG has fixed by adding input validation (!).
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;...

I was shocked to find libgcrypt does not use constant-time arithmetic, which should be the proper way of doing it. But at least we now know input validation can also protect you from timing attacks if you do not implement constant-time field arithmetic correctly (you should).

Paper:

https://eprint.iacr.org/2017/806.pdf
May the Fourth Be With You: A Microarchitectural Side Channel Attack on Real-World Applications of Curve25519
by Daniel Genkin, Luke Valenta, and Yuval Yarom

The Curve25519 Key Validation Debate

Posted Nov 9, 2017 11:40 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

Implementing constant time processing in a *portable* way is really hard up to impossible. It depends on just too many factors. It is not only the type of the cpu put also the variant of the cpu and the OS. And the most annoying thing are compilers which reorder or remove code by looking only looking on the spec but not in the intended or de-facto use of programming constructs.

DJB steps most problems aside by writing curve specific code for certain cpus. We are in the process of improving our code for commonly used curves by replicating the reference code. Using the reference code directly is not possible due to different ways of representing big integers and the fact that the reference code has zero comments. For the Gnuk token Gniibe is even considering to move to a different MCU to have better control over the pipeline.

Anyway, the real problem behind the story is that all implementors have been told to drop or not to do input validation for Curve25519 decryption.

From:		updates@fedoraproject.org
To:		package-announce@lists.fedoraproject.org
Subject:		[SECURITY] Fedora 26 Update: libgcrypt-1.7.9-1.fc26
Date:		Tue, 7 Nov 2017 22:22:21 +0000 (UTC)
Message-ID:		<20171107222221.9543060799F0@bastion01.phx2.fedoraproject.org>