[SOLVED] Verifying Arch ISO the correct way?

esotechnica · 2025-06-08 09:39:34

After downloading the Arch ISO image, the download page instructs the user to verify the file integrity using either the SHA256 or BLAKE2b checksums. It then asks the user to verify the PGP signature for the ISO.

My question is: are both of these checks necessary, or is only one sufficient? In particular I suspect verifying the PGP signature would be the only step needed, and verifying the checksum after that would be redundant.

Am I correct, or am I misunderstanding something?

Last edited by esotechnica (Today 05:59:41)

Lone_Wolf · 2025-06-08 11:59:44

Both check different things .

The checksum verifies content of the download, while the signature verifies who created the download.

If you want to be sure everything is as it should be check both.
In case you only check one, use the checksum .

esotechnica · 2025-06-10 05:51:22

I appreciate the reply, I would just like to clarify something though. Isn't the PGP signature just the checksum encrypted with the creator's private key? So by verifying the signature you're both verifying the creator, as well as the file integrity?

Lone_Wolf · 2025-06-10 10:21:09

Here's an example that may help to clarify things

You order an RX 9070XT online .
When the package arrives , you check the sender address and look for signs of tampering .
The package checks out fine.

When you open the package however you find you got a RX 5700 !

Checking the sender address & looking for signs of tampering is the equivalert of verifying the signature.
Opening the package and verifying it's content is equivalent to comparing a checksum .

Many people won't care much if the package has scratches / some damage as long as the content is what they want in good condition .

TL;DR : file integrity says nothing about the content inside the file .

mpan · 2025-06-10 10:46:27

esotechnica wrote:

My question is: are both of these checks necessary, or is only one sufficient? In particular I suspect verifying the PGP signature would be the only step needed, and verifying the checksum after that would be redundant.

Your thinking is correct.

No, there is no need to do both. And yes, verifying only the signature is sufficient. A signature does what checksums do, and more. It confirms file integrity against accidental and malicious changes, and who signed it.

This doesn’t hold in opposite direction. Checksums by themselves provide only the integrity check and that only against accidental changes. Which means that while there is no reason to do both, it’s always preferred to use the signature.

esotechnica · Today 05:58:30

Thanks mpan, it also seems to me that the checksum is stronger given it contains a SHA512 digest, rather than the SHA256 digest on the website

mpan · Today 07:49:45

I assume you meant to write “that the signature is stronger,” not “that the checksum is stronger.”

Both SHA-256 and SHA-512 are the same cryptographic digest: SHA-2. SHA-2 is suitable for protecting against both unintentional and malicious changes, regardless of the output size.

They differ in collision resistance, but with values that extreme, it is of no practical importance. It’s like weighting between a time trillion times the entire humankind is going to survive, and a time trillion times the universe will exist. So a much more important features are usability and performance. In security we rarely have simple “better” and this is no exception. For example a factor to consider is resistance against length extension attacks and in this case both are equally… bad: they offer none. In this case SHA-384 and SHA-512 truncated to 224 bits(!) perform infinitely better.

No, the real difference is not in output size. The difference comes from what the algorithm provides in terms of features. Digital signatures offer more than simple checksums. If you prefer a table, here it is:

                        | checksums | signatures
------------------------+-----------+-----------
Accidental modification |     ✓     |     ✓
Malicious modification  |     ✗     |     ✓
Authorship confirmation |     ✗     |     ✓

This table remains true without even considering, what specific hash is being used.

⁂

While not directly important for verifying Arch ISOs, for completness this table should further:

Divide “checksums” into simple checksums (like CRC, parity bits, check digits) and hashes. The former can at best deal with basic transmission errors: truncation, missing or repeated bits, swapped digits, or single errors. The latter extremely well detect any kind of an error.
Add message authentication codes (MAC). They offer the same as signatures at much lower cost, but with one critical drawback: the secret key must be shared between all parties. Which means anybody, who can verify MAC, can also forge one.

I mentioned this, because there is a strong counterargument to your initial assumption about “stronger hash.” HMACs may provide security not only using even smaller hash, but they still offer it with both MD5 and SHA-1!

So look at the algorithm, not merely seek bigger numbers. Sometimes they’re not directly comparable.

Last edited by mpan (Today 07:58:47)

Arch Linux

#1 2025-06-08 09:39:34

[SOLVED] Verifying Arch ISO the correct way?

#2 2025-06-08 11:59:44

Re: [SOLVED] Verifying Arch ISO the correct way?

#3 2025-06-10 05:51:22

Re: [SOLVED] Verifying Arch ISO the correct way?

#4 2025-06-10 10:21:09

Re: [SOLVED] Verifying Arch ISO the correct way?

#5 2025-06-10 10:46:27

Re: [SOLVED] Verifying Arch ISO the correct way?

#6 Today 05:58:30

Re: [SOLVED] Verifying Arch ISO the correct way?

#7 Today 07:49:45

Re: [SOLVED] Verifying Arch ISO the correct way?

Board footer