PGG with multiple GnuPG keys

PGG with multiple GnuPG keys

[Satyaki Das]

I've two GPG keys, the older one being a revoked key of
length 768. However with PGG, I can't decrypt any of the
messages that were encrypted for the older key. The problem is
that PGG feeds the pass phrase of my new key when trying to
decrypt messages with the old key.

The attached patch solves this by checking the message to be
decrypted to find the secret key in the user's ring that it
was encrypted for. Then the passphrase of this key is prompted
for, or read from the cache, and the correct passphrase given
to gpg.

Such functionality in PGG would be very helpful.

Thanks,
Satyaki

Index: pgg-gpg.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/pgg-gpg.el,v
retrieving revision 6.19
diff -u -r6.19 pgg-gpg.el
--- pgg-gpg.el	27 Oct 2003 21:46:41 -0000	6.19
+++ pgg-gpg.el	8 Nov 2003 21:17:43 -0000
@@ -103,6 +103,26 @@
 		 (substring (match-string 0) -8))))
        passphrase)))
 
+(defvar pgg-gpg-all-secret-keys 'unknown)
+
+(defun pgg-gpg-lookup-all-secret-keys ()
+  "Return all secret keys present in secret key ring."
+  (when (eq pgg-gpg-all-secret-keys 'unknown)
+    (setq pgg-gpg-all-secret-keys '())
+    (let ((args (list "--with-colons" "--no-greeting" "--batch"
+                      "--list-secret-keys")))
+      (with-temp-buffer
+        (apply #'call-process pgg-gpg-program nil t nil args)
+        (goto-char (point-min))
+        (while (re-search-forward "^\\(sec\\|pub\\):"  nil t)
+          (push (substring
+                 (nth 3 (split-string
+                         (buffer-substring (match-end 0)
+                                           (progn (end-of-line) (point)))
+                         ":")) 8)
+                pgg-gpg-all-secret-keys)))))
+  pgg-gpg-all-secret-keys)
+
 (defun pgg-gpg-lookup-key (string &optional type)
   "Search keys associated with STRING."
   (let ((args (list "--with-colons" "--no-greeting" "--batch"
@@ -147,7 +167,13 @@
 
 (defun pgg-gpg-decrypt-region (start end)
   "Decrypt the current region between START and END."
-  (let* ((pgg-gpg-user-id (or pgg-gpg-user-id pgg-default-user-id))
+  (let* ((current-buffer (current-buffer))
+         (message-keys (with-temp-buffer
+                         (insert-buffer-substring current-buffer)
+                         (pgg-decode-armor-region (point-min) (point-max))))
+         (secret-keys (pgg-gpg-lookup-all-secret-keys))
+         (key (pgg-gpg-select-matching-key message-keys secret-keys))
+         (pgg-gpg-user-id (or key pgg-gpg-user-id pgg-default-user-id))
 	 (passphrase
 	  (pgg-read-passphrase
 	   (format "GnuPG passphrase for %s: " pgg-gpg-user-id)
@@ -158,6 +184,14 @@
       (pgg-gpg-possibly-cache-passphrase passphrase pgg-gpg-user-id)
       (goto-char (point-min))
       (re-search-forward "^\\[GNUPG:] DECRYPTION_OKAY\\>" nil t))))
+
+(defun pgg-gpg-select-matching-key (message-keys secret-keys)
+  "Choose a key from MESSAGE-KEYS that matches one of the keys in SECRET-KEYS."
+  (loop for message-key in message-keys
+        for message-key-id = (and (equal (car message-key) 1)
+                                  (cdr (assq 'key-identifier message-key)))
+        for key = (and message-key-id (pgg-lookup-key message-key-id 'encrypt))
+        when (and key (member key secret-keys)) return key))
 
 (defun pgg-gpg-sign-region (start end &optional cleartext)
   "Make detached signature from text between START and END."

Re: PGG with multiple GnuPG keys

[Simon Josefsson]

Satyaki Das <satyakid@stanford.edu> writes:

> I've two GPG keys, the older one being a revoked key of
> length 768. However with PGG, I can't decrypt any of the
> messages that were encrypted for the older key. The problem is
> that PGG feeds the pass phrase of my new key when trying to
> decrypt messages with the old key.
>
> The attached patch solves this by checking the message to be
> decrypted to find the secret key in the user's ring that it
> was encrypted for. Then the passphrase of this key is prompted
> for, or read from the cache, and the correct passphrase given
> to gpg.
>
> Such functionality in PGG would be very helpful.

I believe this fixes a bug I mentioned earlier in the key passphrase
revamp, so I have installed this despite the feature freeze.  Thanks!

Re: PGG with multiple GnuPG keys

[Satyaki Das]

Simon Josefsson <jas@extundo.com> writes:

> I believe this fixes a bug I mentioned earlier in the key passphrase
> revamp, so I have installed this despite the feature freeze.  Thanks!

Thanks for the quick fix!

I have discovered another minor problem. With current CVS and no
customization, pgg asks for the passphrase of "satyaki" when I
try to sign  a message. Then when I receive encrypted mail, it
asks me for the passphrase of 7C06BDD9, which is the same key as
"satyaki".

I was about to produce a patch which would only store
(key-id,passphrase) tuples in the passphrase cache. But this time
I read the gnus.ding archives and found your post that said that
pgg-lookup-key was buggy and sometimes returns expired keys.

So I have now customized pgg-default-user-id to 7C06BDD9 and that
avoids the repeated queries for my passphrase. Is this the right
solution?

Thanks,
Satyaki

Re: PGG with multiple GnuPG keys

[Simon Josefsson]

"Satyaki Das" <satyakid@stanford.edu> writes:

> I have discovered another minor problem. With current CVS and no
> customization, pgg asks for the passphrase of "satyaki" when I
> try to sign  a message. Then when I receive encrypted mail, it
> asks me for the passphrase of 7C06BDD9, which is the same key as
> "satyaki".

Right.  The problem is that pgg-gpg.el doesn't know, during
decryption, that 7C06BDD9 is the same key as the key that eventually
gets used by the OpenPGP implementation when you request the "satyaki"
key when signing a message.  So it can't use the cached passphrase for
"satyaki" that it knows for the 7C06BDD9 key.

I think the best solution would be to change `pgg-gpg-sign-region' to
parse gpg's output (GOOD_PASSPHRASE) and find out what the key id was,
and then cache your passphrase under that hex key id (and under the
"satyaki" name).  Then the cache will work if you receive a message
for the 7C06BDD9 key id.  I have installed the patch below.  Does it
work?

> So I have now customized pgg-default-user-id to 7C06BDD9 and that
> avoids the repeated queries for my passphrase. Is this the right
> solution?

It is "right" in the sense that it may work for you.  My goal is that
only very few people will need to configure PGG; the default behaviour
should be Right.

2003-11-09  Simon Josefsson  <jas@extundo.com>

	* pgg-gpg.el (pgg-gpg-encrypt-region): Cache passphrase under hex
	key id too (for decryption).
	(pgg-gpg-sign-region): Likewise.

Index: pgg-gpg.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/pgg-gpg.el,v
retrieving revision 6.20
retrieving revision 6.21
diff -u -p -r6.20 -r6.21
--- pgg-gpg.el	9 Nov 2003 04:02:36 -0000	6.20
+++ pgg-gpg.el	9 Nov 2003 21:40:30 -0000	6.21
@@ -162,7 +162,10 @@ If optional argument SIGN is non-nil, do
       (pgg-gpg-process-region start end passphrase pgg-gpg-program args))
     (when sign
       (with-current-buffer pgg-errors-buffer
-	(pgg-gpg-possibly-cache-passphrase passphrase pgg-gpg-user-id)))
+	;; Possibly cache passphrase under, e.g. "jas", for future sign.
+	(pgg-gpg-possibly-cache-passphrase passphrase pgg-gpg-user-id)
+	;; Possibly cache passphrase under, e.g. B565716F, for future decrypt.
+	(pgg-gpg-possibly-cache-passphrase passphrase)))
     (pgg-process-when-success)))
 
 (defun pgg-gpg-decrypt-region (start end)
@@ -209,7 +212,10 @@ If optional argument SIGN is non-nil, do
     (pgg-as-lbt start end 'CRLF
       (pgg-gpg-process-region start end passphrase pgg-gpg-program args))
     (with-current-buffer pgg-errors-buffer
-      (pgg-gpg-possibly-cache-passphrase passphrase pgg-gpg-user-id))
+      ;; Possibly cache passphrase under, e.g. "jas", for future sign.
+      (pgg-gpg-possibly-cache-passphrase passphrase pgg-gpg-user-id)
+      ;; Possibly cache passphrase under, e.g. B565716F, for future decrypt.
+      (pgg-gpg-possibly-cache-passphrase passphrase))
     (pgg-process-when-success)))
 
 (defun pgg-gpg-verify-region (start end &optional signature)

PGG default values (was: Re: PGG with multiple GnuPG keys)

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> My goal is that only very few people will need to configure PGG; the
> default behaviour should be Right.

Looking at my ~/.emacs I (only) have these two:

 '(pgg-encrypt-for-me t)
 '(pgg-passphrase-cache-expiry 12345678)

The defaults are nil and 16 respectively.

I think the first one should default to t.  Sending encrypted messages
and later discovering you can't read them yourself would be a bad
experience.  People that understands enough to worry about a default
setting of t will certainly be able to search for the variable in the
manual and disable it.  Opinions?

For the second one, I think 16 seconds is a rather pointless cache
(maybe only to fix the extra invocation of gpg for GCC).  But I don't
know what a good default would be.  An hour?  A workday?  Opinions?
As you can infer from my settings, I lean towards infinity, but
perhaps a more conservative setting should be used.

I suspect a good feature request at this point would be to add a
yes-or-no-p on whether to use a cached passphrase, but until someone
else mention I'll pretend I haven't thought about it. :-) If such a
query is added, having an infinite passphrase cache might make sense.

Re: PGG default values

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Looking at my ~/.emacs I (only) have these two:
>
>  '(pgg-encrypt-for-me t)
>  '(pgg-passphrase-cache-expiry 12345678)
>
> The defaults are nil and 16 respectively.
>
> I think the first one should default to t. [..]  Opinions?

I agree.

> For the second one, I think 16 seconds is a rather pointless cache
> (maybe only to fix the extra invocation of gpg for GCC).

Yup, I think GCC was the reason for that value.

Re: PGG default values (was: Re: PGG with multiple GnuPG keys)

[Satyaki Das]

Simon Josefsson <jas@extundo.com> writes:

> Looking at my ~/.emacs I (only) have these two:
> 
>  '(pgg-encrypt-for-me t)
>  '(pgg-passphrase-cache-expiry 12345678)
> 
> The defaults are nil and 16 respectively.
> 
> I think the first one should default to t.  Sending encrypted messages
> and later discovering you can't read them yourself would be a bad
> experience.  People that understands enough to worry about a default
> setting of t will certainly be able to search for the variable in the
> manual and disable it.  Opinions?

Yes it should default to t. I actually didn't know about the
option. But I already have some option in ~/.gnupg/options that
does the equivalent.

> For the second one, I think 16 seconds is a rather pointless cache
> (maybe only to fix the extra invocation of gpg for GCC).  But I don't
> know what a good default would be.  An hour?  A workday?  Opinions?

Personally I have it set to 1000000. But the paranoid among us
will prefer a smaller value. I would say something of the order of
10 minutes shouldn't be too bad.

Satyaki

Re: PGG default values

[Simon Josefsson]

"Satyaki Das" <satyakid@stanford.edu> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Looking at my ~/.emacs I (only) have these two:
>> 
>>  '(pgg-encrypt-for-me t)
>>  '(pgg-passphrase-cache-expiry 12345678)
>> 
>> The defaults are nil and 16 respectively.
>> 
>> I think the first one should default to t.  Sending encrypted messages
>> and later discovering you can't read them yourself would be a bad
>> experience.  People that understands enough to worry about a default
>> setting of t will certainly be able to search for the variable in the
>> manual and disable it.  Opinions?
>
> Yes it should default to t. I actually didn't know about the
> option. But I already have some option in ~/.gnupg/options that
> does the equivalent.

I have made the change.

I'm not sure the implementation is perfect though, it looks like:

	   (if recipients
	       (apply #'nconc
		      (mapcar (lambda (rcpt)
				(list "--remote-user" rcpt))
			      (append recipients
				      (if pgg-encrypt-for-me
					  (list pgg-gpg-user-id)))))))))

Arguable --encrypt-to should be used for the encrypt-for-me user.
--remote-user is not documented in 'gpg --help', so I'm not sure what
the semantics of it is.

>> For the second one, I think 16 seconds is a rather pointless cache
>> (maybe only to fix the extra invocation of gpg for GCC).  But I don't
>> know what a good default would be.  An hour?  A workday?  Opinions?
>
> Personally I have it set to 1000000. But the paranoid among us
> will prefer a smaller value. I would say something of the order of
> 10 minutes shouldn't be too bad.

On the other hand, of all users, it is the paranoids that is more
likely to actually read the manual or the source code.  So they would
find the variable and could frob it to whatever setting they prefer,
So we'd might as well have a default value that makes things enjoyable
for the majority of users.  (Assuming the majority of Gnus users are
non-paranoids...)

Anyone knows what KMail, mutt, Mozilla etc do?

Re: PGG default values

[Jorge Godoy]

Simon Josefsson <jas@extundo.com> writes:

> I think the first one should default to t.  Sending encrypted messages
> and later discovering you can't read them yourself would be a bad
> experience.  People that understands enough to worry about a default
> setting of t will certainly be able to search for the variable in the
> manual and disable it.  Opinions?

I'd rather stick with that option in the ~/.gnupg/options file
only. There you can say if you want the message / document / whatever
to be encrypted for you or not. This is a better solution since it is
global for all programs that use GPG. 

> For the second one, I think 16 seconds is a rather pointless cache
> (maybe only to fix the extra invocation of gpg for GCC).  But I
> don't know what a good default would be.  An hour?  A workday?
> Opinions?  As you can infer from my settings, I lean towards
> infinity, but perhaps a more conservative setting should be used.

I use 5 minutes. Usually I'm sending more than one encrypted message,
but I don't want the passphrase to be cached for too long. I used to
use one minute, but it bored me. 

> I suspect a good feature request at this point would be to add a
> yes-or-no-p on whether to use a cached passphrase, but until someone
> else mention I'll pretend I haven't thought about it. :-) If such a
> query is added, having an infinite passphrase cache might make
> sense.

I don't think so. This somewhat violates the idea of knowing the
passphrase to use the encryption. From 3 to 5 minutes is what I think
ideal for a cache (and I think that this is a lot of time...). 


See you,
-- 
Godoy.     <godoy@ieee.org>

Re: PGG default values

[Simon Josefsson]

Jorge Godoy <godoy@ieee.org> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> I think the first one should default to t.  Sending encrypted messages
>> and later discovering you can't read them yourself would be a bad
>> experience.  People that understands enough to worry about a default
>> setting of t will certainly be able to search for the variable in the
>> manual and disable it.  Opinions?
>
> I'd rather stick with that option in the ~/.gnupg/options file
> only. There you can say if you want the message / document / whatever
> to be encrypted for you or not. This is a better solution since it is
> global for all programs that use GPG. 

Right, but do most users enable this?  Is it enabled by default by
GnuPG?  If so, requesting encrypt-for-me again should be harmless, so
wouldn't cause any problems.  If not, people might send encrypted
messages they can't read later on, which is bad.  So I only see
advantages with a default value of t, but no disadvantages.

>> For the second one, I think 16 seconds is a rather pointless cache
>> (maybe only to fix the extra invocation of gpg for GCC).  But I
>> don't know what a good default would be.  An hour?  A workday?
>> Opinions?  As you can infer from my settings, I lean towards
>> infinity, but perhaps a more conservative setting should be used.
>
> I use 5 minutes. Usually I'm sending more than one encrypted message,
> but I don't want the passphrase to be cached for too long. I used to
> use one minute, but it bored me. 
>
>> I suspect a good feature request at this point would be to add a
>> yes-or-no-p on whether to use a cached passphrase, but until someone
>> else mention I'll pretend I haven't thought about it. :-) If such a
>> query is added, having an infinite passphrase cache might make
>> sense.
>
> I don't think so. This somewhat violates the idea of knowing the
> passphrase to use the encryption. From 3 to 5 minutes is what I think
> ideal for a cache (and I think that this is a lot of time...). 

Thanks for your opinion.  So now we have suggestions for ~5 minutes
and ~10 minutes, if I recall correctly.

Re: PGG default values

[Jorge Godoy]

Simon Josefsson <jas@extundo.com> writes:

> Right, but do most users enable this?  Is it enabled by default by
> GnuPG?  If so, requesting encrypt-for-me again should be harmless, so
> wouldn't cause any problems.  If not, people might send encrypted
> messages they can't read later on, which is bad.  So I only see
> advantages with a default value of t, but no disadvantages.

IIRC, the default is off. The reasoning was on the documentation (I
think... It's been a lot of time since I read it fully). 

> Thanks for your opinion.  So now we have suggestions for ~5 minutes
> and ~10 minutes, if I recall correctly.

This is what I've read too... 

-- 
Godoy.     <godoy@ieee.org>

Re: PGG with multiple GnuPG keys

[Satyaki Das]

Simon Josefsson <jas@extundo.com> writes:

>         The problem is that pgg-gpg.el doesn't know, during
> decryption, that 7C06BDD9 is the same key as the key that eventually
> gets used by the OpenPGP implementation when you request the "satyaki"
> key when signing a message.  So it can't use the cached passphrase for
> "satyaki" that it knows for the 7C06BDD9 key.
> 
> I think the best solution would be to change `pgg-gpg-sign-region' to
> parse gpg's output (GOOD_PASSPHRASE) and find out what the key id was,
> and then cache your passphrase under that hex key id (and under the
> "satyaki" name).  Then the cache will work if you receive a message
> for the 7C06BDD9 key id.  I have installed the patch below.  Does it
> work?

Yes, it does. It caches both "satyaki" and "7C06BDD9" and that is
the right way.

> > So I have now customized pgg-default-user-id to 7C06BDD9 and that
> > avoids the repeated queries for my passphrase. Is this the right
> > solution?
> 
> It is "right" in the sense that it may work for you.  My goal is that
> only very few people will need to configure PGG; the default behaviour
> should be Right.

Yes, that is a worthy goal. I have removed the customization for
pgg-default-user-id now, thanks!

Satyaki