Download a Linux ISO and burn it as is to a USB drive without checking anything. It's like installing new doors and windows at home without checking if the order is complete or if someone has swapped them along the way. Most of the time nothing happens, but the day it does… it hurts. A corrupted ISO can cause failed installations, unstable systems, and, in the worst-case scenario, a maliciously manipulated file.
Therefore, Learn how to verify the integrity and authenticity of an ISO image in Linux using checksums and GPG It's practically mandatory if you enjoy tinkering with Linux distributions, custom installers, or security-oriented systems. The procedure is a bit daunting at first (keys, signatures, checksums), but once you understand what each element is and follow a specific order, it becomes a simple habit that takes less than two minutes.
What are we really checking when we verify an ISO?
Before we start using commands, it's important to be clear about what problem we're trying to solve.On the one hand, it's important to verify that the ISO file wasn't corrupted during download (integrity), and on the other hand, that the ISO was actually published by the project team and not by an attacker (authenticity). These are two distinct objectives and are therefore checked using different mechanisms.
Integrity Check It answers the question: “Is the file I have on my disk exactly the same as the one the server offered when I clicked download?” This is where the checksums calculated with algorithms such as SHA1 or SHA256, which generate a unique code associated with the file content.
Authenticity verification with GPG It adds another layer: "Where does this checksum list or this ISO come from?" That's what they're used for. GPG digital signatures, performed with private keys of the developers and verified with their public keys, which we can obtain from key servers or from the project's official website.
An attacker who manages to compromise a mirror or a server could modify both the ISO and the checksum file. so that the codes match, so relying solely on the checksum isn't enough for serious security. That's where GPG comes in as an essential element.
When everything is properly configured, the "healthy" flow is always the same.First, you download the ISO, then you download the corresponding checksum file and the GPG signature file, you verify the signature to ensure that the checksum file is legitimate, and finally, you compare the sum of the ISO with that of the validated file.
Types of files you will find when downloading an ISO
When you enter the downloads page of a modern GNU/Linux distributionAlongside the ISO, several additional links often appear that many people ignore. They usually have names like SHA256SUMS, SHA256SUMS.gpg, .sig, .sha1sum or similar. Understanding what each thing is saves you a lot of headaches.
1. ISO fileThis is the system image itself, the "all-in-one" package that you'll later burn to a USB drive or install in a virtual machine. There's no mystery here: it's the large file with the extension . . Iso, for example ubuntu-20.04-desktop-amd64.iso o manjaro-xfce-0.8.1-x86_64.iso.
2. Checksum files (SHA1, SHA256…)These are text files containing one or more lines with the hash of each published ISO. In some distributions, the name is generic, such as SHA256SUMSIn others, a file is generated per ISO, such as manjaro-xfce-0.8.1-x86_64-sha1.sum o manjaro-xfce-0.8.1-x86_64-sha256.sum.
3. GPG Signature FilesThese are digital signatures that certify the authenticity of the accompanying file. They can have an extension. .gpg (for example, SHA256SUMS.gpg) or .sig (as archlinux-2016.03.01-dual.iso.sigIn some projects, the ISO is signed directly; in others, the checksum file is signed.
4. Developers' public keysThese are not usually downloaded from the same downloads page, but you will need them. They are usually documented on the official website or in the documentation, and are also distributed via key servers such as keyserver.ubuntu.com o pgpkeys.mit.edu, which GnuPG knows how to connect to.
It is crucial that you download all these files from the same "official" source. (distro's main page, trusted mirror, linked documentation), avoiding third-party sites or download portals that might tamper with the files or serve manipulated versions. To minimize risks, use official mirrors and secure transfers with tools like FileZilla.
Why MD5, SHA1 and SHA256 are not the same
Checksums are based on cryptographic hash algorithmsThese tools take a file as input and return a string of characters (the hash) that changes drastically if the file's contents are modified even slightly. This allows for the detection of corruption or alterations.
MD5 and SHA1 were the "classic" algorithms for many yearsAnd you'll still see them on some older project websites today. However, both have become obsolete for security purposes because potential collisions (two different files with the same hash) have been demonstrated.
SHA256 and other variants of the SHA-2 family (SHA-384, SHA-512, etc.) They offer much greater security against known collision attacks. That's why modern distributions often publish SHA256SUMS and, in some cases, also SHA1 for compatibility or as an additional reference.
In the context of ISO verification, it is always recommended to use SHA256 When it's available, especially if you're not clear on the difference between SHA1 and SHA1. Using SHA1 isn't "horrible" for a simple integrity check, but if you're looking for best practices, SHA256 is the sensible choice.
Remember that these algorithms only guarantee that the file has not changed from what was used to generate the checksumBut they don't tell you anything about who generated that checksum. For that, you need the GPG part and digital signatures.
Verify integrity with checksums in Linux step by step
In most GNU/Linux distributions, you have the necessary command-line utilities by default. to calculate SHA1 and SHA256 sums: sha1sum y sha256sumIf for some reason you don't have them, they belong to the coreutils package, which is usually installed by default. If you're unsure of the type of file you have, consult methods for identify file type.
1. Download the ISO and its checksum file from the official website. For example, on Manjaro you could download manjaro-xfce-0.8.1-x86_64.iso together with manjaro-xfce-0.8.1-x86_64-sha1.sum I manjaro-xfce-0.8.1-x86_64-sha256.sum.
2. Make sure both files are in the same directoryIf your browser saves them in DownloadsOpen a terminal and navigate to that folder using something like:
cd Downloads
3. Open the checksum file with a simple text editor (Gedit, Kate, Xed, whichever you have handy) to see the expected hash string. You'll see a line like this:
hash_code name-of-the-iso.iso
4. Calculate the ISO hash using the appropriate command to the algorithm indicated in the filename. For example, for SHA256:
sha256sum manjaro-xfce-0.8.1-x86_64.iso
The program will print a long code (a string of numbers and letters) followed by the file nameYou just need to compare that code with the one in the file .sha256sumIf they are identical, the downloaded file is intact; if there is even a single difference in any character, it means that the ISO has been corrupted or that it does not correspond to that checksum.
If you want to automate it a bit more, some files like SHA256SUMS allow you to use sha256sum with the -c option, which compares all the lines in the file at once against the files present in the folder:
sha256sum -c SHA256SUMS
In this case, you will see an output like this: ubuntu-20.04-desktop-amd64.iso: Sum matches indicating that everything is correct. If there is a problem, the program will warn you that the sum does not match.
Use GPG to verify signatures and public keys
So far we have only verified that the ISO you have matches the checksum you downloadedBut we still don't know if that checksum file is legitimate. To complete the security circle, the following come into play GnuPG (gpg) and digital signatures.
The first thing is to have GnuPG installed.which is included by default in most distributions. If you don't have it, you can install it using your system's package manager (apt, dnf, pacman, etc.). Once available, the typical workflow is: import the distribution's public key, verify the signature of the checksum file, and only if the signature is correct, use that file to verify the ISO.
Let's look at a classic example with Arch Linux, which directly signs the ISO with a file .sigAssume you have downloaded archlinux-2016.03.01-dual.iso and its corresponding archlinux-2016.03.01-dual.iso.sig.
1. Try verifying the ISO signature with gpg:
gpg –verify archlinux-2016.03.01-dual.iso.sig archlinux-2016.03.01-dual.iso
The first time, GPG will almost certainly complain that it doesn't have the public key. necessary to validate that signature and will show something like: Unable to verify signature: No public key along with a key identifier (for example, 9741E8AC).
2. Import the public key from a key server using that ID that GPG itself gave you. For example:
gpg –keyserver pgpkeys.mit.edu –recv-key 9741E8AC
By doing so, you will see that a public key associated with the corresponding developer is downloaded.For example, “Pierre Schmitz ”, along with a validity and trust summary. At this point, GPG is simply telling you who is signing, not whether you trust that person.
3. Run the verification command again about ISO and its signature:
gpg –verify archlinux-2016.03.01-dual.iso.sig archlinux-2016.03.01-dual.iso
You should now see a message like “Successful signature of “This indicates that the ISO has been successfully signed with the private key associated with that public key. GPG will also display a warning similar to: ATTENTION: This key is not certified by a trusted firm!.
That warning means that, even if the signature is cryptographically validYour personal web of trust hasn't yet verified that the key belongs to the person it claims to be. For a home user, the usual practice is to check that the fingerprint matches what the distribution itself documents on its website, or that the key is signed by the... MasterKeys or key project elements.
Practical example with Ubuntu: SHA256SUMS and SHA256SUMS.gpg
Ubuntu and many other distributions follow a slightly different schemeInstead of signing each ISO separately, they publish a global file (for example, SHA256SUMS) which contains all the SHA256 hashes of the ISOs, and then a signature file SHA256SUMS.gpg.
1. Download the ISO, the SHA256SUMS file, and its signature SHA256SUMS.gpg From the official downloads page. Place everything in the same folder and open a terminal in that directory.
2. Verify the signature of the checksums file running:
gpg –keyid-format long –verify SHA256SUMS.gpg SHA256SUMS
If you don't yet have your Ubuntu public key, GPG will notify you again. that it cannot verify the signature. The official documentation usually indicates which key ID you should import. A typical example is:
gpg –keyid-format long –keyserver hkp://keyserver.ubuntu.com –recv-keys 0xD94AA3F0EFE21092
Once the key has been imported, you repeat the signature verification command on SHA256SUMSIf everything goes well, you'll see a message like this: Correct signing of «Ubuntu CD Image Automatic Signing Key (2012) ».
3. Now check that your ISO matches the sum published in that already verified file using the automatic check mode of sha256sum:
sha256sum -c SHA256SUMS
The program will traverse the lines of the file. And, if the corresponding ISO is in that directory, it will display something like: ubuntu-20.04-desktop-amd64.iso: Sum matchesAt that point you know that the ISO is complete and that the checksum file you compared it to is signed by the official Ubuntu key.
The Manjaro case: -sha1.sum and -sha256.sum files
Manjaro and other similar distributions often provide a checksum file for each ISO. and for each algorithm, with names that leave little room for doubt, for example manjaro-xfce-0.8.1-x86_64-sha1.sum o manjaro-xfce-0.8.1-x86_64-sha256.sum.
The reading is simple: the “sha” part of the name comes from “Secure Hash Algorithm”The number (1, 256…) indicates the algorithm version. SHA1 is the most widespread classic version, while SHA256 is a more modern and robust version.
To verify integrity with Manjaro, the basic flow is this:Open the .sum file with a text editor, note the hash, and run the corresponding command in the terminal, for example:
sha256sum manjaro-xfce-0.8.1-x86_64.iso
You compare the generated code with the one shown in the -sha256.sum fileIf they match, the ISO is fine; if not, something has gone wrong and you should delete the file and download it again. It's recommended to use SHA256 if you're unsure which hash to choose, precisely because it's more resistant to potential attacks.
In Windows or macOS environments, where these utilities are not included by default, you can use external tools. like Quick Hash or other hash verification applications, which offer a graphical interface to do exactly the same thing: generate the ISO hash and compare it to the published one. A guide is available for Windows users. Verify integrity with Sigcheck.
The usual mess with Linux Mint and GPG verification
One case that generates a lot of confusion is that of the official Linux Mint guidewhere integrity verification steps (with SHA256) and authenticity verification (with GPG) are mixed in a way that many users find unintuitive.
The guide usually suggests something like thisYou download the ISO, the SHA256 checksum file in text format, and the GPG signature of that SHA256 file. First, you run a command that calculates the SHA256 checksum of the ISO and manually compare it with the contents of the .txt file. This, of course, only verifies that the ISO hasn't been corrupted during the download.
Next, you are instructed to import the Linux Mint signing key. and verify the signed SHA256 file (the .gpg) against the contents of the .txt file. This confirms that the official SHA256 hash has not been tampered with and is signed with the project key.
The problem is that, if it's not explained properly, it seems like GPG should be directly verifying the ISO.However, what it actually does is guarantee the authenticity of the checksum file. If you, for example, repeat the entire process without downloading the ISO, you'll see that the GPG verification of the SHA256 file still works the same, because GPG only checks the signature of that file, not the existence of the ISO.
The correct way to understand it is as a process in two independent layersFirst, you verify the legitimacy of the checksum file with GPG (authenticity), and only then do you use that file as a reference to check the ISO with SHA256 (integrity). If either layer is missing, you lose some protection.
Typical errors and best practices when verifying ISOs
There are a number of very common mistakes people make when they first encounter checksums and GPG.And it's useful to know them in order to avoid them. Most have more to do with the logic of the process than with the commands themselves.
1. Believing that checking only the checksum is sufficientAs we've already mentioned, an attacker who controls the server can modify ISOs and checksums simultaneously. The hash matches, yes, but everything is manipulated. That's why it's vital to rely on GPG and official keys when dealing with important distributions.
2. Do not download files from the official website or accredited mirrorsIf you download ISOs or summaries from third-party websites, forums, or YouTube videos that link to suspicious sites, you completely lose trust in the source. Even if you later verify the hashes, those hashes could have been generated by the attacker themselves.
3. Ignoring GPG warnings about untrusted keysWhen GPG warns you that the key is not certified by a trusted signature, it doesn't mean the signature is fake, but it does mean you don't yet have strong guarantees that the key belongs to the developer. It's always worth checking the key's fingerprint on the official website or with the distribution's documentation.
4. Do not delete an ISO file whose hash does not matchIf the checksum doesn't match the expected one, there's no middle ground; that file isn't reliable. You should delete it and download it again from an official source, preferably using a different mirror in case the problem is with the server.
5. Trusting tutorials that mix concepts or fall shortThere are videos and guides that simply check the ISO hash against any random text file, or that sign things without clarifying what's actually being authenticated. If you want to be sure, follow the official documentation for each distribution or guides that clearly explain what each step does.
Applying this set of checks systematically Before burning an ISO or using it in VirtualBox, you greatly reduce the likelihood of encountering corrupted installations, random errors, or, most worryingly, images manipulated for malicious purposes.
Special case: distributions highly focused on security
In projects with a strong focus on security, such as Qubes OS or some very hardened variants of LinuxThe verification procedure is usually even stricter, with several chains of trust, different master keys, and very detailed documentation on how to check each step.
In these environments, using GPG is not an optional extra, but part of the basic installation process.The developers go to great lengths to explain how to import their keys, how to verify that these keys are signed by higher-level keys (the famous master keys), and how to check the integrity not only of the ISO, but also of the templates, updates, and additional packages.
If you're already used to checking things like Qubes OS or tools like MullvadYou'll likely find that the guides for some more general-purpose distributions fall short or are somewhat confusing, as is the case with Linux Mint. In those instances, applying the mental process of "GPG signature of the checksum file + checking the ISO against that file" will clear things up for you.
The important thing is that you understand that GPG doesn't "look" at the actual contents of the ISO in an antivirus-style way.What it does is guarantee that the signed file (whether it's the ISO itself or the hash file) has not been modified since the author signed it and that the signature comes from the private key associated with the public key that you imported.
Once you've internalized that concept, you can easily adapt what you've learned to any layout.although each one organizes its sum and signature files somewhat differently or uses different key servers.
If you turn this process into a small ritual every time you download a new ISOYou'll gain peace of mind and reduce unnecessary risks. Ultimately, it's just three interconnected steps: download the ISO and its checksum and signature files from a reliable source, validate the checksum file's authenticity with GPG, and finally, confirm with SHA256 (or the relevant algorithm) that the ISO matches what the developers originally published.
