April 23, 2026 · 13 min read cybersecurity linux explainer tech-basics security ·

How Do You Know That Download Is Safe? Checksums, GPG, and File Integrity Explained.

Some links in this article are affiliate links. We may earn a small commission if you purchase through them, at no extra cost to you. See our privacy policy for details.

TL;DR: A checksum (SHA-256 or SHA-512) tells you whether a file arrived intact. A GPG signature tells you whether the publisher is who they claim to be. You need both. Use sha256sum on Linux, Get-FileHash on Windows, and gpg --verify for signatures. This post walks through the full process using an Ubuntu ISO as the example.

You Downloaded It. Now What?

You are setting up a new Linux machine. You head to the Ubuntu website, grab the ISO, and burn it to a USB drive. Twenty minutes later you are installing an operating system. Simple.

But here is what you did not ask: how do you know that file is actually what Ubuntu says it is?

Maybe the download got corrupted halfway through a flaky connection. Maybe you grabbed it from a mirror hosted in a country you have never heard of, maintained by someone you have never met. Maybe, in a worst-case scenario, someone along the way swapped the file for something else entirely.

That is not paranoia. That is the threat model. The Supply Chain Attack is a real and growing category, and software distribution is exactly the target. The gap between “I clicked download” and “I ran the installer” is where the attack lands.

The tools to close that gap are checksums and GPG signatures. They are not complicated. Most IT professionals use them automatically. After this post, so will you.

What Is a Checksum?

Think of a Checksum as a fingerprint for a file.

A hashing algorithm takes a file, processes every single byte in it, and spits out a fixed-length string of characters. That string is the hash, or checksum. For SHA-256, it is always 64 characters long. For SHA-512, it is 128.

The critical properties:

Same input, same output. Every time. Run SHA-256 on the Ubuntu ISO on your machine, then run it on someone else’s machine in another country. If the file is identical, the hashes are identical. Character for character.

One bit changes, everything changes. If a single byte in a 4 GB ISO gets corrupted during download, the resulting hash is completely different. Not slightly different. Unrecognizably different. This is not an accident; it is a property these algorithms are specifically designed to have.

A real SHA-256 hash looks like this:

a435f6f393dda581172490eba797417a84c1a45d42f4e94c441bd1aa43ab9ef

Just a string of hexadecimal characters. Meaningless-looking, but completely deterministic. That specific string maps to one specific file state, and no other.

SHA-256 vs SHA-512: Both are members of the SHA-2 family. SHA-256 produces a 256-bit hash; SHA-512 produces a 512-bit hash. SHA-512 is slightly more collision-resistant in theory, but for download verification either one is more than sufficient. You will encounter both in the wild. The algorithm does not matter as long as you use the same one the publisher used.

You will also see MD5 hashes in older documentation. MD5 is broken for security purposes. Do not rely on it for anything beyond basic corruption detection.

How to Verify a Checksum

The process is the same regardless of what you are verifying: download the file, get the expected hash from the publisher, run the hash yourself, compare.

On Linux

# Compute the SHA-256 hash of your downloaded file
sha256sum ubuntu-24.04-desktop-amd64.iso

That outputs something like:

a435f6f393dda581172490eba797417a84c1a45d42f4e94c441bd1aa43ab9ef  ubuntu-24.04-desktop-amd64.iso

Now you compare that string against the one published on the official Ubuntu release page. They must be identical. Not close. Identical.

If they do not match: do not use the file. Delete it. Re-download. Check again.

On Windows (PowerShell)

# Compute the SHA-256 hash of the downloaded file
Get-FileHash .\ubuntu-24.04-desktop-amd64.iso -Algorithm SHA256

PowerShell returns a table with the Algorithm, Hash, and Path. Copy the Hash value and compare it against the publisher’s published hash. Same rule: identical or bust.

The Faster Way (Linux)

If the publisher provides a checksum file (a text file with hashes for multiple downloads), you can verify automatically:

# -c checks every hash in the file against the corresponding local file
sha256sum -c SHA256SUMS

If the hashes match, you will see ubuntu-24.04-desktop-amd64.iso: OK. If they do not, you will see FAILED. Act accordingly.

The Problem Checksums Alone Do Not Solve

A checksum proves integrity. It does not prove authenticity.

Those are different things. Integrity means the file was not corrupted or modified in transit. Authenticity means the file actually came from the publisher you think it did.

Here is the attack that breaks checksum-only verification: an attacker compromises the website hosting the download. They replace the ISO with a malicious one. They also update the published checksum to match their malicious file.

Now you download the tampered ISO, run sha256sum, compare against the published hash, and see a perfect match. You install it. The attacker wins.

A checksum cannot help you here because the publisher of the checksum and the publisher of the file are the same compromised server.

This is where GPG signatures enter the picture.

What Is GPG Signing?

GPG stands for GNU Privacy Guard. It is an implementation of OpenPGP, a standard for cryptographic signatures and Encryption .

To understand what it does, you need to understand asymmetric cryptography at a high level. Do not worry: no math required.

Asymmetric cryptography uses a pair of mathematically linked keys: one private, one public.

The private key is a secret. The publisher generates it, guards it carefully, and never shares it with anyone.
The public key is shared with the world. The publisher posts it on their website, on key servers, in documentation, anywhere.

When a publisher wants to sign a file, they run it through GPG with their private key. This produces a signature: a block of cryptographic data that proves the file was processed by whoever holds that private key.

When you want to verify that signature, you use the publisher’s public key. GPG checks the signature against the file. If the verification passes, you know two things: the file has not been modified since it was signed, and it was signed by whoever controls the corresponding private key.

Think of it like a wax seal on an envelope. Anyone who has ever seen the seal knows what it looks like. They can verify it is genuine. But only the sender has the stamp. Anyone can check; only one person can create.

For software distribution, the typical flow works like this: the publisher signs the checksum file (not the ISO itself) with their private key. The checksum file lists the expected hashes for all the download files. The signature proves that checksum file came from the publisher, unchanged.

So the chain is: GPG verifies the checksum file is authentic. The checksum verifies the ISO is intact. Combined, they give you both authenticity and integrity.

Full Walkthrough: Verifying an Ubuntu ISO

This is the complete process, start to finish.

Step 1: Download the ISO

Get the ISO from any source you like. An official mirror, a Content Delivery Network , a torrent. It does not matter. The verification process will catch any tampering regardless of the source.

# Your downloaded ISO sits here
ls ubuntu-24.04-desktop-amd64.iso

Step 2: Download the Checksum File and Signature

These must come from the official Ubuntu release server, not a mirror.

# Checksum file listing expected SHA-256 hashes for all Ubuntu 24.04 downloads
wget https://releases.ubuntu.com/24.04/SHA256SUMS

# GPG signature file for the checksum file
wget https://releases.ubuntu.com/24.04/SHA256SUMS.gpg

The SHA256SUMS file is a plain text list of hashes. The SHA256SUMS.gpg file is the cryptographic signature that proves that text file is legitimate.

Step 3: Import the Ubuntu Public Key

Ubuntu’s signing key is published publicly. Import it from the Ubuntu key server:

# Import Ubuntu's signing key by its key ID
gpg --keyid-format long --keyserver hkp://keyserver.ubuntu.com \
  --recv-keys 0x843938DF228D22F7B3742BC0D94AA3F0EFE21092

You can find this key ID in Ubuntu’s official security documentation, cross-referenced across multiple sources. More on why that matters in a moment.

Step 4: Verify the Signature on the Checksum File

# Verify that SHA256SUMS was signed by the Ubuntu key you just imported
gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

A passing result looks like this:

gpg: Signature made Wed 20 Mar 2024 ...
gpg: using RSA key 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: Good signature from "Ubuntu CD Image Automatic Signing Key (2012) <cdimage@ubuntu.com>"

The phrase “Good signature” is your green light. GPG verified that the SHA256SUMS file was signed by the Ubuntu team’s private key. Nobody else could have produced that signature.

A failing result looks like:

gpg: BAD signature from "Ubuntu CD Image Automatic Signing Key ..."

“BAD signature” means the SHA256SUMS file was modified after it was signed. The file has been tampered with. Stop. Do not proceed. Do not trust any hash in that file.

You may also see a warning that the key is not certified with a trusted signature. That is expected if you have not explicitly told GPG to trust Ubuntu’s key. The signature is still valid. The warning is about the web of trust, covered briefly below.

Step 5: Verify the ISO Against the Checksum

# Check the ISO against the hashes in the now-verified checksum file
sha256sum --check SHA256SUMS --ignore-missing

The --ignore-missing flag tells sha256sum to skip entries in the file for ISOs you did not download. Without it, every missing file produces an error.

Output:

ubuntu-24.04-desktop-amd64.iso: OK

That is the clean result. Your ISO is exactly what Ubuntu built and signed off on.

What Can Go Wrong

The verification process handles several distinct failure modes, and the cause matters.

Corrupted download. The most common scenario. Bytes got mangled in transit. The checksum will not match. Re-download the file and verify again. Nothing malicious happened; data transfer is not perfectly reliable.

Compromised mirror. An attacker replaces the ISO on a third-party mirror with a malicious version. The checksum from the official source does not match the file from the mirror. You catch it. The GPG-verified checksum file is your source of truth.

Man-in-the-Middle Attack . An attacker intercepts your download at the network level and substitutes a different file. The checksum catches it. If they also try to substitute the checksum file, the GPG signature catches that.

Compromised website. An attacker gains access to the publisher’s web server and replaces both the ISO and the checksum file. The GPG signature catches it. They cannot forge the signature without the private key, which never touches the web server.

Stale checksum. The publisher updated the file but forgot to update the published hash. The checksum will not match even though nothing malicious happened. If verification fails and you have no reason to suspect a compromise, contact the publisher and verify. Do not assume malice before ruling out sloppiness.

The Trust Problem

There is one question left: how do you trust the public key?

You imported a key from a key server. But who put that key there? What if someone published a fake Ubuntu key?

The answer is: cross-reference. Do not trust a single source.

Check the key ID in Ubuntu’s official documentation. Check it in their release announcements. Check it on Stack Overflow, security forums, mailing list archives. The more independent sources agree on the same key ID, the harder it is to fake.

This is the foundation of what GPG calls the “web of trust”: other trusted parties vouch for keys by signing them. It is a fundamentally different model from SSL/TLS , which centralizes trust in certificate authorities managed by browsers and operating systems. Neither approach is perfect; both are practical for their respective use cases.

For most practical verification purposes, cross-referencing the key ID across multiple independent sources is enough. If six different places all publish the same key ID and it has been stable for years, a substitution attack would require compromising all of them simultaneously.

That is not impossible in theory. In practice, it is not a realistic threat vector for software you are downloading.

Bonus: What File Metadata Tells You

While you have a terminal open, there is one more tool worth knowing: stat.

# Show detailed file metadata including timestamps
stat ubuntu-24.04-desktop-amd64.iso

Output includes four timestamps:

Access (atime): Last time the file was read.
Modify (mtime): Last time the file’s content was changed.
Change (ctime): Last time the file’s metadata or content changed (includes permissions, ownership, rename).
Birth: When the file was created on this filesystem.

These timestamps tell you where the file has been. If you copy a file over SCP to a remote server, the Birth and Change timestamps reflect the transfer time on the destination. The Modify time is typically preserved from the source. That gap tells you the file was copied, not created locally.

Why does this matter? Timestamps are not security controls. An attacker can forge them. But in forensic investigation, a mismatch between Birth and Modify timestamps is a signal worth examining. A file whose Modify time predates its Birth time was almost certainly copied from somewhere else.

Connect this to the broader picture: timestamps tell you where a file has been, checksums tell you whether it changed, and GPG tells you who it came from. Together they are a complete story.

Hash for Integrity, Signature for Authenticity

That is the whole framework.

When you download software, you are extending trust to a chain of systems: the publisher’s build server, their web infrastructure, the mirrors, the network path to your machine. Every link in that chain is a potential point of failure, accidental or deliberate.

Checksums and GPG signatures give you a way to verify that chain without trusting any of it blindly.

This is not advanced security work. It is baseline hygiene. Professional systems administrators verify downloads automatically. They write it into their runbooks. They do not debate whether it is worth the 90 seconds it takes.

The professionals who skip it are the ones writing incident reports.

Make it a habit: download, verify, then install. Not sometimes. Every time.

Want to go deeper? BytesNation covers the full security stack: from file verification and PKI to firewall architecture and threat detection. Check the blog for more, or explore the IT Dictionary for plain-English definitions of every term you encountered here.

Share this post

X LinkedIn Reddit Facebook