[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. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
