Running Linux, 5th Edition - Matthias Kalle Dalheimer [101]
So what happens to your email messages once fetchmail has pulled them from your account? We have said previously that it passes them on to your MTA. Your MTA then usually puts the messages into a so-called local spool file, often /var/spool/mail/ OpenPGP Encryption with GnuPG Using the GNU Privacy Guard, or GnuPG for short, you can encrypt individual files and emails, and digitally sign them. The main command-line tool of GnuPG is gpg, thus called because it started out as a replacement for PGP, which was the first encryption tool available to everyone that had strong cryptography built into it. PGP, which stands for Pretty Good Privacy, was written by Phil Zimmermann in the early 1990s. OpenPGP is the standard that describes the file format of PGP version 5.0 and later. GnuPG and PGP both implement this standard, and hence are able to read each other's files. Symmetric Encryption The simplest way to encrypt a file with GnuPG is to encrypt it with a passphrase.[*] This method is called symmetric encryption. The actual cryptography underlying this is beyond the scope of this book. Suffice it to say that the passphrase is used as the encryption key to the file. Everyone knowing the passphrase will be able to decrypt and read the file.[*] To encrypt the file music.ogg, you simply type gpg --symmetric music.ogg. GnuPG will prompt you for a passphrase, and then again to confirm the passphrase in order to avoid typos. The encrypted file is written to music.ogg.gpg. If you prefer another output file name, use --output outfile, like this: gpg --output music.gpg -c music.ogg Here, we used the -c and -o shortcuts for --symmetric and --output, respectively. To decrypt the file, simply call gpg file. For instance, to continue the previous example: gpg music.ogg.gpg As with encryption, you can request the output to be written to a file other than the default one by using -o outfile. Public-Key Cryptography Although symmetric encryption works well for short-term and casual use, you will run into problems managing the plethora of passphrases accumulated when you encrypt lots of files. The obvious solution of using the same passphrase over and over again poses much the same problems as using the same lock for all your doors. Among others, losing one key locks you out of everything, and if one key is stolen, everything is open to the thief. This can be described as the problem of "Everyone who knows the passphrase can read the contents." Another problem is that of "Everybody who needs to read the contents also needs to know the passphrase." If you encrypt files not for archiving but for sharing with friends, collegues, or business partners, you run into this problem. You cannot reuse passphrases because it's insecure, as already mentioned, and because each new file might target another set of recipients. For instance, if you reuse a passphrase that was used to encrypt a message to Alice and Bob to now encrypt another message, this time to Alice and Charlie, then Alice, Bob, and Charlie can all read both messages, even though only Alice was intended to be able to read both messages. You cannot create a new passphrase for each new message, because your recipients will not know the passphrase. And if you have a secret channel to tell them the new passphrase, why would you need to use encryption in the first place? The only solution using simple encryption, then, is to negotiate a passphrase with each recipient separately, and encrypt the message to each of the recipients separately. But this, too, becomes prohibitively complex, because there must be a passphrase (or another shared secret) for each pair of people wishing