Installation Verification Using GPG Signatures: Complete Technical Guide for Paranoid Users

A Bitcoin user downloads Wasabi Wallet from what appears to be the official site, installs it, and begins transacting. Months later, they discover that the binary they installed was intercepted and modified by an attacker who had no need to compromise the actual servers—a man-in-the-middle attack, a DNS hijack, or a compromised mirror was enough. The user’s private keys were logged, and their anonymity was compromised from the first transaction. This scenario is not hypothetical. Software distribution is a real attack surface, and the defense is verification: confirming that the installer you hold matches the one the developers released.

Wasabi Wallet’s open-source architecture and commitment to user control mean that verification is not merely recommended—it is part of the security model. The developers publish cryptographic signatures alongside each release, allowing anyone with the correct tools to prove that an installer has not been altered since the developers signed it. That proof requires understanding GPG (GNU Privacy Guard), fingerprint checking, and command-line verification steps that many users skip because they seem complicated. Skipping them trades convenience for the exact exposure that a privacy wallet is meant to prevent.

Why signature verification matters for a privacy wallet

Wasabi Wallet integrates CoinJoin technology to mix transactions and break the link between a user’s identity and their Bitcoin transfers. That privacy benefit only exists if the wallet software is authentic and unmodified. A compromised binary defeats every other control. Hardware wallet integration, two-factor authentication, and end-to-end encryption are all rendered useless if the application running on your computer is logging your private keys or broadcasting your transactions in plaintext to an attacker’s server.

The threat is not merely theoretical. Supply chain attacks have successfully modified legitimate software distributions by compromising build systems, signing credentials, or distribution channels. A user who downloads an installer and launches it without verification is trusting that no attacker was positioned between them and the server, that the server itself was not compromised, and that the development infrastructure was never breached. Each assumption narrows the margin of safety.

GPG signatures provide cryptographic proof of authorship and integrity. When the Wasabi developers sign a release with their private key, they create a signature that can only be produced with that key. Anyone with the corresponding public key can verify that the signature matches the installer. A single bit changed in the installer will cause verification to fail. This is not a guarantee that the developers did not introduce a backdoor themselves, but it is a proof that the installer you hold is exactly what they released.

The distinction matters for operational security. A user can rely on verification to exclude entire categories of attack—network interception, server compromise, mirror poisoning, and accidental distribution of outdated versions. They must still evaluate whether the developers themselves are trustworthy, whether the open-source code is audited, and whether the build process is reproducible. But verification at least ensures they are evaluating the right artifact.

Setting up GPG and importing the Wasabi public key

GPG is available on Windows, macOS, and Linux. On Windows, the standard choice is Gpg4win, which includes Kleopatra (a graphical key manager) and the command-line gpg tool. On macOS, GPG can be installed via Homebrew using the command brew install gnupg. On Linux, it is usually pre-installed or available through the package manager: sudo apt-get install gnupg on Debian-based systems, or sudo dnf install gnupg on Fedora. After installation, verify that GPG works by opening a terminal or command prompt and typing gpg --version. A version number should appear.

Next, obtain the Wasabi public key. The Wasabi official site lists the signing key fingerprint and provides the public key file for download. The key fingerprint is a short representation of the full public key—typically displayed as a 40-character hex string (SHA-1) or 64-character string (SHA-256), depending on the version. For example, a fingerprint might appear as: E5D6 8C55 FCBA 59B7 1C36 4ECB AE92 FA22 8E76 45D2. This fingerprint is the critical checkpoint. It serves as a human-verifiable reference point. If this fingerprint does not match what you independently confirm, the key is not genuine.

Import the public key into your GPG keyring using the command: gpg --import wasabi-key.gpg (replacing the filename with the actual key file you downloaded). GPG will report that it has imported the key. Then, verify the fingerprint by running gpg --list-keys --with-colons and checking the output, or more readably with gpg --fingerprint. Compare the fingerprint shown in your terminal with the fingerprint published on the wasabi official site. They must match exactly. If they do not, the key file is corrupted or fraudulent, and you should not proceed.

This step—confirming the fingerprint—is where many users make a critical error. They assume that if a key imports without error, it is correct. That assumption is wrong. The verification happens only when you compare the displayed fingerprint with an independent, trusted source. If you downloaded the key from the same server you are verifying against, you have not solved the problem; an attacker who controls the server controls both the key and the signature. Ideally, confirm the fingerprint through multiple sources: the official Wasabi documentation, GitHub releases page, and a community forum post by a trusted community member.

Downloading the Wasabi installer and signature file

Visit the wasabi official site and locate the downloads section. For each installer (Windows .exe, macOS .dmg, Linux .deb, or browser extension), there is a corresponding detached signature file. This file typically has the same name as the installer plus a .sig extension. For example, if the installer is named Wasabi-2.0.0-Windows.exe, the signature file is Wasabi-2.0.0-Windows.exe.sig. Download both files to the same directory on your computer.

Do not skip downloading the signature file. The signature is a small text file (usually less than 1 KB) containing the cryptographic proof. Without it, you have no way to verify the installer. The directory structure might look like this:

~/Downloads/Wasabi-2.0.0-Windows.exe
~/Downloads/Wasabi-2.0.0-Windows.exe.sig

If you are on Windows and using File Explorer, the .sig file may not display a recognizable icon. That is normal. Open a command prompt (or PowerShell) and navigate to the directory containing both files using cd ~/Downloads (or the path where you saved them). List the files using dir (Windows) or ls (macOS/Linux) to confirm both are present. Then you are ready to verify.

Performing the signature verification

The verification command is straightforward. In your terminal or command prompt, navigate to the directory containing the installer and signature file, then run: gpg --verify Wasabi-2.0.0-Windows.exe.sig Wasabi-2.0.0-Windows.exe. Replace the filenames with the actual names of your files. GPG will check the signature and report the result.

A successful verification produces output similar to:
gpg: Signature made Fri Jan 17 10:30:45 2025 UTC
gpg: using RSA key E5D6 8C55 FCBA 59B7 1C36 4ECB AE92 FA22 8E76 45D2
gpg: Good signature from "Wasabi Wallet <contact@wasabiwallet.io>" [unknown]

The phrase “Good signature” is the key indicator. This means the signature is valid and the installer has not been modified since the developers signed it. The fingerprint shown in the output should match the fingerprint you verified earlier. The “[unknown]” designation simply means you have not explicitly told GPG to trust the key; that is expected and does not indicate a problem.

A failed verification produces output like:
gpg: BAD signature from "Wasabi Wallet <contact@wasabiwallet.io>"
or
gpg: Can't check signature: No public key

If verification fails, do not install the wallet. A bad signature means the installer has been modified, corrupted, or signed with the wrong key. A missing key error means the Wasabi public key is not in your keyring. Go back, confirm that the key was imported correctly, and verify the fingerprint again. If verification still fails after re-checking, delete the installer and signature files and download them again from a different network connection or different time of day (to rule out a local network attack).

Understanding the output and avoiding common mistakes

The GPG output provides three pieces of information worth understanding. First, the signature creation timestamp shows when the developers signed the release. This is informational and helps confirm you have the right version. Second, the key identifier and fingerprint confirm which key was used to sign. This should match the Wasabi key you imported. Third, the trust level (unknown, marginal, full, ultimate) reflects your trust settings in GPG, not the validity of the signature itself.

A common mistake is to assume that “[unknown]” trust means the signature is untrusted or invalid. This is incorrect. “Good signature” means the signature is cryptographically valid. Trust level is a separate concern that applies to future keys you receive from the same source. For critical first-time verification of a privacy wallet, you should verify the fingerprint independently without relying on GPG’s trust database.

Another mistake is downloading the signature file from a different source than the installer. If the signature comes from an attacker, it will appear to verify against a modified installer that the attacker has also signed with a fraudulent key. This is why fingerprint verification through multiple independent sources is essential. The attacker must compromise multiple sources to fool you.

A third mistake is verifying the wrong file. Ensure the command uses the exact installer filename you downloaded. If you renamed the file, the path in the command must match. If you moved the file to a different directory, move both the installer and signature file to the same location. Mismatched paths are the most common reason for “file not found” errors.

Finally, some users generate their own key and assume that verifying against their own key proves authenticity. This is useless. The verification must use the developers’ public key, available through the wasabi official site or GitHub. Your own key proves nothing about the installer’s origin. You can find out more about Wasabi’s distribution security practices and key management find out more through the official documentation.

Platform-specific verification examples

Windows with Gpg4win: After installing Gpg4win, open Kleopatra (the graphical key manager). Click “Clipboard” and paste the Wasabi public key. Kleopatra will import it and display the fingerprint. Verify the fingerprint matches the official source. Then, open a Command Prompt, navigate to the Downloads folder, and run the gpg command shown above. Alternatively, in Kleopatra, right-click the Wasabi key, select “Sign” or “Verify,” and use the file selection dialog to choose the installer and signature file. Kleopatra will display the verification result graphically.

macOS: After installing GPG via Homebrew, open Terminal and navigate to the Downloads folder where the installer and signature file are located. Run the verification command. If you prefer a graphical approach, GPGTools provides a macOS-native interface. After installation, the Keychain application integrates with GPG, and you can verify signatures through the context menu. Import the Wasabi key, verify its fingerprint, and then verify the installer signature.

Linux: Most Linux systems have GPG pre-installed. Open a terminal, navigate to the Downloads folder, and run the verification command directly. No additional software is required. For a graphical interface, use Seahorse (GNOME) or KGpg (KDE), which provide key management and signature verification through menus. Import the Wasabi key, verify the fingerprint, and then use the “Verify Signature” option to check the installer against its signature file.

Browser Extension Verification: If you are using Wasabi as a browser extension, follow the same process. The signature file will be available alongside the extension package. Download both, import the public key, verify the fingerprint, and run the signature verification command. After verification succeeds, install the extension from your browser’s extension menu.

What to do after successful verification

Once the signature verification succeeds with a “Good signature” message, you can safely install the wallet. On Windows, run the .exe file. On macOS, mount the .dmg file and drag Wasabi into the Applications folder. On Linux, install the .deb package using your package manager: sudo dpkg -i Wasabi-2.0.0-Linux.deb. For the browser extension, follow your browser’s installation prompt.

During the initial setup, Wasabi will prompt you to create a wallet or import an existing one. This is where your private keys are generated and stored locally on your device. The open-source architecture means you can review the code that generates and encrypts these keys. The hardware wallet integration allows you to use a Ledger, Trezor, or Coldcard device instead of storing keys on your computer, further isolating them from network-connected systems.

After installation, keep the installer and signature file. If you need to reinstall Wasabi on another machine or verify a newer version, you can follow the same process. For security updates or new releases, repeat the verification process. Do not skip it because you have verified Wasabi once before; each release must be verified independently. An attacker might compromise only certain versions or targeting specific users.

Finally, document your verification. Record the date you verified, the version number, the fingerprint you confirmed, and the output from the gpg –verify command. This creates an audit trail if you later need to demonstrate that you installed an authentic copy. For high-value accounts or paranoid users, photograph or print the verification output. The record proves that you performed due diligence, even if a compromise is discovered months later.

Advanced verification and reproducible builds

Signature verification proves that the installer matches what the developers released, but it does not prove that the developers’ build process was not compromised. A more advanced security model is reproducible builds: the source code is compiled, and the resulting binary can be independently verified to match the official release binary byte-for-byte. This proves that no malware was injected during the build process.

Wasabi’s build infrastructure is documented in its GitHub repository. Users with sufficient technical expertise can download the source code, follow the build instructions, compile the wallet themselves, and compare their binary hash to the official release. If the hashes match, the build was reproducible and no tampering occurred during compilation. If they do not match, the build system or dependencies were modified. Most users do not have the expertise or patience for this, but the option exists and strengthens the security model for those who need it.

Another layer is code auditing. Because Wasabi is open source, security researchers can review the code for vulnerabilities, backdoors, or dangerous cryptographic practices. Third-party audits are published and available in the repository. This does not guarantee security—audits can miss subtle vulnerabilities—but it distributes the trust burden. Instead of relying only on the developers’ integrity, security depends on a broader community of reviewers. If a critical vulnerability is discovered, the developers issue a patch, and you can verify and install it using the same GPG signature process.

Users interested in the deepest level of verification should explore the GitHub releases page, where installers, signatures, hashes, and build information are available. The source code is available under an open-source license. Community members have compared official builds to reproducibly compiled versions and published the results. These resources are not immediately accessible to non-technical users, but they exist for those who need evidence beyond signature verification.