From Whonix



TODO: To be written.

See also Verifying Software Signatures.

Figure: How PGP Works [1]


Common Misconceptions[edit]

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

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

Related Tools[edit]

Encrypt, decrypt, sign, and verify text using OpenPGP; GnuPG front-end


In English Language[edit]

In German Language[edit]

Advanced Topics[edit]

Air Gapped OpenPGP Key[edit]

See Air Gapped OpenPGP Key.

Clearsign with Multiple Keys[edit]

Clearsign text document with multiple keys? [archive]

The OpenPGP Web of Trust[edit]

Hauke Laging [archive]'s clearsigned version of this text can be found here: OpenPGP_Certified.

The certification [archive] image (hauke_laging_gepruefter_artikel.en.png [archive]) is copyrighted by Hauke Laging [archive].

If you want to be extra cautious and really authenticate a OpenPGP key in a stronger way than what standard HTTPS offers you, you could use the OpenPGP Web of Trust.

One of the inherent problems of standard HTTPS is that the trust we usually put on a website is defined by certificate authorities: a hierarchical and closed set of companies and governmental institutions approved by web browser vendors. This model of trust has long been criticized and proved several times to be vulnerable to attacks as explained on our warning page.

We believe instead that users should be given the final say when trusting a website, and that designation of trust should be done on the basis of human interaction.

The OpenPGP Web of Trust [archive] is a decentralized trust model based on OpenPGP keys. Let's see that with an example.

You're a friend of Alice and really trust her way of managing OpenPGP keys. You've validated Alice's key.

Furthermore, Alice met Bob in a conference, and signed Bob's key.

This scenario creates a trust path from you to Bob's key that could allow you to validate it without having to depend on certificate authorities.

This trust model is not perfect either and requires both caution and intelligent supervision by users. The technical details of creating, managing and trusting OpenPGP keys are outside of the scope of this document.

We also acknowledge that not everybody might be able to create good trust path since it based on a network of direct human relationships and the knowledge of quite complex tools such as GnuPG.

Bootstrapping OpenPGP keys from the web[edit]

What in case you want to totally stay anonymous or have no trust path to a OpenPGP key?

Some people just write an unencrypted mail to the recipient and ask them to send their public key. The recipient will most likely either send its public key or at least its fingerprint.

This works against passive attacks. An observer wouldn't know what they have been talking about in the following encrypted mails. This totally fails against active attacks. A man-in-the-middle could replace the recipient's key with its own malicious key. The sender would use the wrong key, the man-in-the-middle would decrypt the message, read it, and re-encrypt it with the legit key and forward it to the recipient. Neither sender nor recipient would ever find out that their messages are being read by an adversary. - This is the whole reason, why the trust model path and key signing is recommended in the first place.

As an alternative, some people also publish their OpenPGP fingerprint or their OpenPGP public key on their personal or other websites. This gets more secure, if the website is accessible over SSL (more when both server and client are using HSTS [archive] [and DNSSEC [archive]]) and/or as an onion service with a .onion domain. Of course, this presupposes, that the visitor is aware what kind of transportation mechanism is provided. In this case, the adversary would have to break the SSL or onion encryption while someone wants to obtain the key or fingerprint or to compromise the server, which may take, depending on the adversary more resources. Note, that both, the public CA system of SSL and Tor onion services have security issues, see SSL and Onion_Services#Onion_Services_Security for more information.

For such a model, it is best if the same website is accessible over both, https and .onion and the user visits both sites and compares if the results match.

To further improve the situation the key holder can spread its fingerprint and/or OpenPGP key to other websites. Some key holders attach their OpenPGP fingerprint to their e-mail signature (a short attachment of any mail) and participate(d) various public mailing lists. It will be difficult for an adversary to spoof all those information. This only helps, if the one trying to obtain the key is either aware of that or researching that on their own initiative.

GnuPG Key Encryption vs OpenPGP Hardware Protection[edit]



GnuPG encryption of OpenPGP private key hardware protection [4]
OpenPGP private key can be protected by software encryption Yes [5] No [6]
OpenPGP private key can be stored encrypted on storage Yes [7] No [8] [9]
implementation of software or device 100% Freedom Software Yes No [10]
can be independently reproduced and audited Yes No [11]
number of people capable of auditing the implementation small [12] very small [13]
OpenPGP private key protected by hardware, as in it is very difficult to extract the key from the devices storage No Yes [14]
wipes OpenPGP private key once physical tampering is detected (FIPS 140-2 Level 3 [archive]) No No (?) [15]
OpenPGP private key access notification No Some, yes? [16]
secret [17] can be entered on a secure external device [18] No Some, yes. [19]
OpenPGP private key can no longer be abused once detached from malware infected machine No [20] Yes [21]
user difficulty to remember secret Medium [22] Easy [23]
usability Medium [24] Difficult [25]
OpenPGP private key security once lost (without machine compromise) [26] protected by software encryption [27] [28] protected by hardware [29] [30] [31] [32]
OpenPGP private key cannot be used by malware [33] when key attached [34] and passphrase stolen [35] or pin cached No No
OpenPGP private key cannot be extracted, deleted or revoked by malware No [36] Yes
encryption of users data still effective once malware infected No [37] No [38]
signatures cannot be created by malware No No
signature counter on hardware device No Yes [39]
signature counter on computer display trustworthy if attached on malware infected computer Not applicable. No [40]
signature counter trustworthy if attached on malware free machine [41] Not applicable. Yes


Both options have unique advantages. Unfortunately, it is not yet possible to combine both options. [9]


Why aren't the SKS keyserver wiki steps always functional?

The SKS keyserver network has recently come under attack after a critical vulnerability was discovered which allows certificates to be spammed using a flaw in the OpenPGP protocol itself. Future releases of OpenPGP software will likely mitigate this flaw, but high profile contributors to the protocol suggest that data should not be retrieved form the network at present if possible. For more details, see here [archive]. [42] [43]


  1. [archive]
  2. As defined by TUF: Attacks and Weaknesses:
  3. [archive]
  4. token or smartcard
  5. If a secure password has been chosen to protect the OpenPGP private key.
  6. The OpenPGP private key is stored unencrypted on the storage of the smartcard or token.
  7. Stored on hdd, usb, etc.
  8. Stored on the memory chip of the smartcard or token.
  9. 9.0 9.1 Source: 1) gnupg-users mailing list: Possible to combine smartcard PIN with key password? [archive] 2) Patrick Schleizer specifically asked Werner Koch about this at c3c1. This is neither possible nor a planned or likely future feature.
  10. Specification may be Freedom Software, but currently there are no blueprints for smartcards or tokens that are Freedom Software.
  11. Due to the absence of blueprints and copyright, no other company can reproduce/audit security.
  12. Written in C and using cryptography. Hard stuff.
  13. Hardware is more difficult than software. That type of hardware is even harder. Only the engineers of producers have a chance to best understand it. In the case of closed hardware implementations, which most (all?) tokens and smartcards are, open and independent audits are impossible.
  14. It is very difficult to read the storage of smartcards and tokens. Professional data recovery companies usually decline requests for recovery from such storage.
  15. As far as known, no OpenPGP tokens or smartcards claim to poss this security feature.
  16. Some external smartcard readers blink a flashlight and/or tone when key is being accessed?
  17. password vs pin
  18. On an external device that is usually not infected by malware.
  19. Example: spr332
  20. A skilled adversary will take a copy of the OpenPGP private key as well as the passphrase for the case that the user manages to move on the a malware free machine.
  21. Since adversaries cannot extract the key to get a copy, once the compromise has been undone (either by chance, by doing a clean re-installation which the malware did not survive or because of noticing of the malware), future files/mails encrypted to the private key can no longer be decrypted by the adversary. No new malicious signatures can be made anymore. Revoking previously compromised keys would still be advisable, because the adversary could have created a huge number of signatures for all sorts of texts and/or files.
  22. a long passphrase
  23. a medium sized pin
  24. Arguably, OpenPGP is not that simple. In compression, OTR has a smaller feature set (for example, no signatures for publicly released files), but encryption is much more usable. OTR is younger and has more users.
  25. Initial setup is harder than GnuPG private key password encryption and generally hard.
  26. Assumption, 1) no malware on users computer 2) either the storage (hdd, usb, etc.) holding the OpenPGP private key vs token or smartcard has been lost, stolen or robbed.
  27. The adversary would require either 1) a backdoor in gnupg itself 2) or a backdoor in the distribution that shipped gnupg 3) or have found a vulnerability in gnupg 4) or have found an effective weakness in the encryption algorithm used by gnupg
  28. No vulnerabilities in gnupg's private OpenPGP key encryption have ever been reported.
  29. Quote wikipedia [archive]:

    Smart cards can be physically disassembled by using acid, abrasives, or some other technique to obtain unrestricted access to the on-board microprocessor. Although such techniques involve a fairly high risk of permanent damage to the chip, and irrecoverable loss of the secret keys therein, they permit much more detailed information (e.g. photomicrographs of encryption hardware) to be extracted.

  30. Other, non-OpenPGP smartcards have been cracked in past using ultra-expensive electron-scanning microscopes. Source: theguardian, [archive]
  31. [archive]
  32. More information on the realism, difficulty and cost of such attacks is required. If you know more information, please add them here.
  33. If machine used by the user has been compromised by malware such as trojan horse.
  34. On storage (hdd, usb, etc.) vs on token or smartcard)
  35. By keylogger or extracted from memory once cached.
  36. Therefore make sure to have a backup on storage that is never attached to that machine.
  37. An adversary who manged to compromise the user's machine can use a keylogger to sniff the OpenPGP private key password once it is entered next time of extract it from memory if it is still cached. Any of the users encrypted e-mail, files, etc. (that are read from the users devices or that have been extracted from other sources, such as by man-in-the-middle attacks or obtained from the user's mail provider and so forth) can then be decrypted.
  38. An adversary who manged to compromise the user's machine can wait until the user caches its pin next time. Otherwise, same as above. Once a machine has been compromised, nothing it shows can be trusted anymore. Even if the PIN is never cached. If the PIN is cached or not is up to the software on the users machine which can be no longer trusted once compromised. The adversary could install its own key caching software (gnupg-agent). Instead of the users request "decrypt mail X", malware can also intercept this and make it "decrypt mail Y and X".
  39. Users could attach their smartcard to other computers, perhaps non-compromised, perhaps offline machines and check the signature counter. For example output, see: [archive]
  40. One malware is running on a machine, nothing the machine's display can be trusted. It could be manipulated by the malware.
  41. Assumption: The tooken or card reader has not been compromised by malware running on the users machine.
  42. New, experimental keyservers have been established which afford protection against this attack.
  43. The author notes the potential downsides of this attack:
    • If you fetch a poisoned certificate from the keyserver network, you will break your GnuPG installation.
    • Poisoned certificates cannot be deleted from the keyserver network.
    • The number of deliberately poisoned certificates, currently at only a few, will only rise over time.
    • We do not know whether the attackers are intent on poisoning other certificates.
    • We do not even know the scope of the damage.


The certification [archive] image (hauke_laging_gepruefter_artikel.en.png [archive]) is copyrighted by Hauke Laging [archive].

The rest of this page is under the following license.

Whonix ™ OpenPGP wiki page Copyright (C) Amnesia <amnesia at boum dot org>

Whonix ™ OpenPGP wiki page Copyright (C) 2012 - 2020 ENCRYPTED SUPPORT LP <>

This program comes with ABSOLUTELY NO WARRANTY; for details see the wiki source code.

This is free software, and you are welcome to redistribute it under certain conditions; see the wiki source code for details.

Search engines: YaCy | Qwant | ecosia | MetaGer | peekier

Follow: Twitter.png Facebook.png 1280px-Gab text logo.svg.png Iconfinder news 18421.png Rss.png Matrix logo.svg.png 1024px-Telegram 2019 Logo.svg.png Discourse logo.svg Reddit.jpg Diaspora.png Gnusocial.png Mewe.png 500px-Tumblr Wordmark.svg.png Iconfinder youtube 317714.png 200px-Minds logo.svg.png 200px-Mastodon Logotype (Simple).svg.png 200px-LinkedIn Logo 2013.svg.png

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

Whonix donate bitcoin.png Monero donate whonix.png United Federation of Planets 1000px.png

Share: Twitter | Facebook

Please consider a recurring donation [archive]!

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. Policy of Whonix Website and Whonix Chat applies.

Copyright (C) 2012 - 2020 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, Contact.