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