[Announce] Security fixes for Libgcrypt and GnuPG 1.4 [CVE-2016-6316]

Peter Gutmann pgut001 at cs.auckland.ac.nz
Fri Aug 19 14:08:01 CEST 2016

Werner Koch <wk at gnupg.org> writes:

>No need to reverse engineer the code.  Well, unless you are looking at that
>18 year old code from 1.4.  Here is the description from Libgcrypt before the

Ah, I was looking at cipher/random.c, for which the sole comment is 
/* loop over the pool */.

>The reason why only 64 bytes are hashed is that it allows the use of the bare
>transform function.  IIRC, old Cryptlib versions did the same but I guess you
>changed that to the full hash machinery in the course of your doctoral work.

Yeah, the last time the raw hash was used was in the 2002 release, since then
the code has used the high-level interface because calling into a low-level
internal function isn't very portable, and it makes the result harder to
analyse.  So now I explicitly hash $hashsize + 64 bytes, $hashsize bytes
before the current position for chaining and 64 bytes after.


More information about the Gnupg-users mailing list