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

[Peter Gutmann]

[Redirected to gnupg-devel rather than gnupg-users because it seems more
 appropriate there]

I wrote:

>OK, I'm downloading an older source archive now, let's see if I can find the
>flaw before Werner posts a reply :-)

So I think I've managed to reverse-engineer what the code is doing (there are
no code comments explaining it).  It's not at all what I described in my PRNG
paper, but I can't tell if that's an accident or by design because, well,
there are no code comments.  What the GnuPG code does is mix the next 64 bytes
and then overwrite the preceding 20 bytes with the mixed output, however this
doesn't propagate any entropy along through the buffer.  Quoting the original
paper:

  Assuming the use of MD5, which has a 64-byte input and 16-byte output, we
  would hash the 16+64 bytes at locations n-16... n+63 and then write the
  resulting 16-byte hash to locations n ... n+15 (the chaining which is
  performed explicitly by PGP is performed implicitly here by including the
  previously processed 16 bytes in the input to the hash function). We then
  move forward 16 bytes and repeat the process, wrapping the input around to
  the start of the buffer when the end of the buffer is reached. The
  overlapping of the data input to each hash means that each 16-byte block
  which is processed is influenced by all the surrounding bytes

The GnuPG code however only hashes the next 64 bytes, and then uses the output
to overwrite the current 20 bytes (it uses RMD160, not MD5, since it's a bit
newer than the original paper).  No state is carried along.

Peter.