MailCrypt for the Gnu Privacy Guard (GPG)
-Brian Warner <firstname.lastname@example.org>
The GPG support in mailcrypt is at an alpha level and is at least ready for
adventurous users to try out. There are a number of known problems, listed
below. Please send any and all comments, bug reports, patches, enhancements,
etc, to me at <email@example.com>.
First off, what is GPG? GnuPG (formerly known as "g10") is a GPL'ed
replacement for PGP that implements the OpenPGP standard that is slowly making
its way through the IETF OpenPGP working group (it may well be a Proposed
Standard by now.. check your local RFC mirror). It does not implement any
algorithms that cannot be provided under the GPL; that means no RSA
(patented/licensed) or IDEA, so in general it does not interoperate with pgp
2.6 . However it should work with pgp 5.0, pgp 6.0 (theoretically), and of
course itself, and it has a shared-object-loading plugin mechanism whereby new
algorithms can be loaded, so of all the pgpgpgish programs out there it has
the best chance of being compatible. GPG is being developed entirely outside
the USA because of that silly ITAR nonsense.
The GPG home page is at <http://www.gnupg.org/>. The mailcrypt support for it
(contained mostly in mc-gpg.el) is mostly thoroughly tested against GPG
version 1.0.6, so you should use that version or a later one. However, it
ought to work fairly well with version 0.9.3 or later.
There is no key fetching. I don't know of any GPG keyservers yet. When some
become available, I'll add support for them. If you try to verify the
signature on a message when you don't have the signator's key, the code will
offer to fetch the key for you. If you answer "yes, please fetch that key",
you'll just get an error message.
the --throw-keyid encryption option is not yet supported (a.k.a. "stealth
mode", where the recipients' keyids are not included in the message, and the
potential receiver must simply try all of their secret keys to see if any of
not a problem with gpg 0.4.3 or later. In --batch mode, older versions did
not properly decrypt messages that were encrypted to multiple recipients,
including messages encrypted with the "mc-encrypt-for-me" option. If you
can't use a newer version of gpg for decryption, you need to have your
correspondents to send you messages that are only encrypted to you.
not a problem with gpg 0.4.1 or later. Older versions don't handle the
"--passphrase-fd 0" option correctly, and need a wrapper script called
"gpgwrap.pl". If you can't run a newer version of gpg, get the wrapper
script from mailcrypt-3.5b7.
You want to be confident that the keys you encrypt messages to are actually
owned by the person named in the key, and not just some random goofball who
likes to create and distribute keys with other people's names on them. Think
about how you obtained someone's key: did they give it to you in person?
Then it's probably the right one. Did they mail it to you? Did you get it
by fingering their account? Chances are good that it's valid. Did it come
from a keyserver? Anyone could have put it there. Suppose it's signed by
someone that you trust to check the key's validity. Should you trust it
This is the PGP (and GPG) "web of trust", and for more details you should
check the pgp 2.6 documentation. Here's what mailcrypt-gpg does with trust:
encryption: pass --always-trust in, forcing all keys to be trusted even
if you don't have a trust path. This is necessary because
without it, untrusted keys are just dropped, and your message
won't be readable by all the folks you addressed it to.
decryption: report the trust value in the echo area when checking a
signature. TRUST_ULTIMATE means the message is signed by one of
your own keys. TRUST_FULLY and TRUST_MARGINAL are for keys that
you trust via some path that starts with a key that you have
signed with one of your private keys. For each public key in
your keyring, you can specify (with --edit-key) how much you
trust that key to sign other keys. The sum of these trust
values along the path from your private key to the signator's
key determines the amount of "owner trust" you have in that key
and determines the TRUST_ value displayed when checking a
signature. TRUST_UNDEFINED means that you do not have a trust
path to that key.
verify: same as decryption
Ideally, if you try to encrypt to an untrusted key, mailcrypt should give
you a warning. A future version may do this.
key names are passed through the shell enclosed in ""s. If the names have any
quotes in them or seriously weird characters ("!" comes to mind) then the
shell may have problems. I think the GPG key-generation process may restrict
the key names to something reasonable, but other programs (pgp5.0?) might
there is some debugging code left around. Some temporary buffers may get
created but not deleted (names generally start with " *mailcrypt"). Some
temporary files (/tmp/mailcrypt-gpg-*) may get left around.
mc-gpg.el depends upon /bin/sh to run GPG while redirecting several file
descriptors to temp files (to collect three different output streams). If you
don't have /bin/sh, it probably won't work.
I probably don't have enough (save-excursion ) and (unwind-protect ) clauses.
If you run into an error halfway through an operation, or if you hit C-g and
abort an operation, you might not be put back in the buffer you started with.
Just find your original buffer and hit "undo" if necessary. All mailcrypt
operations can be undone with "undo".
I've tested a number of cases, but I haven't been able to create test
messages for some of them, like signed messages that have been tampered with.
(clearsigned messages with tampering are caught, but I don't know how to
modify an unclear signed message to invalidate the signature without also
damaging the CRC added by the ascii armor). If you know how to create such a
message, please send it to me so I can test those cases too. The same goes
for the (probably much more difficult) case of encrypted+signed messages that
decrypt OK but have bad signatures.
REALLY TINY PROBLEMS:
mc-gpg-comment works fine, I just disabled it to let GPG insert it's own
mc-gpg-alternate-keyring might work. It should probably be split up so you
can add public and private rings separately.
mailcrypt is designed to handle multiple encryption schemes. Decryption is
supposed to work by trying each one in order, stopping after one of them
succeeds. mc-gpg.el will have two problems with this. One is that my code
will probably error out upon failure instead of returning a failure and
allowing the top-level scheme loop to try another scheme. The second is that
pgp2.6, pgp5.0, and gpg all use the same packet format, so it isn't generally
obvious what scheme should be used (unless you look for a version or comment
header in the armored message). This is complicated by the fact that they can
use each other's keys, to a certain extent. I don't have a good answer for
this yet. One is to keep all your keyrings separate. One is to figure out how
to use GPG for everything and merge all your keyrings into your GPG
keyring. If you manage that one, let me know about it.
WILD ENHANCEMENT IDEAS:
it would be cool to incorporate some trust status reporting into this code.
you give it a keyid and it shows you the best trust path to that key.
key management from within emacs: sign keys, edit trust.
set algorithm preferences or extra options (--rfc1991) by recipient ID. this
might help pgp compatibility
tab-completion on keyids, using --list-keys or --list-secret-keys.
rfc2015 operation (MIME multipart/encrypted). see SEMI for the pgp version.
create a detached signature from the current buffer
Share and Enjoy,