On Thu, 17 Mar 2016 20:44, d...@fifthhorseman.net said: > FWIW, the threat model of digest algorithms being published on an HTTPS > website that then links to the file to be downloaded is much easier to > work around than by compromising SHA-1's preimage resistance (or even
I fully agree and I view cecksums only as the last resort to verify something downloaded. However sometimes it is required - there are some OS which do not have gpg installed (OpenBSD, Windows) and there need to be a way to bootstrap the installation. Of course the checksums on the web page are not sufficient and they do only work because we also announce them by mail and also by means of a signed file (gnupg.org/swdb.lst{,.sig). Any non-targeted tampering of the checksum will likely be reported soon. In fact we had such reports in the past due to a c+p bug by me. I'll look at how we can improve the description on the web page. > However, it makes more sense to me to just move everything to sha-256 > today. Anyone who actually checks the digests should be capable of > using sha256 today, and it would avoid this sort of question coming up Most people are actually not able to check even the SHA-1 checksums because they are missing a tool to do so (e.g. Windows) and have not the knowledge to install or compile and audit a shaXsum tool. Further, in my experience many users do not check the entire SHA-1 sum but just a few of the first and last digits. With the longer and harder to read SHA-256 checksums this will only get worse (“oh yes, the checksum is longer and thus safer and thus I need to compare less digits” :-(). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users