MailCrypt for the Gnu Privacy Guard (GPG) -Brian Warner 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 . 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 . 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. KNOWN PROBLEMS: key fetching: 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 them works). multiple recipients: 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. wrapper script 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. SMALLER PROBLEMS: trust: 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 then? 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 not. 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 advertisement. 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, -Brian Warner