On 2/23/2017 at 1:27 PM, si...@web.de wrote:Today was announced that SHA1 is now completely broken https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
A few weeks back it was mentioned that there is a new proposal for a openpgp standart including a new algorithm for pgp fingerprints. As this is currently not applicable in practice, I would like to know what this new development means for pgp-gnupg and the use of SHA1 for key identification. After researching how the fingerprint is generated, I think it would be easy to include a new option in gnupg to print a fingerprint using sha256. Would that be something that will/can be included in future versions of gnupg ===== The Openpgp standards group is working on this. The link you give for the collision used 2 PDF's. Using a PDF is sort-of 'cheating', and does not extrapolate to being 'completely broken'. Assuming that it is possible to find a pre-image collision, i.e: [1] m1.txt 1 has an SHA1 hash of H1 [2] m2.txt will now have the same SHA1 hash H1 What will happen to in order to generate m2.txt is that there will be many trials of a gibberrish string added to the plaintext of m2.txt until one is found that has the same SHA1 hash as m1.txt BUT This will be quite visible in the plaintext of m2.txt, and won't fool anyone. With a PDF, the 'extra gibberish string' is 'hidden'. It is not in the actual PDF the receiver reads, only in the meta-data, the appended PDF 'Suffix'. While this is *do-able* and a good reason to move on to a future SHA256 hash, it would not be transferable (at this time, based on the PDF collision data), to find a fingerprint collision for any v4 key. vedaal
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users