How to use Gnu­PG sec­urely

In practice it will depend on various circumstances whether the use of encryption can give you more privacy, security or anonymity.

  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 elws.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 http://www.elstel.org/auxil/elws.pubkey.asc. Use a Tails DVD for Tor or make sure with netstat -atupn that no harmful programs are running like f.i. an ssh daemon. Compare the obtained key files for equality. Do not take your USB stick with the key to an online computer which may always be compromised. Either compare for equality offline or use a read-only USB stick. 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 elstel.org or perhaps just an NSA mirror. You may additionally try to fetch the public key from one of the following key servers: hkps://keys.openpgp.org, hkps://hkps.pool.sks-keyservers.net, hkp[s]://subkeys.pgp.net[:11371], keys.gnupg.net, pgp.mit.edu:11371, keyserver.ubuntu.com, pool.sks-keyserver.net 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. You may configure 'keyserver' in ~/.gnupg.dirmngr.conf.

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. Even worse since about 2008 all modern PCs have a component called Intel ME (Management Extension). This component was virtually designed to allow remote maintenance for your PC. However intelligence services may exploit security vulnerabilities of this component in order to log into any computer they want to (learn more here). 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 plain text message (no other file formats!) 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.

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.

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 online encryption 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.

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 http://www.elstel.org/auxil/elws.pubkey.asc > also: gpg --keyserver xy.net --recv-key / --send-key email/key-id >       gpg --output yz.pubkey.asc --armor --export yz@email.org

or: root> tor-resolve keys.gnupg.net root> torsocks/torify gpg --keyserver 130.206.1.8 --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 email and cmp with elws.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 elws.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 elws.pubkey.asc > gpg --fingerprint > gpg --list-keys > gpg --output mymessage.txt.gpg --encrypt --armor --recipient elws@elstel.org 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. We suggest you to create a key without a passphrase and without automatic expiry date. A keylogger is installed easily so that a password does not give you any additional security.

> gpg --full-generate-key > gpg --list-secret-keys > gpg --edit-key C824B271CAEDF21BE9A28B785CA6AA8CBE270325 gpg> showpref gpg> setpref TwoFish AES SHA512 SHA384 SHA256 SHA224 BZIP2 gpg> save

If you have created a new key you should set your cipher/algorithmic preferences next. We recommend TwoFish as a symmetric cipher. Whenever you use assymetric encryption like RSA the whole message will still be encrypted symmetrically the assymetric algorithm just being used to encrypt the symmetric key because symmetric encryption is much faster. TwoFish is an algorithm invented by Bruce Schneier. TwoFish has made it to the final round of selecting an encryption algorithm for the Advanced Encryption Standard. Nonetheless we do not believe the actual choice of the NIST (National Institute of Standards and Technology) for AES as optimal (Rijndael). That is because government agencies do not only have interest in secure encryption but also in breaking the encryption of others. There is no known method to attack TwoFish while different methods have been discussed for AES. There exist some known cryptoanalytical attacks against AES-256 (key length of 256bit) which may be less safe than AES-128 because of the special properties of the algorithm (look at this article). Note that we have stated TwoFish before AES (which means AES-128) at setpref so that it will become the default choice when encrypting messages for this key. Unfortunately TwoFish is not selected by default as usable algorithm so that specifying --cipher-algo twofish on the command line will not help under most circumstances. We have chosen bzip2 as compression algorithm which does compress better than gzip. Besides this bzip2 has several asserts (checking of consistency conditions) in its code so that it should be more hard to infect a computer by merely executing the uncompression algorithm. It is basically desireable to encrypt compressed data because compressed data has a higher entropy and thus less redundancies which could be used to crack encryption.

> gpg --output maxmustermman.pubkey.asc --armor --export maxmustermman@email.org > chmod 444 maxmustermann.pubkey.asc; > gpg --output /media/usbstick/maxmustermann.privkey.asc --armor --export-secret-keys; > 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.

> gpg --output mymsg.txt.signed --personal-digest-preferences SHA512 [--local-user elws@elstel.org] --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 elws@elstel.org 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-cipher-preferences TwoFish AES128 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 gpg> help

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 elws.privkey
gpg: keyring `/home/amnesia/.gnupg/secring.gpg' created
gpg: key 9981E39D: secret key imported
gpg: key 9981E39D: public key "Elws. Starnight (…) <elws@elstel.org>" imported
gpg: key 9981E39D: public key "Elws. Starnight (…) <elws@elstel.org>" 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 elws@elstel.org
 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)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>

 gpg> trust
  sub  4096R/0D5B5869  created: 2015-01-10  expires: never       usage: E
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 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)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 [ unknown] (1)  Elws. Starnight (use this key to create and encrypt messages offline on a computer which is known to be clean; at best in plain text.) <elws@elstel.org>
 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.

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.

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”).