How to use GnuPG for e-mail

Kurt Garloff <garloff@suse.de>∗

1024D/1C98774E (99/08/23): 94DD 1125 CDFB AB48 6573 28EF C662 E1EA 1C98 774E
1024R/CEFC9215 (97/09/08): 92 00 AC 56 59 50 13 83 3C 18 6F 1B 25 A0 3A 5F

Andreas Jaeger <aj@suse.de>†

1024D/C272A126 (99/10/13): 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

28th August 2000

Abstract
This document describes how to sign and encrypt mail and other
data. It first tells a little bit about the basics of cryptography and
then gives an overview of GnuPG functionality and its trust model.
It also deals with integration into mail programs (mutt + Gnus) and
with compatibility issues for old PGP2 keys.

1 Basics
1.1 How secure is it?
There are a couple of algorithms which are considered safe by mathemati-
cians. Safe means, that there is no known weak point in the algorithm,
resulting in the fact, that the only possible attack is brute force1 . Brute
force means that every possible key is tried, until the right one has been
found. A brute force attack against a 56 bit DES key took a little more
than a year to crack by thousands of computers spending their idle time
to crack it in 1997/1998 in the distributed.net effort. In 1999, specialized
hardware built by the EFF was able to crack it within less than a day. So
56 bit DES can no longer be considered to be safe.
∗
General, GnuPG and mutt part
†
Gnus part
1
This is not entirely true. When the key is generated, you need good random numbers.
If those are bad and predictable, your key might be found easily. Linux /dev/random
however is OK.

1
 As every single bit in the length of the key doubles the number of possible
keys, reasonably long keys are safe, unless some mathematician finds a weak
point in the algorithm. The 168 bits of Triple DES won’t be found by brute
force attacks within the next hundred years. If computer power increased
by a factor of two every year, you’d need one more bit every year for the
same level of safety . . .

1.2 Symmetric vs. asymmetric algorithms

When using symmetric algorithms, both parties share the same key for en-
and decryption. To provide privacy, this key needs to be kept secret. Once
somebody else gets to know the key, it is not safe any more. Symmetric
algorithms have the advantage of not consuming too much computing power.
A few well-known examples are: DES, Triple-DES (3DES), IDEA, CAST5,
BLOWFISH, TWOFISH.
Asymmetric algorithms use pairs of keys. One is used for encryption and
the other one for decryption. The decryption key is typically kept secretly,
therefore called “private key” or “secret key”, while the encryption key is
spread to all who might want to send encrypted messages, therefore called
“public key”. Everybody having the public key is able to send encrypted
messages to the owner of the secret key. The secret key can’t be recon-
structed from the public key. The idea of asymmetric algorithms was first
published 1976 by Diffie and Hellmann.
Asymmetric algorithms seem to be ideally suited for real-world use: As
the secret key does not have to be shared, the risk of getting known is
much smaller. Every user only needs to keep one secret key in secrecy and
a collection of public keys, that only need to be protected against being
changed. With symmetric keys, every pair of users would need to have an
own shared secret key. Well-known asymmetric algorithms are RSA, DSA,
ELGAMAL.
However, asymmetric algorithms are much slower than symmetric ones.
Therefore, in many applications, a combination of both is being used. The
asymmetric keys are used for authentication and after this has been suc-
cessfully done, one or more symmetric keys are generated and exchanged
using the asymmetric encryption. This way the advantages of both algo-
rithms can be used. Typical examples of this procedure are the RSA/IDEA
combination of PGP2 or the DSA/BLOWFISH used by GnuPG.

1.3 Hashes
Asymmetric algorithms provide a means to make sure, nobody but the owner
of the secret key is able to read the encrypted message.
Two more things are desired for secure communication: The recipient
wants to know if the sender is really the one he seems to be and the message is

2
really the one the sender sent originally. Ensuring this is called a “signature”.
For prooving his identity, the sender uses his secret key. Without know-
ing it, the recipient can check it by using the well-known public key of the
refered person. However, he still does not know, whether the message is the
one originally sent.
In order to achieve this, Hashes are used. A hash is a sort of a checksum,
which is being computed over the text. The algorithm used for this checksum
(hash value), however, needs to make sure, that changing a bit can not
easily be compensated with changing another one. The hash value itself is
protected by mangling it with the secret key. Ideally, no two different texts
would result in the same hash value. In practice, the hash values used are
much shorter than the text itself and therefore it is in theory possible to
find different texts with the same hash value. The better the algorithm the
more difficult to find it. Commonly used algorithms include MD5, SHA1,
RIPEMD160.

1.4 Man in the middle

The weakest point in the communication based on asymmetric encryption is
the knowledge about the real owners of keys. Somebody evil could generate
a key pair, give the public key away and tell everybody, that it belongs to
somebody else. Now, everyone believing it will use this key for encryption,
resulting in the evil man being able to read the messages. If he encrypts
the messages again with the public key of the real recipient, he will not be
recognized easily.
This sort of attack is called “man-in-the-middle” attack and can only
be prevented by making sure, public keys really belong to the one being
designated as owner.

2 PGP2 and GnuPG

2.1 History
PGP (Pretty Good Privacy) was created by Phil Zimmermann. He used
the well known RSA algorithm, published 1978, for the asymmetric keys.
His program became commonly used very fast and a lot of users all over
the world adopted it. Phil Zimmermann gave it away for free. However he
almost went into prison for this. As he was American and the program was
used outside the US, he was accused for having it illegaly exported. Starting
from version 2, the program was exported printed as a book and scanned
and manually entered in Scandinavia to create an international version. A
lot of users still use PGP2.6.3i.
Besides the export problems, the algorithms are problematic. The RSA
labs were able to get a patent for the RSA algorithm, regardless of the

3
fact that it was already published in 1977 by Rivest, Shamir and Adleman.
The symmetric algorithm used, IDEA, is also covered by a patent, also in
Europe, and only strictly private use is possible without having to pay a fee
to Ascom Ltd. Newer versions of PGP (5.x, 6.x) used other algorithms, but
the program was no longer available for free for everybody. In commercial
environments, fees had to be paid. So, a lot of people did never accept PGP5
or later.
Therefore a new project came up: Gnu Privacy Guard, called GnuPG
or gpg. It was created within Europe to prevent the US regulations and
patented algorithms were avoided. It is designed to comply to the OpenPGP
(RFC2440) specification and released under the GNU GPL Copyleft. The
version 1.0.0 was released in September 1999.

2.2 Functionality
GnuPG offers the full range of functionality for en- and decryption, hashing
and signing messages and checking those. It supports several algorithms and
can be extended by modules.
It furthermore offers key management. It keeps the keys stored in a
database, called keyring. There is a private keyring, containing secret keys
(often only one), which is protected by a passphrase, and a public keyring
(typically quite large), containing a collection of public keys.
In order to be sure, public keys really belong to the owner, the user would
have to meet the person, check his ID and accept his public key on a floppy
disk. As this is quite unrealistic, GnuPG (like PGP) provides a little help.
First, there are fingerprints. A hash algorithm is run over the public key
and a hash value, called “fingerprint” is displayed. This fingerprint consists
of a couple of hex numbers and can easily be compared at a telephone line.
If the fingerprint is correct, one can be quite sure that the key is authentic.

2.3 Web of trust

Once you know a key is authentic, you can sign this key with your own secret
key. This signature is stored in the keyring. Whenever you use it, GnuPG
will check whether you signed it, and warn you if not.
There’s another possibility to get rid of the warning. If you don’t sign
the key, but you signed other keys and told GnuPG you trust those others
(to only sign keys they are sure of) and the owners of those keys have signed
the questionable key, GnuPG will accept it as being authentical. How many
signatures exactly are needed, is configurable and depends of the amount of
trust you assigned to these others.
The latter mechanism can be used to build a “web of trust”. If you have
some friends you know to be careful about signing keys and you know to

4
have the real public keys of them, you may allow them to introduce new
trusted keys to you.
Apart from this model, you may also use an hierarchical key signing
policy. In a company, you may designate a person responsible for signing
keys and the user may trust all public keys signed by this one. There are also
Certification Institutes (CA) that sign keys, if you prove your identity with
the help of a passport. Depending on their published policy, their owner,
their visible skill and your paranoia, you may trust keys signed by them.
Note that you can also have untrusted keys in your keyring. You will be
warned, when using them, because you don’t know, those really belong to
the one they seem to.
A lot of people just store their public key on a web site or submit it to one
of the public keyservers. See http://www.keyserver.net/ or http://www.
openpgp.net/ for more information on keyservers. Putting your gpg key
into the file ~/.plan is also a good idea: People can get it by a finger
command. Printing your key’s fingerprint on your business cards is also a
nice idea.

2.4 GnuPG commands

2.4.1 Key generation
First of all, you need to create a key pair. Every keypair carries one or more
user-IDs, typically a name and an e-mail address. gpg --gen-key will ask
your OS (Linux) to create a random number and generates a key pair out
of it. You will be asked name and e-mail address which are stored as user
ID.

2.4.2 Transfer of keys

You will want to exchange public keys with your friends. For this you will
use the --import and --export commands of gpg, preferably with the --
armor option to get the output in a format transportable with mail transport
programs. The commands --list-keys and --check-sigs may be used to
display the contents of your public keyring.

2.4.3 Signing keys

Before you can sign a public key, you will have to import it into your public
keyring in the first place. After this you should check the identity, either by
personal contact or by comparing fingerprints or by trusting other people
you know very well who signed the key with the care necessary.
You will use the command --sign-key to put your signature below the
key. As you need to use you private key, you will be asked to type the
passphrase.

5
 Afterwards, you might want to export the signed key again and give it
back to the owner. He can import this key again and your signature will
then also show up in his public keyring. Whenever he exports his public
again, your signature will be included and tell others, that you trust him.

2.4.4 Miscellaneous
There are a lot more commands. Use the man page or the --help option to
get this info. You can add user-IDs to keys, revoke keys, etc.
You missed the options to encrypt, decrypt, signing and checking mes-
sages? Well, look into the next chapter: You will use gpg directly only for
the key management, if you just want to use it for mail. Otherwise have a
look at the man page.

2.5 Compatibility issues

GnuPG does by default not support the old RSA keys and IDEA encrypted
mails, which are produced by PGP2. This is a consequence of the will
to avoid patented algorithms by the GnuPG authors. PGP2 does not un-
derstand the DSA/ELGAMAL keys/mails from GnuPG. At least, GnuPG
interaction with PGP5 is almost no problem.
If you don’t care about the license issues, eg. because you only use
GnuPG for private mail and live outside the “land of the free”, you can use
the ability to load modules into GnuPG and to provide interoperability with
PGP2 that way. SuSE provides the package gpgaddon which contains the
idea and rsa modules and provides a wrapper script, called gpg-compat,
which basically is exec gpg --load-extension rsa --load-extension idea
-allow-non-selfsigned-uid $*. You may additionally want to use the op-
tion --rfc-1991. You can even import old pgp2 keyrings with the help of
these options.
This simple approach will do most for you. However, it is not clever
enough to produce encrypted messages readable by pgp2. For this, a perl
script from Gero Treuner <gero@faveve.uni-stuttgart.de>, which is much
more clever, is provided and put into /usr/bin/gpg-2comp.
The configuration of ggp-2comp is done via the config file ~/.gpg-
2comprc. You need to set the key-ID of your RSA key there. Here is an
example with comments stripped off.
# ------- gpg-2comp user configuration
#$gpg = ‘/usr/bin/gpg-compat’;
$use_pgp2 = 0;
# YOU REALLY NEED TO SET THIS
$rsa_default_key = ‘0x12345678’;
$rsa_encryptself = 1;
#$comment = ‘Scripting by http://muppet.faveve.uni-stuttgart.de/~gero/gpg-2comp’;

6
3 Encrypting and Signing e-mails
Very often you have confidential information that you want to tell some-
body else by e-mail. Therefore you want to use encryption and signatures.
You may use GnuPG directly to encrypt and sign your letter and send this
document as attachment to your party. But there’s software that helps you
doing this automatically, so you won’t have to bother about calling GnuPG
yourself.
For e-mails, it’s the job of the mail reader (MUA = Mail User Agent) to
provide this help.2
The Mail program mutt does provide excellent support for PGP and
GPG. It has a lot of other nice features like mail threading and it is therefore
the prefered MUA of a lot of people. The interaction between mutt and gpg
will be described below. Other program with gpg support include pine
(limited), Gnus and others.

3.1 mutt configuration for gpg

Encrypted and signed mails complying to the OpenPGP specification carry
the MIME type application/pgp; format=text; x-action=encryptsign; signed
mails are multipart messages and have the MIME type of the signature set to
application/pgp-signature. mutt is able to detect this and call pgp2, pgp5 or
gpg automagically. When sending mails, on the other hand, you can select,
whether you want to sign or encrypt it or both.
Here is a sample configuration for mutt-1.0 assuming you want to use
gpg with the compatibility modules loaded. The comments should explain
what the meaning of the options are. More detailed information can be
found in the variable reference of mutt, which is in chapter six of the online
docu: /usr/share/doc/packages/mutt/manual-6.html

# Part of your ~/.muttrc

# Note: Within mutt, you can set these options manually as well:
# Just use : to type in the set command directly
#
# Use gpg command syntax
set pgp_default_version=gpg
# Call the gpg wrapper perl script with pgp2 compatibility
set pgp_gpg=/usr/bin/gpg-2comp
# Encrypted messages are encrypted with own key when stored
set pgp_encryptself
# Automatically encrypt/sign when replying to encr./signed messages
set pgp_replysign
set pgp_replyencrypt
2
There were also approaches where the MTA (Mail Transfer Agent) would be respon-
sible for encryption, but as the user does not normally directly interact with the MTA,
this concept was rather flawed and did not succeed.

7
# Sign by default
set pgp_autosign
# How many seconds does mutt remember your pass phrase
set pgp_timeout=600
# If you have more than one private key, specify which one you want
set pgp_sign_as=0x1C98774E
# pgp2 language: "mutt" is english with shorter messages
set pgp2_language=mutt
# You need this if you want to be able to encode 8bit messages
set pgp_strict_enc

For mutt-1.2, the PGP support settings have changed slightly. I split
most of them out of my ~/.muttrc by putting a source ~/.gpg.rc there.
I left
set pgp_replysign
set pgp_replyencrypt
set pgp_autosign
set pgp_timeout=1200
set pgp_strict_enc

in my ~/.muttrc. The ~/.gpg.rc is again suitable for old PGP2 support

and looks like this:

# This version uses gpg-2comp from

# http://muppet.faveve.uni-stuttgart.de/~gero/gpg-2comp.tar.gz
# %p The empty string when no passphrase is needed,
# the string "PGPPASSFD=0" if one is needed.
# This is mostly used in conditional % sequences.
# %f Most PGP commands operate on a single file or a file
# containing a message. %f expands to this file’s name.
# %s When verifying signatures, there is another temporary file
# containing the detached signature. %s expands to this
# file’s name.
# %a In "signing" contexts, this expands to the value of the
# configuration variable $pgp_sign_as. You probably need to
# use this within a conditional % sequence.
# %r In many contexts, mutt passes key IDs to pgp. %r expands to
# a list of key IDs.

# decode application/pgp
set pgp_decode_command="gpg-compat %?p?--passphrase-fd 0? \
--no-verbose --batch -o - %f"

# verify a pgp/mime signature

set pgp_verify_command="gpg-compat --no-verbose --batch -o - --verify %s %f"

# decrypt a pgp/mime attachment

set pgp_decrypt_command="gpg-compat --passphrase-fd 0 \
--no-verbose --batch -o - %f"

8
# create a pgp/mime signed attachment
set pgp_sign_command="gpg-2comp --no-verbose --batch -o - --passphrase-fd 0 \
--textmode --armor --detach-sign %?a?-u %a? %f"

# create a application/pgp signed (old-style) message

set pgp_clearsign_command="gpg-2comp --no-verbose --batch -o - \
--passphrase-fd 0 --armor --textmode --clearsign %?a?-u %?a?-u %a? %f"

# create a pgp/mime encrypted attachment

set pgp_encrypt_only_command="pgpewrap gpg-2comp -v --batch -o - \
--encrypt --textmode --armor --always-trust -- -r %r -- %f"

# create a pgp/mime encrypted and signed attachment

set pgp_encrypt_sign_command="pgpewrap gpg-2comp --passphrase-fd 0 -v --batch \
-o - --encrypt --sign %?a?-u %a? --armor ---always-trust -- -r %r -- %f"

# import a key into the public key ring

set pgp_import_command="gpg-compat --no-verbose --import -v %f"

# export a key from the public key ring

set pgp_export_command="gpg-compat --no-verbose --export --armor %r"

# verify a key
set pgp_verify_key_command="gpg-compat --no-verbose --batch \
--fingerprint --check-sigs %r"

# read in the public key ring

set pgp_list_pubring_command="gpg-compat --no-verbose --batch \
--with-colons --list-keys %r"

# export a key from the public key ring

set pgp_export_command="gpg-compat --no-verbose --export --armor %r"

# verify a key
set pgp_verify_key_command="gpg-compat --no-verbose --batch \
--fingerprint --check-sigs %r"

# read in the public key ring

set pgp_list_pubring_command="gpg-compat --no-verbose --batch \
--with-colons --list-keys %r"

# read in the secret key ring

set pgp_list_secring_command="gpg-compat --no-verbose --batch \
--with-colons --list-secret-keys %r"

# receive key from keyserver:

#set pgp_getkeys_command="gpg-compat --keyserver wwwkeys.eu.pgp.net \
--recv-keys ‘%r’"

9
 Another note: Many editors create backup copies. If those stay lying
aroung in /tmp/, your privacy is not protected very well . . . . Use edi-
tors, where you can switch off backup copies or use the mutt option set
delete_tilde, which will delete the file with a tilde appended after edit-
ing.3 You may instead set the dir for temporary files to one belonging to
you in your ~/.muttrc: tmpdir=~/tmp. Needless to say that this directory
should better exist . . .
PGPpine, an old package to help pine (3.9x) to produce encrypted mes-
sages, produces PGP messages without the correct MIME type. Add the
following to your ~/.procmailrc, if you want to have mutt recognize those
as PGP messages.
# Part of your ~/.procmailrc
# This recognizes PGPpine PGP messages and places the correct MIME type
:0
* !^Content-Type: message/
* !^Content-Type: multipart/
* !^Content-Type: application/pgp
{
:0 fBw
* ^-----BEGIN PGP MESSAGE-----
* ^-----END PGP MESSAGE-----
| formail \
-i "Content-Type: application/pgp; format=text; x-action=encrypt"

:0 fBw
* ^-----BEGIN PGP SIGNED MESSAGE-----
* ^-----BEGIN PGP SIGNATURE-----
* ^-----END PGP SIGNATURE-----
| formail \
-i "Content-Type: application/pgp; format=text; x-action=sign"
}

3.2 Using GnuPG together with Gnus in (X)Emacs

Emacs and XEmacs come with different mail and news reading packages. In
the following the support for the news and mail reader Gnus by the package
Mailcrypt is descriped. Mailcrypt also supports the mail readers VM, RMAIL
and MH-E.
GnuPG support is part of Mailcryptversion 3.5.5 which can be down-
loaded via http://www.nb.net/~lbudney/linux/software/mailcrypt.html.
Mailcrypt comes with its own manual which explains everything better than
I do. This section is just a shortcut for the lazy.
You need to install Mailcrypt on your disk and then run ./configure
and make to bytecompile everything. You can either have mailcrypt installed
in your home directory or put it in the global (X)Emacs directories with make
install. If you install it locally, you need to tell your emacsen where it lives
with setting the load-path in your ~/.emacs file e.g.
3
This option is provided by a SuSE patch, and has not (yet?) found its way into the
official mutt.

10
(setq load-path
(cons "/home/aj/ELisp/mailcrypt-3.5.5" load-path))
To hook Mailcrypt in your (X)Emacs, add the following lines to .emacs:
(load-library "mailcrypt")
(mc-setversion "gpg")
(autoload ’mc-install-write-mode "mailcrypt" nil t)
(autoload ’mc-install-read-mode "mailcrypt" nil t)
(add-hook ’gnus-summary-mode-hook ’mc-install-read-mode)
(add-hook ’message-mode-hook ’mc-install-write-mode)
(add-hook ’news-reply-mode-hook ’mc-install-write-mode)
Next time you start Gnus, you get a menu called ¨Mailcrypt¨ which gives
you an easy access to GnuPG.
Some variable settings which might be helpful are:
;; Use the pgp2 compatibility wrapper
(setq mc-gpg-path "/usr/bin/gpg-compat")
;; If you have more than one key, specify the one to use
(setq mc-gpg-user-id "0x12345678")
;; Always sign encrypted messages
(setq mc-pgp-always-sign t)
;; How long should mailcrypt remember your passphrase
(setq mc-passwd-timeout 600)
To sign automatically every message you send, you need to add some
lisp code. After adding the following lines to your .emacs file, (X)Emacs
will ask you if the message is to be signed before sending it.
(add-hook ’message-send-hook ’my-sign-message)
(defun my-sign-message ()
(if (yes-or-no-p "Sign message? ")
(mc-sign-message)))
Please note that Mailcrypt and Gnus don’t support proper MIME han-
dling as specified by the OpenPGP (RFC2440) specification. It just replaces
the text.

References
[1] Bruce Schneier, “Applied Cryptography: Protocols, Algorithms,
and Source Code in C”, 2nd edition, John Wiley & Sons, 1995
[2] Documentation to pgp and GnuPG, to be found in the man
pages and /usr/share/doc/packages/pgp resp. /usr/share/doc/
packages/gpg.
[3] GnuPG HOWTOs in english, french, german and spanish.

11