6.0.0-beta1
9/2/25

[#9493] GPG encryption chooses wrong key.
Summary GPG encryption chooses wrong key.
Queue IMP
Queue Version 4.3.9
Type Bug
State Resolved
Priority 2. Medium
Owners Horde Developers (at) , slusarz (at) horde (dot) org
Requester ans+horde (at) immerda (dot) ch
Created 01/05/2011 (5354 days ago)
Due
Updated 01/20/2011 (5339 days ago)
Assigned 01/05/2011 (5354 days ago)
Resolved 01/20/2011 (5339 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
01/20/2011 08:51:01 AM Michael Slusarz Comment #7
State ⇒ Resolved
Reply to this comment
However, we should do a better job of verifying that the returned 
keyIDs contain the email address requested - although this requires 
us to download each returned key and verify.
Added more thorough checking to H4 - verify e-mail by downloading key 
and parsing.  Previous algorithm should work 99.9% of the time so this 
isn't ultra-critical and will not be backported.
01/20/2011 08:48:58 AM Git Commit Comment #6 Reply to this comment
Changes have been made in Git for this ticket:

Bug #9493: More thorough checking when retrieving PGP key by e-mail
Add basic keyserver retrieval tests

http://git.horde.org/horde-git/-/commit/e9de4fa5e82572dfd0d31190f034deaf4192bca4
01/05/2011 07:02:52 PM Michael Slusarz Comment #5
Assigned to Michael Slusarz
Assigned to Horde DevelopersHorde Developers
State ⇒ Assigned
Priority ⇒ 2. Medium
Reply to this comment
The lookup from the horde addressbook has been fixed.

We don't do an exact search for email addresses from the PGP server - 
mainly because it is not possible.  See: 
http://pgp.mit.edu/extracthelp.html

However, we should do a better job of verifying that the returned 
keyIDs contain the email address requested - although this requires us 
to download each returned key and verify.
01/05/2011 06:52:38 PM CVS Commit Comment #4 Reply to this comment
Changes have been made in CVS for this ticket:

Bug: 9493
Merge from git:
commit 88c2c490cda7345700a72fd14e4e9647db63c04d
Author: Michael M Slusarz <slusarz@curecanti.org>
Date:   Wed Jan 5 11:43:36 2011 -0700
Bug #9493: Do strict e-mail search when retrieving encryption keys
http://cvs.horde.org/diff.php/imp/lib/Crypt/PGP.php?rt=horde&r1=1.90.2.27&r2=1.90.2.28&ty=u
http://cvs.horde.org/diff.php/imp/lib/Crypt/SMIME.php?rt=horde&r1=1.45.2.25&r2=1.45.2.26&ty=u
01/05/2011 06:51:20 PM Git Commit Comment #3 Reply to this comment
Changes have been made in Git for this ticket:

Bug #9493: Do strict e-mail search when retrieving encryption keys

http://git.horde.org/horde-git/-/commit/8158680e6e32f02cc592ee4bd5797fec710f91fc
01/05/2011 04:04:29 PM ans+horde (at) immerda (dot) ch Comment #2 Reply to this comment
i just realized that you don't use gpg keyrings to store the keys (i 
think) and therefore did some more tests:

when i wrote an email from someone@bar.com to o@bar.com without any 
keys in my horde profile it uses the correct key. (maybe because o@bar 
is returned before foo@bar from the keyserver or maybe because it 
works correct. i cannot tell.)

if i import the foo@bar key into horde and then write an email to 
o@bar it uses the key of foo@bar instead of o@bar.

so the lookup from the horde profile is broken.

the lookup from the keyser is probably also broken because i did not 
see any escaping in the pgp.php code, but i couldn't reproduce it so 
far.
01/05/2011 03:34:49 PM ans+horde (at) immerda (dot) ch Comment #1
Priority ⇒ 3. High
Type ⇒ Bug
Summary ⇒ GPG encryption chooses wrong key.
Queue ⇒ IMP
Milestone ⇒
Patch ⇒ No
State ⇒ Unconfirmed
Reply to this comment
If user o@bar.com writes an encrypted email to foo@bar.com imp uses 
the publickey of o@bar.com instead of foo@bar.com.

I suspect (but did not yet try this) that this would happen also if 
user someone@bar.com writes an email to o@bar.com but has the key of 
foo@bar.com in his keyring and this key is above the key of o@bar.com
As this is a potential security issue, i marked this bug as high.

most probably you do not escape the email address properly before 
searching the key. in gpg the default lookup strategy is string match. 
if you want to lookup an emailadress, you should use <foo@bar.com>

Saved Queries