Different SHA1 Checksum using Microsoft file checksum integrity verifier

[W Wong]

Greeting all:

I downloaded the Gpg4win 2.3.0 (Released: 2015-11-25)

from https://www.gpg4win.org/download.html


I did a checksum using Microsoft file checksum integrity verifier as
follows:

C:\Users\edsw\utility>fciv.exe ..\..\Downloads\gpg4win-2.3.0.exe

//

// File Checksum Integrity Verifier version 2.05.

//

4a88f90a01b0ba8e3eb0073f7b6a4bfb ..\..\downloads\gpg4win-2.3.0.exe


The checksum is different from the one announced on the site


SHA1 checksum (for gpg4win2.3.0.exe):
88d90ee9a1ea3e66b198ea866063140b882444d5


I believe that nothing has been tampered with the version gpg4win-2.3.0.exe
that I have downloaded. Is there any reason why the Microsoft file checksum
integrity verifier (fciv) will produce a different checksum?


May be the checksum announced on the https://www.gpg4win.org/download.html

has not been updated for a while???


Please comment. Thanks in advance for your assistance with my query


Best regards,


Wyatt

[Daniel Kahn Gillmor]

Hi Wyatt--

Post by W Wong
I downloaded the Gpg4win 2.3.0 (Released: 2015-11-25)
from https://www.gpg4win.org/download.html
I did a checksum using Microsoft file checksum integrity verifier as

on any modern version of windows, you should be able to do checksum
verification with certutil.exe using the -hashfile subcommand:

https://technet.microsoft.com/en-us/library/cc732443.aspx#BKMK_hashfile

Post by W Wong
C:\Users\edsw\utility>fciv.exe ..\..\Downloads\gpg4win-2.3.0.exe
//
// File Checksum Integrity Verifier version 2.05.
//
4a88f90a01b0ba8e3eb0073f7b6a4bfb ..\..\downloads\gpg4win-2.3.0.exe
The checksum is different from the one announced on the site
88d90ee9a1ea3e66b198ea866063140b882444d5

Note that the lengths are different, which suggests that they might be
different digest algorithms entirely. I believe that fciv.exe is
calculating the MD5 checksum, while the download site is using the SHA1
checksum.

Indeed, i see the MD5 sum matching the value you found with fciv.exe,
while the SHA1 sum matches the published data:

0 ***@alice:~$ gpg2 --print-md MD5 < gpg4win-2.3.0.exe
4A 88 F9 0A 01 B0 BA 8E 3E B0 07 3F 7B 6A 4B FB
0 ***@alice:~$ gpg2 --print-md SHA1 < gpg4win-2.3.0.exe
88D9 0EE9 A1EA 3E66 B198 EA86 6063 140B 8824 44D5
0 ***@alice:~$

So i think your download is most likely ok (assuming that fciv is doing
what i believe it is).

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.

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
use at least SHA256, as every modern OpenPGP implementation has been
capable of verifying SHA256 signatures for years now.

hth,

--dkg

[Werner Koch]

Post by Daniel Kahn Gillmor
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).

Post by Daniel Kahn Gillmor
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 ***@2226)

[Daniel Kahn Gillmor]

Post by Werner Koch
If you talk to people on how they verify SSH fingerprints (that is even
MD5 for most installations)

SSH key fingerprints are a different thing than software distribution
checksums because the material digested in ssh originates entirely from
one party, whereas the software distribution checksums can potentially
be influenced by multiple parties.

Post by Werner Koch
you will so often hear: “Oh, I look at the first and a few of the
last digits only”.

right, this is not a cryptographically-strong verification :)

Post by Werner Koch
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?

if they don't check more digits, then we can't help them. but it'd be
nice to offer a way for people to do a cryptographically-strong check if
they decide to do so.

but in general, i agree with you that published checksums are stopgap
measures at best, mainly fit for detecting corrupted downloads, and not
particularly useful against a targeted attack.

Post by Werner Koch

Post by Daniel Kahn Gillmor
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).

[...]

Post by Werner Koch
[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

great, thanks!

--dkg

[Tom Browder]

Post by W Wong
I downloaded the Gpg4win 2.3.0 (Released: 2015-11-25)
from https://www.gpg4win.org/download.html

...

Post by W Wong
I did a checksum using Microsoft file checksum integrity verifier as
C:\Users\edsw\utility>fciv.exe ..\..\Downloads\gpg4win-2.3.0.exe
//
// File Checksum Integrity Verifier version 2.05.
//
4a88f90a01b0ba8e3eb0073f7b6a4bfb ..\..\downloads\gpg4win-2.3.0.exe

Wyatt, that checksum is shorter than the one on the site. Make sure
you use the '-sha1' option.

-Tom

[Christoph Moench-Tegeder]

Post by W Wong
4a88f90a01b0ba8e3eb0073f7b6a4bfb ..\..\downloads\gpg4win-2.3.0.exe

That is the MD5 checksum of the gpg4win-2.3.0.exe file, which has
the SHA1 checksum 88d90ee9a1ea3e66b198ea866063140b882444d5.

Regards,
Christoph