The most dangerous moment in Monero security is not a network attack. It is the five seconds when you download a wallet, glance at the file, and double-click it. If that file came from a spoofed domain, a mirrored download site, or a tampered mirror, you just handed your seed words to someone else. Monero has no central authority that can reverse that. Verification takes three minutes and closes the biggest hole in the whole setup.
What you are actually checking
There are two separate checks, and they prove different things.
Step 1: the hash. A SHA-256 hash is a fingerprint of the exact file you downloaded. If one byte differs, the hash is completely different. Checking the hash proves the file you have is bit-for-bit the file that was released. It does not prove the release is genuine. If an attacker built a poisoned wallet and published its hash on their own site, your hash would match perfectly and your wallet would still be compromised.
Step 2: the GPG signature. The Monero maintainers cryptographically sign each release binary with a private key. If the signature verifies against the published signing key, you have proof the release came from someone holding that key, and that the hash file was not altered after signing. This is the check that actually matters.
The procedure, start to finish
Download three things from the official getmonero.org: the installer itself, the hashes.txt file (sometimes called a bare hash list), and the detached signature file for the hashes. Keep them in one folder.
Import the binary fingerprint signing key. The Monero project publishes the key ID on its release page; the current long-serving signing key has ID F0AF449690516A7A, binaryfate. From a terminal:
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys F0AF449690516A7A
Check the fingerprint shown against the one published on getmonero.org itself, not on a forum or a third-party mirror. If the fingerprints match, trust the key locally:
gpg --lsign-key F0AF449690516A7A
Now verify the signed hash list against the signature:
gpg --verify hashes.txt.sig hashes.txt
You want to see Good signature from "binaryfate". A warning that the key is not certified with a trusted signature is normal for a self-managed web of trust; the fingerprint match you did in the previous step is what settles it.
Only now check your download against the list:
sha256sum monero-gui-win-x64-v0.18.4.4.zip
Compare the output to the matching line in hashes.txt. On Windows, certutil -hashfile yourfile.zip SHA256 does the same job. On macOS, shasum -a 256 yourfile.zip.
Why the order matters
Verify the signature on hashes.txt before you trust the hashes. If you skip straight to comparing hashes, you are trusting the hash list on its own, and a man-in-the-middle who could swap your installer could just as easily swap the hash list. The GPG signature pins the hash list to the signer. Without that pin, the whole exercise is theatre.
What about the CLI, mobile wallets and builds from source
The same procedure covers every official artifact. The CLI tarball, the hashes file and its signature live beside the GUI download, and the same key signs them all. Mobile wallets downloaded from an app store shift part of the job to Apple or Google, who sign the packages themselves, but the release notes still publish the expected version and hash, and checking the version string inside the wallet against the release notes catches spoofed or abandoned listings. For anyone building from source, verify the signed tag on the git repository (git tag -v v0.18.4.4) rather than trusting a cloned copy, then build from that tag. The principle does not change with the platform: pin the artifact to the signing key before you run it, on every platform you use.
Common failure modes
“No public key” errors. The keyserver was flaky or the key ID was mistyped. Try a different keyserver, hkp://keys.openpgp.org, and retype the ID. Never download a signing key from a mirror site to save time.
Hash mismatch. Do not rationalise it. Redownload from getmonero.org over a clean connection and check again. If it still mismatches, stop, and report it. A mismatch means either your download corrupted or the file you have is not the released file. Neither is something to install.
Old signing key cached locally. If you verified releases years ago, your keyring may hold a stale or revoked key. Run gpg --list-keys and refresh with gpg --refresh-keys before assuming the project’s key changed.
Where this fits in the wider routine
Verification is a habit, not a one-off. Every wallet update, every CLI tool, every time you move to a new machine, the same three-minute check applies. It pairs with the rest of a sane setup: once the verified wallet is installed, the address types you use for receiving matter (primary, subaddress and integrated addresses), and if you are rebuilding on new hardware, restore from seed rather than copying wallet files (here is what a seed restore actually recovers).
The uncomfortable truth about trust
Even this procedure rests on one assumption: that the getmonero.org domain you visited is the real one, and that the fingerprint page you compared against was not itself substituted. That assumption is reasonable, because the domain is the project’s longest-held public identity and the fingerprint is published in multiple independent places, including the source repository history. But it is an assumption, and it deserves to be named. What GPG verification buys you is protection against tampered mirrors, corrupted downloads, and swapped binaries. It reduces your trust in a hundred download points down to trust in one well-watched key. That is a large improvement, stated honestly.
Three minutes, two checks in the right order, one habit. The version of you that loses coins to a tampered download never took those three minutes. Do not be that version.