SHA-1 vs. SHA-256 checksums (was: Different SHA1 Checksum using Microsoft file checksum integrity verifier)

[Werner Koch]

On Sun, 24 Jan 2016 00:01, dkg at 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 at 2226)

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.