How to use GnuPG securely

In practice it will depend on various circumstances whether the use of encryption can give you more privacy, security or anonymity.
We suggest the following guidelines when it comes to secure your communication or to secure any other kind of documents than emails. Please follow the instructions given in this document thouroughly if there is some information which you wanna handle to us in encrypted form:

  1. Obtain a genuine copy of our public gpg key.
  2. Do not encrypt or store private keys on a computer which is online.
  3. Always keep your private key with you (f.i. on an USB stick) / Never leave it unattended.
  4. Try to avoid using a computer which could have been compromised even if that computer is offline.
  5. Include your own public key for a response.
  6. To stay anonymous you may use a throwaway e-mail via Tor.
  7. Tell us that you have complied with these instructions.
  8. The most sensitive information may require a secure destruction of the private key after the message has been read.

At first you will need to obtain a genuine copy of our public gpg key i.e. the estellnb.pubkey.asc file. Try to download the key file from different computers over different networks as available via the contact link from our main page; at best also via Tor: do nothing more than booting a clean computer from CD/DVD and execute sth. like torsocks wget Compare the obtained key files for equality. You may also ask for the fingerprint via telephone though this is not a panacea either as telephone calls can be re-routed and eavesdropped as internet connections can. Be sure not to use a personal phone but perhaps a phone of a friend from a friend of yours. This is important because you will never know whether you are visiting the original site or perhaps just an NSA mirror. Using our self signed https-certificate to fetch the key currently makes only sure that you are connecting to the same site all the time. It may be an advantage as the spoofing of web sites by intelligence agencies does not work with 100% reliability. You may additionally try to fetch the public key from one of the following key servers:,,,, although we can not guaruantee the keys available there to be up to date which is a major disadvantage. Only the latest key must be used.

Now supposing you have obtained a genuine copy of our public gpg-key you need to follow some precautions in order not to render encryption useless or even harmful. At first never create your messages on a computer which is online if you wanna encrypt this messages later on. Any computer connected to the internet can be compromised and rooted within seconds as soon as you just open your web browser or email program. Consequently use an own offline computer which is booted from a known-to-be-clean boot CD or DVD for creating and encrypting your message; delete the original message from RAM or with shred from disk, put the encrypted message on an USB stick and transfer the encrypted message to a computer which has access to the net. At best unplug your network cable and blacklist your wifi device driver before booting. This is so important because we need to trust in encrypted messages not having already been eavesdropped at the sender.

If you wanna have a response on your message please pack the public key of yours into the message. We wanna be sure that the response is directed to the originator of the message; thus we will not download your public key from the web. Create the private key (or that is to say the pair of private and public keys) on a clean offline computer and store it on an USB-stick or SDcard with read-only switch for later use. Always keep the private key with you. Never leave it on a computer at home. Intelligence agencies or other players may be able to enter your home when you are away because you can always be located by your mobile phone. Entering your home does not pose a problem: There are “universal keys” as also used at airports to examine your luggage which can open any physical lock. It may be hard or impossible to detect the loss of a private key as it can just be copied like any other data. Chip card readers may be a way out of this dilemma because then you need to steel the chipcard in order to take posession of the private key. However we do not describe the usage of such readers in here and merely rely on your compliance.

In case that you should already be targeted by a surveillance agency - whether you know about it or not - try to make sure that your hardware is clean. Note that f.i. the NSA regularely intercepts laptop shipments so that hardware ordered for your name may already be manipulated. The best way out may be a desktop computer built by your own where you can always see the mainboard and all components inside; notebooks tend to be hard to disassemble and you cannot do that every time you leave your computer unattendedly. Errors on a machine which can not be reproduced on another machine with the exactly same setup may either point to damaged or to manipulated hardware. Note that the necessary hardware manipulations may be rather hard to see, f.i. small alterations of the width of your USB-plugs.

Before you send your message consider whether it can be a disadvantage that a possible surveillance authority knows on who has communicated with whom. You have the possibility to send your message from a temporary throwaway e-mail domain like those listed by TorVPN via Tor. Select one or two email providers of your choice from this list and do not do anything else than sending your encrypted message via the providers you have selected once you enter the Tor network. Tor users are under heavy attack among other services also by the NSA and you may be traced back once you are attacked. The shorter you stay in the Tor net the lower is your likelihood of being cracked. The only thing which can prevent you from giving away anonymity may be Whonix. It puts the Tor client into a virtual machine so that compromising it does not abandon anonymity. However the only problem may be that you will not have a clean boot CD for Whonix. Likewise you may prefer a real OSS, i.e. a non commercial virtualization technology i.e. qemu because even virtualization does not constitute an invincible shield (while it is certainly somewhat harder to get bugs inserted in OSS software for intelligence agencies).

Last but not least tell us what security measures you have taken when sending your message to us. What kind of security mesaures may be appropriate depends on your threat scenario and the sensitivity of the information you wanna pass to us. Nonetheless we need to consider encrypting with public keys from others or openly storing private keys on computers which are used for web access and browsing to be piggery as that pretends some sort of elevated security where there is none. One of the worst fallacies when it comes to any kind of security need is to trust in something that should not be trusted in. Either consider sending your message as plain text or try to take some minimum security measures to escort encryption.

Finally we do not use our private key forever. All your encrypted messages may be stored by surveillance agencies or by some other party. Once they get the private key they can suddenly decrypt all of your messages! We are trying to avoid this by ultimately destroying our private keys at least whenever we have received information which can be considered sufficiently sensitive or whenever we did not succeed in shielding our private key as a mere preventive measure. We may save less sensitive messages in plain text along with our private key. New public keys will likely be signed with the old private key to make it easier for you to assert the source of the new key. However checking such a signature may be an insufficient measure because those who may have stolen the private key may also create their own successive key for eavesdropping; i.e. we believe there is little value in doing so. At best begin another time at point one. Revoked keys will be listed together with the new key under «contact» at the main page. Handle your own private keys likewise; at least those used to communicate with us.

Note that we consider anonymity to be the better security measure than the so called «web of trust» which can be infiltrated easily at an arbitrary point. Buy the CD/DVD you boot your clean system with at a newspaper stand. No eavesdropper or no intelligence agency can sell compromised versions of hardware or software to all the people as this would quickly be brought to public attention. It is almost always the case that certain people are targeted individually for any reason you may or may not know. Remaining anonymous means to remain save with a few exceptions: Users of the Tor network tend to be targeted or also such users who just wanna inform themselves about how to encrypt or stay anonymous. Users like you who have just read this text. Note that by reading this text you may already be under suspicion. This is not a joke.

The following is a quick reference about how to use gpg. You may additionally want to consult other sources of information:

> /usr/sbin/tor & > torsocks wget > also: gpg --keyserver --recv-key / --send-key email/key-id >       gpg --armor --export yz.pubkey.asc

or: > tor-resolve > torsocks gpg --key-server --recv-key 0x9981E39D

It should not matter which keyserver you consult since they are known to synchronize themselves regularely. A key retrieved like this can no more be compared via --armor --export file and cmp with estellnb.pubkey.asc because signatures of other people may already have been appended to the key as retrieved from the keyserver. Once you also have the gpg keys of these persons that will nonetheless pose a potential advantage in verifying the authenticity of the estellnb.pubkey (see for the «Web of Trust»).

Now reboot from DVD and take your computer offline (You may need to blacklist your wireless adapter.).

> gpg --import estellnb.pubkey.asc > gpg --fingerprint > gpg --list-keys > gpg --output mymessage.txt.gpg --encrypt --armor --recipient mymessage.txt ( armor creates an ascii-output which can be sent via email. )

The so called fingerprint is a hash value which should allow you to check whether your copy of a public key is authentic. This is especially useful whenever you have received the fingerprint in person f.i. via a business card or whenever there is no other possibility to check two keys for equality. Remember that two copies of the same key may differ by the number of signatures attached to them (see: keyserver).

Or if you wanna have a response create a 4096bit RSA key. It is best to use the same level of encryption as we do. A chain is as strong as its weakest part.

> gpg --gen-key > gpg --armor --export maxmustermman.pubkey.asc > chmod 444 maxmustermann.pubkey.asc; > gpg --armor --export-secret-keys /media/usbstick/maxmustermann.privkey.asc; > chmod 400 /media/usbstick/maxmustermann.privkey.asc; ( you may also touch and chmod the file first; chmod also the .cpio ) > or: find ~/.gnupg | cpio -H crc -o >/media/usbstick/maxmustermann.gnupg.cpio >     cpio -tdv </media/usbstick/maxmustermann.gnupg.cpio > at a later bootup use: cpio -idvu </media/usbstick/maxmustermann.gnupg.cpio … > gpg --output amassage.txt --decrypt amassage.txt.gpg

Note that the --armor option is required as soon as you want to print or transmit a message via email. It converts to an ascii/character based notation rather than creating binary data.

If you are planning to have a longer correspondence or if you just wanna communicate in both directions then you should sign your messages. A message being signed says that you have been in the possesion of the secret key and thus that the message comes from you. Signing is especially important if both parties undisclose their public key. Please also mind that you should apply the same security measures to the key you use for signing as the one you use for encryption (as opposed to some suggestions in the context of the «Web of Trust»). Getting messages signed may be hardly less important than encrypting at least for a mutual dialogue. Thus the keypair for signing and encrypting should always be generated and destroyed together.

> gpg --output mymsg.txt.signed --personal-digest-preferences SHA512 [--local-user] --clearsign mymsg.txt > später: gpg --verbose --verify mymsg.txt.signed

Now you can sign and later on encrypt your messages. Even so it is possible to just sign and publish a message. That way other people will be able to gain some sort of certainty that a message was in deed published by you (the sender of an email address can be faked very easily for everyone who knows the SMTP protocol.). gpg just appends a trailer to your message which contains the signature. We recommend that you specify the SHA-512 algorithm for signing as otherwise the known unsafe SHA-1 might be used. The key-number or the key-email may in case of ambiguity be specified by --local-user or -u.

> or: gpg --output mymsg.txt.gpg --encrypt --sign --personal-digest-preferences SHA512 --armor --recipient mymsg.txt > später: gpg [--output mymsg.txt] --verbose --decrypt mymsg.txt.gpg

You can furthermore combine both steps easily. Then gpg will output an additional message that it has verified the authenticity of the sender on decryption. The --verbose flag is here to show the used hash algorithm (SHA-512/256) and the RSA-key-lengths (f.i. 3072 or 4096). However we rather prefer to keep both steps separated.

If you have some material which you wanna hand to us once and that`s it so then you do not need to sign (though it still might be interesting for us). You just need our public key; don`t even generate your own keypair. Possibly you want nobody to know who has brought that to the public. Then signing would be a bad idea.

gpg smart cards, ~/.gnupg/gpg.conf and online keys

Once you have used gpg it will create a file called ~/.gnupg/gpg.conf (a default ‘skeleton’ configuration file to do so may reside below /etc/skel/.gnupg/). It is worth to have a look at this file as you may not only set some default preferences like f.i. your default-key there but as it can also relieve you from the act of retyping the same long-options like --personal-digest-preferences again and again which is a security risk as you may forget them one day. Just have a look at the following example excerpt of our gpg.conf:

default-key 02530C63 charset utf-8 personal-digest-preferences SHA512 group online = 02530C63 group offline = 9981E39D

Having a default-key is useful for the purpose of signing so that you do not need to specify the --local-user option. The group option is also interesting as it allows you to define aliases for certain keys (as returned by gpg --list-keys). While the email adress is more often used as an alias for the key ID the group option may be a viable alternative once you have two keys associated with the same email (f.i. one key used for online encryption and another one for offline usage). Personal digest preferences should default to SHA5-512 or SHA-256 in order to avoid the unsafe SHA-1 (as stated above). Finally utf-8 is the default charset on most distributions nowadays so that you should instruct gpg to use this charset for metadata (the charset of the message itself will be preserved unchanged.).

> gpg --card-status > gpg --card-edit

Once you would also like to use gpg on a computer connected to the internet you may need a gpg encryption smart card like those from the FSFE (Free Software Foundation Europe) in order to prevent your key from being stolen. To make use of such a card you will first need a card reader. Then you have to install pcscd (PC secure card daemon) in addition to gpg2. After that you may mainly use the two commands from above to access your card. Though various other manuals will recommend you to make a backup of your secret keys before loading them on the card we wanna discourage you strongly from doing so. If someone else finds your backup medium that will compromise your key without your knowledge which is a worst case scenario. Not to use GnuPG is far better than to deceive unsuspecting people by a non-existant security. Just generate and backup a revocation certificate for your secret key. Once the card gets lost and you do not find it any more you will have to tell your friends about the new key again after having quickly published your revocation certificate. Remember f.i. that intelligence services have universal keys and may enter your home while you are away (something they can easily see by locating your mobile phone). An additional interesting function of your gpg smart card is that you can use it to authenticate with SSH.

Concerning us our online encryption smart card is only used with a specially secure workstation booted from a carry-with-you USB-stick. We merely use it with an ftps program and a browser where all default certificates have been removed. The only DANE and Tor verified certificate on there currently is to access our hosting provider including a web mail facility. Graphical email programs may have their own flaws and we currently use none. Using a smart card in a secure environment is so important for encryption as the attacker may view your message in plain text when using a compromised machine. Smart cards can only shield against the case of stolen keys (as long as you do not “backup” your secret key which is fool´s instruction) because there is no way to get a key out of the card once it is in there. If you do only want to sign (but never encrypt), that can still be secure on a compromised machine as long as you keep an eye of the signature counter of the card which increments on every usage. Note that your PIN may already have been grabbed by a key-logger without your knowledge (a good cracker does not leave any traces in the logs). Changing the PIN all the time is not a solution either as you never know in an insecure environment when your machine would have been compromised the last time. Additionally the gpg card will destroy itself when you forget and enter the PIN wrongly too often.

An important information for the usage of your gpg card is that unfortunately it often will only keep your secret key but not your public keys. As a consequence you need to keep a save backup of your own public key; it contains additional information being signed by but not being part of your secret key on the card!

Web of Trust

Though some practices which are usually associated with the Web of Trust have been criticized in here we believe it is still important to know something about it. Our critics do mainly pertain to the usage of unsafely stored, unsafely used and outdated master keys as used for signing. Nonetheless under certain circumstances it can be very useful to trust in a key verifiably signed by someone else presumed that you have no verifiably authentic master copy of the key.

Now let us start with something very simple. Suppose you have decided to import your private key into an empty and fresh gpg database instead of restoring a backed up old database with cpio. Now gpg will not know that the private key is really yours. This may become a problem when it comes to check signatures (Encrypting and decrypting would already work well.).

amnesia@amnesia:~$ gpg --import estellnb.privkey
gpg: keyring `/home/amnesia/.gnupg/secring.gpg' created
gpg: key 9981E39D: secret key imported
gpg: key 9981E39D: public key "Elmar Stellnberger (…) <>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg:       secret keys read: 1
gpg:   secret keys imported: 1

You can circumvent this problem by assigning ultimate trust in the “signing capability” of your own key. This means that you will trust any key which you have signed. Signing known good keys may be a good practice in order to suppress warnings on decrypting signed messages. By signing a public key you tell gpg that you consider it good f.i. because you have checked its fingerprint as obtained from a reliable source.

amnesia@amnesia:~$ gpg --edit-key
 gpg (GnuPG) 1.4.12; Copyright (C) 2012 Free Software Foundation, Inc.
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
 Secret key is available.
  pub  4096R/9981E39D  created: 2015-01-10  expires: never       usage: SC
                       trust: unknown       validity: unknown
  sub  4096R/0D5B5869  created: 2015-01-10  expires: never       usage: E
 [ unknown] (1)  Elmar Stellnberger (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <>

 gpg> trust
  sub  4096R/0D5B5869  created: 2015-01-10  expires: never       usage: E
 [ unknown] (1)  Elmar Stellnberger (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <>
 Please decide how far you trust this user to correctly verify other users' keys
 (by looking at passports, checking fingerprints from different sources, etc.)
   1 = I don't know or won't say
   2 = I do NOT trust
   3 = I trust marginally
   4 = I trust fully
   5 = I trust ultimately
   m = back to the main menu
 Your decision? 5
 Do you really want to set this key to ultimate trust? (y/N) y
 pub  4096R/9981E39D  created: 2015-01-10  expires: never       usage: SC
                      trust: ultimate      validity: unknown
 sub  4096R/0D5B5869  created: 2015-01-10  expires: never       usage: E
 [ unknown] (1)  Elmar Stellnberger (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <>
 Please note that the shown key validity is not necessarily correct
 unless you restart the program.

 gpg> save
 Key not changed so no update needed. 

Note that the 4096R/9981E39 says that it is a 4096 bit RSA key with the given hashed key id written after the slash (the last seven digits of the fingerprint). You need the key id whenever you want to retrieve a key via a key server since the email address alone is not enough information to do so. Here we switch the trust in our own key from unknown to ultimate. Do not let yourself be irritated by gpg showing an unknown validity for our ultimately trusted key by now. After another --edit-key with a gpg> list - command it shows ultimate trust and the implied ultimate validity for the public/private keypair we have just imported. The editing mode can be left with save or quit where you are asked once more whether you wanna keep your latest changes.

As you can see gpg had not just generated one key for us but one master key for signing (usage: SC, «sign, certify») and a subkey for encryption (usage: E). This is the default option for --gen-key (RSA and RSA). RSA is a well known, founded and analysed assymetric encryption algorithm based on factoring primes which you can trust in if it is implemented correctly. If there are many subkeys you can select a specific subkey with key Number when being in the --edit-key mode. You may enable and disable subkeys so that they either can or can not be used for encryption. However usually when you add a new key with addkey you will first revoke the previously used and selected key with revkey because there is hardly any reason to have two keys used for encryption at the same time. The newer one tends to be the better one as it will less likely have been compromised.

Subkeys can be revoked but never more deleted once they have been uploaded to a keyserver. Nonetheless it may likely be necessary to exchange your master key from time to time as well especially when it is not stored on a special encryption card and can be copied any time. Use gpg --output mykey.revoke.asc --gen-revoke my@email.dom to achieve this; publish your revocation certificate and then a new master key at best also signed with the old master key. The passwd command can be used to reset the password you need for decryption and signing. You may want to do this if you should ever have plugged a secure encryption card in an online computer (or a computer compromised in any other way). Your keystrokes could have been monitored. As keystrokes can be monitored easily on a compromised machine you may want to decide to do even without such a password. However then you will need to be quick to publish your revocation on loss of the card.

There are a few other things you may want to know. At first if you wanna get rid of warnings issued by gpg when checking signatures you need to sign public keys from other parties you wanna communicate with. Do so by issuing an --edit-key on the others` public key, type fpr, check the fingerprint and finally use sign to assert the validity of the key. Basically you should not sign a key which you do not think of as trustworthy but rather check the fingerprint on every decryption; at least do not upload your signature to a keyserver if you do not know or if you are not persuaded by the key handling and security measures taken by the other person. Once you have signed a public key your signature for it will be exported on every --export you issue on it. You may do this for your own later use or if you wanna show the world that you consider a key and its user as having been verified by you as well as having good security practices. If you do not wish to do so just use delsig to remove your signature from the other key before exporting that public key.

Finally there is some additional feature by gpg called user id management. A user id always pertains to the master key and can indicate mutlitple usage purposes as well as email addresses to be used together with that key. The commands to select an uid, to make it the primary one to add and delete an uid are uid Number, primary, deluid, adduid.

These are all basic commands you need to know (more are listet in the gpg man page). Let us now come back to the Web of Trust and why it is called like this. We have mentioned in the beginning that it is possible for gpg to check the validity of a key based on the signature of other people whom you trust. This is good practice.

Now consider the following example: You have just communicated with over gpg and are now assigned to a specific staff member who has his own key. Now you may assign full trust in the key signing policy of the key. If your staff members` key has been signed by the key and you already have imported that key then gpg will establish a chain of trust from the info key up to your staff members key so that you do not need to re-check, verify and sign the new key no more. Note that such a chain of trust may only entail a limited number of hops (as given by the --max-cert-depth option). It should be clear that a linear chain is broken if any of its keys gets compromised. Don`t trust anyones signed keys fully if your security needs should be critical.

That is why you would normally only assign marginal trust to the key signing customs of other people. Then you need --marginals-needed Number signatures from other peoples unless gpg trusts that key (There is even a --completes-needed option.). Not a too bad problem if you have enough time to collect and assert other peoples` public keys you may say. However too old master keys may not be trustworthy either. That is where the cat starts to hunt for its own tail and why the Web of Trust is only half as good in practice as in theory; at least unless everyone had a secure encryption card where the private key is generated on the card an will never leave the card; and unless everyone using gpg entailed good security practices as described herein. In that case only a loss of the card would trigger an invalidation of your master key. It certainly needs to be mentioned that a secure card will not alleviate you from the issue of having to encrypt on a clean offline computer because eavesdropping a message when it is still in plain text is always most easy to do (secure cards only used for authentication via ssh do of course pose an exception to the “offline rule”).