On Sun, 24 Jan 2016 00:01, d...@fifthhorseman.net said: > fwiw, MD5 and SHA1 are both old digest algorithms, and are not as strong > as they should be. I recommend that anyone using checksums for file > integrity switch to SHA256 as soon as possible.
That is correct for MD5 given how easy it is to create collisions. For SHA-1 the case is different because there is _currently_ no known way to create a collisions let alone creating a second pre-image. As soon as it will be possible to create collisions for SHA-1 the world does not break apart regarding the use of SHA-1 checksums to verify the integrity and origin of distributed files: Only those who are anyway distributing the file will be able to create two different files resulting in the same SHA-1 digest. Right, they could do interesting things with that capability (providing a different file for certain requesting IPs) but that is a pretty limited use case given that interesting targets would anyway not rely on simple checksums. Checksums are used as a stop-gap for those who are not able to verify a digital signature [1]. The problem is that there is no bulletproof way of verifying the checksum - we post it on the website and we distribute it via the announcement mail. Both are not very secure - if you are able to break SHA-1 today you will also be able to modify these resources. There are many easier ways to attack software distributions: I would start with one of the libraries or tools required in the build process where we have no way to check for tampering. It is wishful thinking that the development process of all the, say, several hundred developers with commit access to the software or the tools required in the build process would withstand a targeted attack. If you talk to people on how they verify SSH fingerprints (that is even MD5 for most installations), you will so often hear: “Oh, I look at the first and a few of the last digits only”. We can assume that this won't be different for SHA-1 checksums - does anyone believe that by switching to SHA-256 they would check many more digits? I would even postulate that we will often hear a “SHA-256 is more secure than SHA-1, thus I do not need to compare more digits”. Running empirical tests might result in an interesting paper. Such a research should then also look at the new hard to compare base-64 encoded SHA-256 fingerprints of OpenSSH). > Also, the OpenPGP signature published at > https://files.gpg4win.org/gpg4win-2.3.0.exe.sig itself uses SHA1 > internally. This is also a bad idea. signatures published today should Yes, that should be fixed because it is easy and not subject to the UX problems described above. FWIW, for GnuPG proper we switched to SHA-256 in 2012 (gnupg 1.4.12). Salam-Shalom, Werner [1] Right, the GnuPG speedo build script with its signed and published list of package versions also uses SHA-1 and that should be fixed before 2.2. (filed as bug@2226) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
