LinuxQuestions.org - Checking file integrity

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Checking file integrity (https://www.linuxquestions.org/questions/linux-newbie-8/checking-file-integrity-4175500484/)

Checking file integrity

Often software available for download will have hashes similar to those shown below (this one is from http://centos.mirror.facebook.net/6.5/isos/x86_64/).

Is it just personnel preference whether md5, sha1, or sha256 is used, or is one better than the other?

Are the hash files which end in "asc" also providing protection that the actual hash file is legitimate? How do I use this second hash?

I understand how to use md5sum, but then I need to visually compare the two hashes. Is there a good way have the command compare the MD5 of the file to a given hash string, and indicate yes/no whether they match?

I take it the reason to do so is to ensure the software is the same as the original author intended. Is the treat that some bad guy might replace the file with some sinister software? If someone could do that, wouldn't it be just as easy to replace the hash files with something that matches the bad software

Thank you

md5sum.txt:

Code:

83221db52687c7b857e65bfe60787838  CentOS-6.5-x86_64-bin-DVD1.iso

91018b86ca338360bc1212f06ea1719f  CentOS-6.5-x86_64-bin-DVD2.iso

8c37390fa5d932d03feb05fba13fe92e  CentOS-6.5-x86_64-LiveCD.iso

7b571e13ce6c3f61dc176bd34f8d60bb  CentOS-6.5-x86_64-LiveDVD.iso

0d9dc37b5dd4befa1c440d2174e88a87  CentOS-6.5-x86_64-minimal.iso

939fd1d87c11ffe7795324438b85adfb  CentOS-6.5-x86_64-netinstall.iso

md5sum.txt.asc:

Code:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



83221db52687c7b857e65bfe60787838  CentOS-6.5-x86_64-bin-DVD1.iso

91018b86ca338360bc1212f06ea1719f  CentOS-6.5-x86_64-bin-DVD2.iso

8c37390fa5d932d03feb05fba13fe92e  CentOS-6.5-x86_64-LiveCD.iso

7b571e13ce6c3f61dc176bd34f8d60bb  CentOS-6.5-x86_64-LiveDVD.iso

0d9dc37b5dd4befa1c440d2174e88a87  CentOS-6.5-x86_64-minimal.iso

939fd1d87c11ffe7795324438b85adfb  CentOS-6.5-x86_64-netinstall.iso

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v2.0.14 (GNU/Linux)



iQIcBAEBAgAGBQJSmNXkAAoJEAlG/KLBBbnesZkP+wQ97c/t9YatQvrkdkuS53+z

aocVbfZywyKt5V2v0Hz2470h57azhnSwBDm8xD6RRnNOfjwAzxGUnnXz+zwB3e6i

heDfl9H6mLSWPBRnlMYxjYLdbF5/vgUDqhSFJIAqgUg3hX7RtueMgq73SMmZXPG+

FIqJDQCnJ2GXXkap8yZzqeEB+N9R5LpeTSNcAuvm4TEcd9u470KtF90hMj+JuRHx

4ySu6hO1of7L5h9tynsP9kPZNTe+Q1BAJHFQfds5CexeSeVSKYrBEPfwYFHe5A+W

R9ycOtlIs6e7/lIjW9AlTI3aaaTdAXSVpcuRRcKlwyaJ9gKmBZbTjfjNiAWEUTvC

a3pFFpwqrkHhFPOIx0ilcEIY15D6euZstP/99+8TsisvEQuktnWq88JV+feEQg/m

nvhEj6z29ihhiwvHXcbmM3PB3Ovohjb4ZGnmKKFodqG/2rxQJ2eU5sfMlgFeMX6p

hCmiCDCZhdy39H3mo+AZXZsP7mvpcMSbuWKN+6q7/LQLvt4uMXjR8P/zHReVpmO1

5JLT8tm2NcT2nzIgOdELDYihPo9LRnwFdwPupTL3h/JRJ95ssiqUSA3rPD+gO24/

8Xh38CnjJDmXJmuWzC+MNa1HfQUqzREAXTo21qDxQ0LM+a0mEAoXvKNz/a7m0zxF

nVo51tyAxeGFNj9782T+

=L56x

-----END PGP SIGNATURE-----

Code:

Is it just personnel preference whether md5, sha1, or sha256 is used, or is one better than the other?

Best? All three, almost certainly stops any attacks, but, in reality, any will do. SHA256 will (obviously) have less collisions over something like, MD5, purely because the hash is larger (256 bits for SHA256, 128 for MD5), and, MD5 is also technically cryptographically broken, it's fine for just verifying that files got from place A to place B without an issue, but, an attack on the files *may* have occurred (Although, would still be hard to pull off), so, really, it's personal preference, there's a few other things (SHA1 will outperform SHA256 in a CPU time test, although, the main bottleneck will be your disk I/O), but, they're negligible.

Code:

I understand how to use md5sum, but then I need to visually compare the two hashes. Is there a good way have the command compare the MD5 of the file to a given hash string, and indicate yes/no whether they match?

Code:

[root@Archx64_VM tmp]# dd if=/dev/urandom bs=1M count=5 of=randomFile

5+0 records in

5+0 records out

5242880 bytes (5.2 MB) copied, 0.322251 s, 16.3 MB/s

[root@Archx64_VM tmp]# md5sum randomFile | tee randomFile.md5

2eb136e8737185d21e0aba5348e53d44  randomFile

[root@Archx64_VM tmp]# md5sum -c randomFile.md5

randomFile: OK

Should answer your questions decently well, same applies to sha1, sha256, and, sha512 sum:-

Code:

[root@Archx64_VM tmp]# dd if=/dev/urandom bs=1M count=5 of=randomFile

5+0 records in

5+0 records out

5242880 bytes (5.2 MB) copied, 0.324517 s, 16.2 MB/s

[root@Archx64_VM tmp]# for i in sha1 sha256 sha512; do ${i}sum randomFile | tee randomFile.${i}; ${i}sum -c randomFile.${i}; done

6a82df8189ae161a19bf6ad0ed52b7859ff1ae18  randomFile

randomFile: OK

68c09b0306f1930b5da6755fcb4d1c57ac2a8c2f8a2118893a9b9bfdcf3011e2  randomFile

randomFile: OK

d7061e499f331bf57071b6bfcd3d04a339b70e0eaa6cb683e0654d61ddd9d90ea0990b7fd3471825b2aabd53151cf9134d64c2f4611fd1d3c18386c5d4006259  randomFile

randomFile: OK

Code:

I take it the reason to do so is to ensure the software is the same as the original author intended. Is the treat that some bad guy might replace the file with some sinister software? If someone could do that, wouldn't it be just as easy to replace the hash files with something that matches the bad software

Sort of, the main (Absolute main) point is verify zero corrupt from point A to point B (Yes, TCP is grand at fixing errors, but, that doesn't help anything if the files were corrupt from the start, or, corrupt after they got to you), however, it can also be used to prevent an attacker from swapping the file out, that is why they provide the .asc, which is signed, you have to manually, however, verify that the person who signed it is the person that you actually trust, to verify it, type:-

Code:

gpg --verify md5sum.txt.asc

However, that'll just spit back a fingerprint, your job to is actually verify that that fingerprint and the owner are one-and-the-same.

As stated, md5 is broken so it is NOT preferred. sha1 is getting a bit old. The best hash of the three would be sha-256.

The .asc file is PGP signed. You can verify it using 'gpg --verify file.asc'. It verifies BOTH the integrity and authenticity of the file. Hashes only validate the integrity. Now that isn't to say that PGP signatures can't be faked:
http://it.slashdot.org/story/14/03/2...velopers-found

Understand that if someone breaches a server, they will likely alter all relevant files to make them match. The hardest one to alter is the .asc file because it relies on a the PGP key server, which is a different server. Technically, you could improve security using regular hashes by using different servers for different parts, that way they would have to alter multiple servers to get everything to match up.

To verify checksum files use the '-c' option, it's the same option for md5sum, sha1sum, sha512sum. 'sha1sum -c checksums.sha1'

Thank you all.

OK, I take it that md5/sha1/sha256 are all probably adequate for this application, but, I should use the strongest hashing algorithms provided (i.e. sha256) if I am not concerned about CPU demands.

Also, I understand that the .asc files are used to authenticity the file. What do they authenticate against? Maybe "/etc/pki/rpm-gpg/RPM-GPG-KEY*"?

I've tried a bit more, but still don't understand who I could trust. How do I establish the original trust?

Code:

[root@michales ~]# gpg --verify sha256sum.txt.asc

gpg: Signature made Fri 29 Nov 2013 09:58:38 AM PST using RSA key ID C105B9DE

gpg: Can't check signature: No public key

[root@michales ~]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*

[root@michales ~]# gpg --verify sha256sum.txt.asc

gpg: Signature made Fri 29 Nov 2013 09:58:38 AM PST using RSA key ID C105B9DE

gpg: Can't check signature: No public key

[root@michales ~]# gpg --recv-keys C105B9DE

gpg: keyring `/root/.gnupg/secring.gpg' created

gpg: requesting key C105B9DE from hkp server keys.gnupg.net

gpg: /root/.gnupg/trustdb.gpg: trustdb created

gpg: key C105B9DE: public key "CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org>" imported

gpg: no ultimately trusted keys found

gpg: Total number processed: 1

gpg:              imported: 1  (RSA: 1)

[root@michales ~]# gpg --verify sha256sum.txt.asc

gpg: Signature made Fri 29 Nov 2013 09:58:38 AM PST using RSA key ID C105B9DE

gpg: Good signature from "CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org>"

gpg: WARNING: This key is not certified with a trusted signature!

gpg:          There is no indication that the signature belongs to the owner.

Primary key fingerprint: C1DA C52D 1664 E8A4 386D  BA43 0946 FCA2 C105 B9DE

[root@michales ~]#

Also, I don't know if it is related, but I tried to create my own key. At the end of the process, I received the error about not being able to connect to `/root/.gnupg/S.gpg-agent'. After this part, the command just hung indefinitely. How do I resolve this?

Code:

[root@michales ~]# gpg --gen-key

gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.



Please select what kind of key you want:

  (1) RSA and RSA (default)

  (2) DSA and Elgamal

  (3) DSA (sign only)

  (4) RSA (sign only)

Your selection? 1

RSA keys may be between 1024 and 4096 bits long.

What keysize do you want? (2048)

Requested keysize is 2048 bits

Please specify how long the key should be valid.

        0 = key does not expire

      <n>  = key expires in n days

      <n>w = key expires in n weeks

      <n>m = key expires in n months

      <n>y = key expires in n years

Key is valid for? (0)

Key does not expire at all

Is this correct? (y/N) y



GnuPG needs to construct a user ID to identify your key.



Real name: Michael

Email address: xxx@xxx.net

Comment:

You selected this USER-ID:

    "Michael <xxx@xxx>"



Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

You need a Passphrase to protect your secret key.



can't connect to `/root/.gnupg/S.gpg-agent': No such file or directory

gpg-agent[2439]: directory `/root/.gnupg/private-keys-v1.d' created

We need to generate a lot of random bytes. It is a good idea to perform

some other action (type on the keyboard, move the mouse, utilize the

disks) during the prime generation; this gives the random number

generator a better chance to gain enough entropy.

Quote:

Originally Posted by mddesai (Post 5146652)

Try this.

Thanks mddesai, doing so removed the error, and I apparently can connect to `/root/.gnupg/S.gpg-agent'.

It still just hangs, however. How long does it take to "generate a lot of random bytes"? I've waited 45 minutes before ^C, and killing the process.

Guess I just had to wait for gpg --gen-key. Took about 50 minutes or so.

Back to the original question. When verifying a file using 'gpg --verify file.asc', how do I know it is valid since it certified with a trusted signature?

Code:

[root@michales ~]# gpg --verify sha256sum.txt.asc

gpg: Signature made Fri 29 Nov 2013 09:58:38 AM PST using RSA key ID C105B9DE

gpg: Can't check signature: No public key

[root@michales ~]# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*

[root@michales ~]# gpg --verify sha256sum.txt.asc

gpg: Signature made Fri 29 Nov 2013 09:58:38 AM PST using RSA key ID C105B9DE

gpg: Can't check signature: No public key

[root@michales ~]# gpg --recv-keys C105B9DE

gpg: keyring `/root/.gnupg/secring.gpg' created

gpg: requesting key C105B9DE from hkp server keys.gnupg.net

gpg: /root/.gnupg/trustdb.gpg: trustdb created

gpg: key C105B9DE: public key "CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org>" imported

gpg: no ultimately trusted keys found

gpg: Total number processed: 1

gpg:              imported: 1  (RSA: 1)

[root@michales ~]# gpg --verify sha256sum.txt.asc

gpg: Signature made Fri 29 Nov 2013 09:58:38 AM PST using RSA key ID C105B9DE

gpg: Good signature from "CentOS-6 Key (CentOS 6 Official Signing Key) <centos-6-key@centos.org>"

gpg: WARNING: This key is not certified with a trusted signature!

gpg:          There is no indication that the signature belongs to the owner.

Primary key fingerprint: C1DA C52D 1664 E8A4 386D  BA43 0946 FCA2 C105 B9DE

[root@michales ~]#

Thanks mddesai, That was helpful.

So, when generating a key, it is mandatory to add a comment? The utube video used the comment kind of like a username, and used commands such as "gpg --encrypt --recipient user file.txt" and "gpg --armor --output Michael_PUBKEY.txt --export user". Why not use the linux username?

I think I am still uncertain on my previous question, but let me digest this for a bit.

Thanks