[git] GCRYPT - branch, LIBGCRYPT-1-6-BRANCH, updated. libgcrypt-1.6.5-14-g7ee6bbb

by Werner Koch cvs at cvs.gnupg.org
Wed Aug 17 13:58:09 CEST 2016


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The GNU crypto library".

The branch, LIBGCRYPT-1-6-BRANCH has been updated
       via  7ee6bbb64f2a6e8351a20ea42d5a544dde429c27 (commit)
       via  e28f3f3d7b694cf440700a49d5927b3311cdd071 (commit)
       via  c748f87436d693f092a4484571a3cc7f650b5c81 (commit)
       via  190b0429b70eb4a3573377e95755d9cc13c38461 (commit)
      from  16a4ec65a636a00a0a234900c3a29b23a918c72f (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 7ee6bbb64f2a6e8351a20ea42d5a544dde429c27
Author: Werner Koch <wk at gnupg.org>
Date:   Wed Aug 17 13:52:42 2016 +0200

    Post release updates
    
    --

diff --git a/NEWS b/NEWS
index 0686dff..f978703 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,7 @@
+Noteworthy changes in version 1.6.7 (unreleased) [C20/A0/R_]
+------------------------------------------------
+
+
 Noteworthy changes in version 1.6.6 (2016-08-17) [C20/A0/R6]
 ------------------------------------------------
 
diff --git a/configure.ac b/configure.ac
index d427903..12379c8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -30,7 +30,7 @@ min_automake_version="1.14"
 # for the LT versions.
 m4_define(mym4_version_major, [1])
 m4_define(mym4_version_minor, [6])
-m4_define(mym4_version_micro, [6])
+m4_define(mym4_version_micro, [7])
 
 # Below is m4 magic to extract and compute the revision number, the
 # decimalized short revision number, a beta version string, and a flag

commit e28f3f3d7b694cf440700a49d5927b3311cdd071
Author: Werner Koch <wk at gnupg.org>
Date:   Wed Aug 17 13:46:32 2016 +0200

    Release 1.6.6
    
    * configure.ac: Set LT version to C20/A0/R6.
    
    Signed-off-by: Werner Koch <wk at gnupg.org>

diff --git a/NEWS b/NEWS
index 22ce582..0686dff 100644
--- a/NEWS
+++ b/NEWS
@@ -1,6 +1,11 @@
-Noteworthy changes in version 1.6.6 (unreleased) [C20/A0/R_]
+Noteworthy changes in version 1.6.6 (2016-08-17) [C20/A0/R6]
 ------------------------------------------------
 
+ * Fix critical security bug in the RNG [CVE-2016-6313].  An attacker
+   who obtains 580 bytes from the standard RNG can trivially predict
+   the next 20 bytes of output.  Problem detected by Felix Dörre and
+   Vladimir Klebanov, KIT.
+
 
 Noteworthy changes in version 1.6.5 (2016-02-09) [C20/A0/R5]
 ------------------------------------------------
diff --git a/configure.ac b/configure.ac
index 75d3a06..d427903 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,7 +56,7 @@ AC_INIT([libgcrypt],[mym4_full_version],[http://bugs.gnupg.org])
 #   (No interfaces changed:                   REVISION++)
 LIBGCRYPT_LT_CURRENT=20
 LIBGCRYPT_LT_AGE=0
-LIBGCRYPT_LT_REVISION=5
+LIBGCRYPT_LT_REVISION=6
 
 
 # If the API is changed in an incompatible way: increment the next counter.

commit c748f87436d693f092a4484571a3cc7f650b5c81
Author: Werner Koch <wk at gnupg.org>
Date:   Mon Aug 8 12:54:08 2016 +0200

    random: Hash continuous areas in the csprng pool.
    
    * random/random-csprng.c (mix_pool): Store the first hash at the end
    of the pool.
    --
    
    This fixes a long standing bug (since 1998) in Libgcrypt and GnuPG.
    An attacker who obtains 580 bytes of the random number from the
    standard RNG can trivially predict the next 20 bytes of output.
    
    For use in GnuPG this bug does not affect the default generation of
    keys because running gpg for key creation creates at most 2 keys from
    the pool: For a single 4096 bit RSA key 512 byte of random are
    required and thus for the second key (encryption subkey), 20 bytes
    could be predicted from the the first key.  However, the security of
    an OpenPGP key depends on the primary key (which was generated first)
    and thus the 20 predictable bytes should not be a problem.  For the
    default key length of 2048 bit nothing will be predictable.
    
    For the former default of DSA+Elgamal key it is complicate to give an
    answer: For 2048 bit keys a pool of 30 non-secret candidate primes of
    about 300 bits each are first created.  This reads at least 1140 bytes
    from the pool and thus parts could be predicted.  At some point a 256
    bit secret is read from the pool; which in the worst case might be
    partly predictable.
    
    The bug was found and reported by Felix Dörre and Vladimir Klebanov,
    Karlsruhe Institute of Technology.  A paper describing the problem in
    detail will shortly be published.
    
    CVE-id: CVE-2016-6313
    Signed-off-by: Werner Koch <wk at gnupg.org>

diff --git a/random/random-csprng.c b/random/random-csprng.c
index b3fc984..bc3ae50 100644
--- a/random/random-csprng.c
+++ b/random/random-csprng.c
@@ -571,23 +571,22 @@ _gcry_rngcsprng_randomize (void *buffer, size_t length,
  * bytes.
  *         <................600...............>   <.64.>
  * pool   |------------------------------------| |------|
- *         <..44..>                        <20>
- *            |                             |
- *            |                             +-----+
- *            +-----------------------------------|--+
- *                                                v  v
+ *         <20><.24.>                      <20>
+ *          |     |                         +-----+
+ *          +-----|-------------------------------|-+
+ *                +-------------------------------|-|-+
+ *                                                v v v
  *                                               |------|
  *                                                <hash>
- *                                                  |
  *          +---------------------------------------+
  *          v
  *         <20>
  * pool'  |------------------------------------|
- *         <20><20><..44..>
- *          |         |
- *          |         +------------------------------+
- *          +-------------------------------------+  |
- *                                                v  v
+ *         <20><20><.24.>
+ *          +---|-----|---------------------------+
+ *              +-----|---------------------------|-+
+ *                    +---------------------------|-|-+
+ *                                                v v v
  *                                               |------|
  *                                                <hash>
  *                                                  |
@@ -595,13 +594,11 @@ _gcry_rngcsprng_randomize (void *buffer, size_t length,
  *              v
  *             <20>
  * pool'' |------------------------------------|
- *         <20><20><20><..44..>
- *              |         |
- *              |         +--------------------------+
- *              +---------------------------------+  |
- *                                                v  v
- *                                               |------|
- *                                                <hash>
+ *         <20><20><20><.24.>
+ *              +---|-----|-----------------------+
+ *                  +-----|-----------------------|-+
+ *                        +-----------------------|-|-+
+ *                                                v v v
  *
  * and so on until we did this for all 30 blocks.
  *
@@ -628,9 +625,9 @@ mix_pool(unsigned char *pool)
   gcry_assert (pool_is_locked);
   _gcry_rmd160_init( &md );
 
-  /* Loop over the pool.  */
+  /* pool_0 -> pool'.  */
   pend = pool + POOLSIZE;
-  memcpy (hashbuf, pend - DIGESTLEN, DIGESTLEN );
+  memcpy (hashbuf, pend - DIGESTLEN, DIGESTLEN);
   memcpy (hashbuf+DIGESTLEN, pool, BLOCKLEN-DIGESTLEN);
   _gcry_rmd160_mixblock (&md, hashbuf);
   memcpy (pool, hashbuf, DIGESTLEN);
@@ -641,19 +638,17 @@ mix_pool(unsigned char *pool)
         pool[i] ^= failsafe_digest[i];
     }
 
+  /* Loop for the remaining iterations.  */
   p = pool;
   for (n=1; n < POOLBLOCKS; n++)
     {
-      memcpy (hashbuf, p, DIGESTLEN);
-
-      p += DIGESTLEN;
-      if (p+DIGESTLEN+BLOCKLEN < pend)
-        memcpy (hashbuf+DIGESTLEN, p+DIGESTLEN, BLOCKLEN-DIGESTLEN);
+      if (p + BLOCKLEN < pend)
+        memcpy (hashbuf, p, BLOCKLEN);
       else
         {
-          unsigned char *pp = p + DIGESTLEN;
+          unsigned char *pp = p;
 
-          for (i=DIGESTLEN; i < BLOCKLEN; i++ )
+          for (i=0; i < BLOCKLEN; i++ )
             {
               if ( pp >= pend )
                 pp = pool;
@@ -662,7 +657,8 @@ mix_pool(unsigned char *pool)
 	}
 
       _gcry_rmd160_mixblock (&md, hashbuf);
-      memcpy(p, hashbuf, DIGESTLEN);
+      p += DIGESTLEN;
+      memcpy (p, hashbuf, DIGESTLEN);
     }
 
     /* Our hash implementation does only leave small parts (64 bytes)

commit 190b0429b70eb4a3573377e95755d9cc13c38461
Author: Werner Koch <wk at gnupg.org>
Date:   Mon Aug 8 12:08:43 2016 +0200

    random: Improve the diagram showing the random mixing
    
    * random/random-csprng.c (mix_pool): Use DIGESTLEN instead of 20.
    --
    
    Signed-off-by: Werner Koch <wk at gnupg.org>

diff --git a/random/random-csprng.c b/random/random-csprng.c
index d3b6614..b3fc984 100644
--- a/random/random-csprng.c
+++ b/random/random-csprng.c
@@ -566,41 +566,49 @@ _gcry_rngcsprng_randomize (void *buffer, size_t length,
 
 
 /*
-   Mix the pool:
-
-   |........blocks*20byte........|20byte|..44byte..|
-   <..44byte..>           <20byte>
-        |                    |
-        |                    +------+
-        +---------------------------|----------+
-                                    v          v
-   |........blocks*20byte........|20byte|..44byte..|
-                                 <.....64bytes.....>
-                                         |
-      +----------------------------------+
-     Hash
-      v
-   |.............................|20byte|..44byte..|
-   <20byte><20byte><..44byte..>
-      |                |
-      |                +---------------------+
-      +-----------------------------+        |
-                                    v        v
-   |.............................|20byte|..44byte..|
-                                 <.....64byte......>
-                                        |
-              +-------------------------+
-             Hash
-              v
-   |.............................|20byte|..44byte..|
-   <20byte><20byte><..44byte..>
-
-   and so on until we did this for all blocks.
-
-   To better protect against implementation errors in this code, we
-   xor a digest of the entire pool into the pool before mixing.
-
-   Note: this function must only be called with a locked pool.
+ * Mix the 600 byte pool.  Note that the 64 byte scratch area directly
+ * follows the pool.  The numbers in the diagram give the number of
+ * bytes.
+ *         <................600...............>   <.64.>
+ * pool   |------------------------------------| |------|
+ *         <..44..>                        <20>
+ *            |                             |
+ *            |                             +-----+
+ *            +-----------------------------------|--+
+ *                                                v  v
+ *                                               |------|
+ *                                                <hash>
+ *                                                  |
+ *          +---------------------------------------+
+ *          v
+ *         <20>
+ * pool'  |------------------------------------|
+ *         <20><20><..44..>
+ *          |         |
+ *          |         +------------------------------+
+ *          +-------------------------------------+  |
+ *                                                v  v
+ *                                               |------|
+ *                                                <hash>
+ *                                                  |
+ *              +-----------------------------------+
+ *              v
+ *             <20>
+ * pool'' |------------------------------------|
+ *         <20><20><20><..44..>
+ *              |         |
+ *              |         +--------------------------+
+ *              +---------------------------------+  |
+ *                                                v  v
+ *                                               |------|
+ *                                                <hash>
+ *
+ * and so on until we did this for all 30 blocks.
+ *
+ * To better protect against implementation errors in this code, we
+ * xor a digest of the entire pool into the pool before mixing.
+ *
+ * Note: this function must only be called with a locked pool.
  */
 static void
 mix_pool(unsigned char *pool)
@@ -622,14 +630,14 @@ mix_pool(unsigned char *pool)
 
   /* Loop over the pool.  */
   pend = pool + POOLSIZE;
-  memcpy(hashbuf, pend - DIGESTLEN, DIGESTLEN );
-  memcpy(hashbuf+DIGESTLEN, pool, BLOCKLEN-DIGESTLEN);
-  _gcry_rmd160_mixblock( &md, hashbuf);
-  memcpy(pool, hashbuf, 20 );
+  memcpy (hashbuf, pend - DIGESTLEN, DIGESTLEN );
+  memcpy (hashbuf+DIGESTLEN, pool, BLOCKLEN-DIGESTLEN);
+  _gcry_rmd160_mixblock (&md, hashbuf);
+  memcpy (pool, hashbuf, DIGESTLEN);
 
   if (failsafe_digest_valid && pool == rndpool)
     {
-      for (i=0; i < 20; i++)
+      for (i=0; i < DIGESTLEN; i++)
         pool[i] ^= failsafe_digest[i];
     }
 
@@ -653,8 +661,8 @@ mix_pool(unsigned char *pool)
 	    }
 	}
 
-      _gcry_rmd160_mixblock ( &md, hashbuf);
-      memcpy(p, hashbuf, 20 );
+      _gcry_rmd160_mixblock (&md, hashbuf);
+      memcpy(p, hashbuf, DIGESTLEN);
     }
 
     /* Our hash implementation does only leave small parts (64 bytes)

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

Summary of changes:
 NEWS                   |  11 +++++-
 configure.ac           |   4 +-
 random/random-csprng.c | 104 +++++++++++++++++++++++++------------------------
 3 files changed, 66 insertions(+), 53 deletions(-)


hooks/post-receive
-- 
The GNU crypto library
http://git.gnupg.org




More information about the Gnupg-commits mailing list