Verifying Software Signatures

From Whonix


For greater system security the installation of unsigned software should be avoided at all costs. Instead it is recommended to:

What Digital Signatures Prove[edit]

Bear in mind that using digital signatures to verify the trustworthiness of software is not an infallible process. Digital signatures increase the certainty that no backdoor was introduced by a third party during transit, but this does not mean the software is absolutely "backdoor-free". The following is a summary of what digital signatures prove and do not prove.

Table: Digital Signatures Properties

Property Description
Digital Signatures Prove
  • Someone with access to the private key has made a signature.
  • The file contents have not been tampered with (preserving integrity).
  • May indicate the given file is authentic.
Digital Signatures do not Prove
  • Any other property, for example, that the file is not malicious. Nothing stops a person from signing a malicious program.
  • That persons signing the file are inherently trustworthy, for example, Microsoft, Whonix ™ developers and so on -- but trust must be eventually placed in someone. [1]

If all files downloaded from trusted vendors are verified, then this removes the threat of server compromises, dishonest staff at hosting companies or ISPs, Wi-Fi attacks and so on. The reason is files that have been tampered with will produce bad digital signatures, so long as the public keys used for signature verification are the authentic, original ones (see below).

Common Misconceptions[edit]

warning Check the GPG signature timestamp makes sense. For example, if you previously saw a signature from 2019 and now see a signature from 2018, then this might be a targeted rollback (downgrade) or indefinite freeze attack. [2]

warning Note: OpenPGP signatures sign files, but not file names. [3]

Checking Digital Fingerprints of Signing Keys[edit]

Ambox warning pn.svg.png Warning: Software should only be installed after a key's fingerprint has been verified and good signatures are produced for files/repositories.

A critical first step in verifying software is legitimate is confirmation that the signing key is authentic -- this requires inspection of the key fingerprint. [4] Always perform this operation before keys are imported or trust is placed in OpenPGP output when verifying files or repositories.

The standard Whonix ™ wiki advice is to carefully obtain copies of the OpenPGP fingerprint from multiple secure websites and to use other authentication systems to check they match. [5] In this instance, "other authentication systems" refers to: [6]

  • Use the The OpenPGP Web of Trust.
  • Check the key against different keyservers.
  • Use different search engines to search for the fingerprint.
  • Use Tor to view and search for the fingerprint on various websites.
  • Use various VPNs and proxy servers.
  • Use different Wi-Fi networks (work, school, internet cafe, etc.).
  • Ask people to post the fingerprint in various forums and chat rooms.
  • Check against PDFs and photographs in which the fingerprint appears (e.g., slides from a talk or on a T-shirt).
  • Repeat all of the above from different computers and devices.
  • See also Bootstrapping OpenPGP keys from the web

Checking Digital Fingerprints of Signed Software[edit]

Before file signatures can be safely verified with the signing key, several prerequisites must be met:

  1. The correct signing key pair was downloaded.
  2. The signing key's fingerprints were checked against multiple sources.
  3. The key pair was imported.
  4. The software package intended for installation was downloaded.
  5. The accompanying signature file for the software package (.asc files are GPG signatures) was downloaded.

The following example shows how the file signature is checked for Tor Browser bundle v8.5, directly downloaded from The Tor Project website.

In a terminal run.

gpg --verify tor-browser-linux64-8.5_en-US.tar.xz.asc tor-browser-linux64-8.5_en-US.tar.xz

The OpenPGP output should show a "good signature", with the primary key fingerprint matching the one verified by the user earlier on. In this example.

    gpg: Signature made Mon May 20 11:00:34 2019 UTC using RSA key 0xEB774491D9FF06E2
    gpg: Good signature from "Tor Browser Developers (signing key) <>" [unknown]
    gpg: WARNING: This key is not certified with a trusted signature!
    gpg:          There is no indication that the signature belongs to the owner.
    Primary key fingerprint: EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290
         Subkey fingerprint: 1107 75B5 D101 FB36 BC6C  911B EB77 4491 D9FF 06E2

The software can now be safely installed. If the output states "bad signature", then the files and digital signatures should be removed and downloaded again.

System Security Level[edit]

  • always software signatures verification security level: always verify software signatures (for example by using OpenPGP, codecrypt, APT)
  • always use TLS security level: always securely download files over TLS
  • plaintext security level

Once ever software was installed or started which was not previously successfully software signature verified the system security level is to be considered reduced from OpenPGP level security to TLS level security or even plaintext level security.

Unless a Disaster Recovery Procedure is applied, it is not possible to increase the security level of a machine or VM from let's say TLS level security to OpenPGP level security.

If you prudently consider Transport Layer Security (TLS) to be weak as recommended, software signatures need to be consistently verified. No exceptions ever.

Conceptual Challenges in Software Digital Signatures Verification[edit]

There are many educational shortcomings related to verification of software digital signatures. There are many implicit assumptions which are seldom spelled out. Realistically, expecting users to successfully verify software signatures and to notice attacks by advanced adversaries is very much likely to fail unless properly educated before the attack started.

Writing on an internet website "please download our signing key and verify our software signatures" has only limited usefulness. providing software signatures is just an example. This is the same for any software that provides software signatures.

Diligence in software signatures cannot be offered by vendors (those who offer software for download). Vendors can only offer software signatures. Diligence in verification of software signatures is something that only users can demand from themselves.

This is because of the threat model of software signature verification. The implicit assumption behind it are the different system security level. Implicit meaning, that the threat model is seldom explicitly spelled out and explained to users. This chapter attempts to make this explicit.

In this threat model, signing keys and software signatures are considered a higher security level. Everything the user can see on a website is on a lower security level. This is because there are not (OpenPGP) signed websites anywhere yet. And TLS is considered a lower security level too than verification of digital software signatures.

Let's assume there was a software. It's main website would be reachable over TLS. (In this very example TLS vs non-TLS does not even matter.) Due to file size and economic shortcommings it however is not possible to host software downloads on the same server. Software downloads are being offered on a mirror network, i.e. by third parties. In such an example it could be argued that mirrors are less trusted than the main project website. In that case if the main website offered a signing key then a malicious file shipped by a third party mirror could be detected if software signature verification was utilized by the user.

In case of other projects among which Whonix ™ is again just an example, everything, i.e. the software downloads, signing key and software signatures are provided by the same server over TLS (and in case of Whonix also over .onion, see also Download Security). No project however can promise that its server will never be compromised, see Distrusting Infrastructure for details.

Therefore blindly trusting whatever the project website says about software signature verification is a very bad idea. The threat model is to keep in mind, the question to ask is: What if the website I am currently seeing is already compromised? What if whatever the server is saying about instructions on how to verify software signatures, which signing key should be used has not sorely written by the vendor but maliciously modified by a third party? Advanced adversaries might after they compromised a project web server show fake website contents only to users they want to specifically target.

There are various attacks, various malicious modifications of the project website possible for an attacker:

  • Remove any mention of software signature verification and replace software downloads with malicious counterparts.
    • Users who never heard about software verification would have no chance to notice this and get compromised.
    • Users who already previously understood the threat model of digital software verification and wanted to enforce "always software signatures verification security level" would ask for software signatures and stay safe.
  • Mention a potential lie such as "from now on, software signatures are no longer required. This is now automatic, because ...".
    • Users who are gullible would believe this and get compromised.
    • Diligent users would search for a digitally signed message by the vendor confirming this. And if not found, report the issue and stay safe.
  • Replace the genuine signing key and software signatures with a signing key and software signatures created by the attacker.
    • Users who did not previously receive the singing key and who did not do further research the plausibility of having received the correct signing key would not notice this and get compromised.
    • Diligent users would follow the recommendations in earlier chapters on this page and therefore stay safe.

To counter these threats, user diligence is required as a sanity check.

Due to the complexity of this issue and the very low awareness, it is unlikely that a significant amount of users is enforcing "always software signatures verification security level". The concept of these security levels explicitly spelled out has never been seen before by the author of this chapter. Required knowledge is far too much. Usability of tools used for manual verification of software signatures is far too bad. Better technical solutions are required but these do not exist.

Attacks in the Wild[edit]

Virus Stealing Money[edit]

Fake Tor Browser[edit]

To illustrate the risk of installing unsigned software, consider the following attack which recently used a "trojanized" Tor Browser [archive] to spy on users and to steal Bitcoin. This attack had several elements: [7] [8]

  • Advertisements for the fake Tor Browser were used in Russian forums focused on privacy, censorship circumvention, darknet markets and cryptocurrencies.
    • Messaging included promises to circumvent Russian censorship bodies and to bypass CAPTCHAs.
    • Links were provided to fake domains for downloading Tor Browser ( and, instead of the genuine website:
  • After visiting the fake websites, users received warnings their Tor Browser was outdated (regardless of the reality). Users who believed this message were redirected to another website with an installer.
  • The malicious Tor Browser version downloaded was older (version 7.5) than the current release (9.0 at the time of writing), and had disabled the digital signature check for installed Tor Browser add-ons (xpinstall.signatures.required was set to false). It had also renamed the updater tool to prevent victims updating to a legitimate version of Tor Browser.
  • The Tor proxy was used in the browser, anonymizing the user's IP address. However, users could be spied upon because a custom user-agent (text-based identifer) was set that allowed the software and operating system to be visible -- a unique Fingerprint made tracking by network observers possible.
  • Attackers had bundled HTTPS Everywhere with a modified manifest.json file. This permitted the web extension to have broader permissions and to add content scripts that were loaded into various web pages. As a consequence, a Command and Control server [archive] could load further scripts when users browsed on certain Darknet markets and a commonly used Russian money transfer service (QIWI) -- changing cryptocurrency wallet addresses to match an addressed controlled by criminals in order to steal money.
  • It is also assumed the NoScript extension settings were modified so JavaScript was active when browsing.

This highlights the possible dangers of installing unsigned software -- loss of anonymity and financial loss in this case. If the victims had instead only installed signed Tor Browser software from trusted and known sources after: verifying they had the correct key pair, confirming the key's fingerprints, and checking the signature file for the software package matched, then they could have bypassed this scam entirely.

See Also[edit]


Gratitude is expressed to Qubes OS [archive] (Permission [archive]) (w [archive]). The What Digital Signatures Prove chapter contains content from the Qubes OS: What do the Digital Signatures Prove and What They DO NOT Prove [archive] page.


  1. Digital signatures are still useful in this case, because it is possible to limit trust to a few select people/organizations such as Whonix ™ developers.
  2. As defined by TUF: Attacks and Weaknesses:
  3. [archive]
  4. For example, anybody could generate an OpenPGP key pair and pretend to be the "Whonix ™ Project", but only Patrick Schleizer's key pair is legitimate.
  5. Website checks are only as secure as the imperfect TLS system, which is itself based on certificate authorities that have been frequently compromised in recent years.
  6. [archive]
  7. [archive]
  8. [archive]

Follow: Twitter.png Facebook.png 1280px-Gab text logo.svg.png Rss.png Matrix logo.svg.png 1024px-Telegram 2019 Logo.svg.png Discourse logo.svg

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate whonix.png

Share: Twitter | Facebook

Interested in becoming an author for the Whonix News Blog [archive] or writing about anonymity, privacy and security? Please get in touch!

https link onion link

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.

Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee [archive] of the Open Invention Network [archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)

Whonix ™ is a derivative of and not affiliated with Debian [archive]. Debian is a registered trademark [archive] owned by Software in the Public Interest, Inc [archive].

Whonix ™ is produced independently from the Tor® [archive] anonymity software and carries no guarantee from The Tor Project [archive] about quality, suitability or anything else.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint.