Encryption with GnuPG (GNU Privacy Guard) and PGP (Pretty Good Privacy) can make digital life much safer. Setting it up is really easy, but by using the tools incorrectly, the hoped-for security gain is usually only moderate.
What is the problem?
Although installation and initial configuration are very easy, keys (private and public) must be maintained locally to ensure a high level of security at all times. If this does not happen, the frustration is usually great. A good example of this is the generation of a new private key. The process of generating the key is simple and quick, but the distribution often fails, even if everything has been uploaded properly. The consequences of this are mails that have been encrypted for invalid, outdated, or even lost keys, and "running after" people to get the latest key. There are definitely ways and means to avoid these and other problems, but they should be followed by everyone, comparable to good table manners.
Create keys correctly
When things have to be done quickly, you often read half-heartedly or disinterestedly, but especially with GnuPG and PGP you can gain considerably in security if you take a closer look at the details. Usually you generate your keys with
gpg --keygen
However, GnuPG has the suboptimal default of generating only 2048-bit RSA keys. This is not recommended without good reason, but more on that below. A key that is longer increases the security of the encrypted data immensely. Therefore, a key length of 4096 bits should rather be chosen if possible.
An expiration date is also useful, as this ensures that the key automatically loses its validity at a selected time in the event of loss. However, if the key still exists and continues to have its integrity, one can simply extend the expiration date. As a matter of principle, the expiration date should not be set too generously, as this will make this mechanism less important.
It is also advisable to use subkeys for the tasks at hand. Personally, I have one subkey for encryption, one for signing, and one for authentication. The master key, which is always created, is actually only responsible for key management, the subkeys are then used for actual task fulfillment. By default, GnuPG always creates a master key with a subkey for encryption and signing, which in turn has some disadvantages. If the subkey is compromised, it is possible to create a new subkey for the respective task, so you should have one subkey each for encryption, one for signing and one for authentication, because this reduces the probability that all three tasks are prevented at the same time due to the loss of a subkey. At the same time, much better management is possible because each subkey can be configured autonomously and thus has different expiration dates, for example.
gpg -K sec rsa2048/0x8C859FD829F10BDB 2017-05-30 [SC] [verfällt: 2018-05-30] Schl.-Fingerabdruck = D2A8 01AF A566 6AD5 169F FB7E 8C85 9FD8 29F1 0BDB uid [ ultimativ ] Ben Rösler <ben.roesler@gzevd.de> ssb> rsa2048/0x65C88B9BCEC43491 2017-05-30 [E] [verfällt: 2018-05-30] ssb> rsa2048/0xDB086DE8E0E33804 2017-05-30 [S] [verfällt: 2018-05-30] ssb> rsa2048/0x4121D9A5AC02E54E 2017-05-30 [A] [verfällt: 2018-05-30]
By the way, my key only has a length of 2048 bits because I use a SmartCard, which unfortunately technically comes with this limitation.
Regardless of how secure you feel, you should always use a password for your private GnuPG key. There is no good reason not to do so.
In addition, it is still important to generate a revocation key, because this can be the last hope to protect against misuse if the private key is lost. Once a key has been revoked, this cannot be undone.
GnuPG maintenance
GnuPG does not take care of public and private key maintenance itself, which most users do not seem to be aware of yet. The consequence of this is often a feeling of facing a level of complexity that one finds burdensome due to time pressure or disinterest. But there is another way - and an easier way. The magic word is "cron" - and it delivers what it promises. I have my nursing tasks processed every day at 2:00 a.m., so the following line can be found in my crontab:
0 2 * * * /usr/bin/gpg --batch --refresh-keys > ~/.log/gpg-keys-update.log
The command /usr/bin/gpg --batch --refresh-keys makes sure that all keys are updated regularly. This way I quickly get to know if someone should have revoked his key.
Trust and affirm your fellow man
GnuPG is pointless if you can't trust it. There are so-called "key signing parties" where nothing else is done than confirming to other key holders that a certain key belongs to them. This sounds quite complex at first, but there are already tools for this, for example Pius. Unless you don't have the time or the means, you can of course do it yourself. Here's how it works:
gpg --edit-key $YOUR_FRIENDS_KEY sign yes save
In this way, you confirm that the key really belongs to the person in question, and you stand for this with your name.
Another, not so binding option is to place your trust in a key, but others have nothing to gain from this. One should do it nevertheless.
gpg --edit-key $YOUR_FRIENDS_KEY trust 5 y quit
Thus, you put your full trust in this key. If you don't want this in this absolute form, you should just read the dialog of GnuPG and follow it, because GnuPG knows different gradations of trust.
Practical gadgets and tools
Finally, I would like to briefly explain a few tools that use GnuPG to provide more than just mail encryption and signing.
Password encryption
With password-store, passwords can be managed excellently and securely, and even with multiple users versioned via git. It's worth integrating this simple script into your everyday life, because it even allows you to implement scripts that in turn require passwords. For GUI-loving people, there are also several graphical interfaces and integrations for MacOS X and Linux.
SSH-Agent
The GnuPG agent has a built-in ssh agent that can completely replace the traditional ssh agent. To do this, you need to start the GnuPG agent as follows:
#!/bin/sh /usr/bin/gpg-agent --daemon --enable-ssh-support export GPG_TTY=$(tty) export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
The ssh-agent is no longer needed at this point. You can use all ssh tools as usual, including ssh-add. If you have a subkey for authentication, you can also use it as SSH key. You can get the public SSH key with
gpg -a --export $KEYID > $KEYID.public.key
You have the private key in the private GnuPG keyring as a subkey to your private key.
This concept works even better with a GnuPG-compatible SmartCard, because it allows you to put your private key on the card and thus always carry it with you. On the one hand, this increases security, since a SmartCard is required to use the key, and on the other hand, it increases flexibility, since the SmartCard can be used with multiple devices.
Git
It is possible to sign one's commits. Together with the previously described ssh-agent, the commit is thus uniquely assigned to a person and the authentication is also absolutely secure via GnuPG. To realize this, Git must be configured in addition to ssh-agent, for which you can use the following commands:
git config --global commit.gpgsign true git config --global gpg.program gpg2
There are also other GnuPG integrations in Git, but these do not work with every Git service provider. If necessary, however, these can also be configured for the respective Git repo:
git config push.gpgsign true git config tag.forceSignAnnotated true
