better heuristic for choosing an encryption key based on a User ID
Closed, ResolvedPublic

Description

Currently, if a user asks gpg to encrypt data to a name (as opposed to a key
ID), gpg selects the first valid key in its keyring that has a matching User ID
(regardless of the calculated validity of the User ID itself).

This is problematic in a number of use cases, and can cause potentially serious
security problems if data is encrypted to the wrong key.

A proposed new heuristic for selecting a key is:

Select the most recently-generated valid key that has a non-revoked,
non-expired encryption-capable subkey, and has a matching user ID with
the highest-available-class of calculated validity for the given User
ID.

discussion and details about the concern can be found in gnupg-users:

http://lists.gnupg.org/pipermail/gnupg-users/2009-September/037395.html

dkg added a subscriber: dkg.
werner added a subscriber: werner.Sep 25 2009, 5:38 PM

We can implement that in 2.1 after having replaced the current keyring based DB
with the Keybox based one. The latter is far more efficient and does not
require sequential scans all the time. Some breakage will anyway happen and
thus a new selection strategy, i.e. a well defined one, won't harm either.

Wilson added a subscriber: Wilson.May 30 2011, 7:51 PM

If a recipient has more than one key - for instance outdated keys, needed for
decryption of older messages, it is sometimes difficult or impossible to make a
mail application encrypt with the correct key. Recently I fought this one, and
got around the problem in both KMail and Thunderbird by demoting the Trust
status of the older key, but although this works it's not ideal for the
following reason.

Both mail agents have a mechanism for setting default keys for recipients, KMail
by using the recipient's addressbook record and/or by marking default keys in
KGpg, and Thunderbird by the Per-Recipient rules. When a user has set the
default using one of these he expects that new default to be used for
encryption. In fact the recipient is quite likely to find that the older key
has been used, and it may not be possible to decrypt the message - my
correspondent had a corrupt private key.

Ideally, GPG should respect the default key set in the mail-agent being used.
If that is not possible, perhaps it would be possible to make some easy-ish way
for the user to tell gpg which key should be considered default, instead of
simply taking the first record found. I could find nothing about this in the
man page.

neal closed this task as Resolved.Nov 5 2015, 2:32 PM
neal claimed this task.

Comitted in a958ffd.

neal reopened this task as Open.Nov 5 2015, 2:34 PM

Whoops, I closed the wrong bug report, sorry. Reopening.

neal added a comment.Nov 6 2015, 12:39 PM

Note: T1232 is related.

Just noticed this issue as it was mentioned in T2359 which is "my" issue
about this topic ;-)
I've actually implemented the algorithm outlined in T1143 (dkg on Sep 23 2009, 06:53 PM / Roundup) in libkleo/ QGgpME
for a better opportunistic encryption support in kmail (
https://phabricator.kde.org/T2520 )

Werner told me that something like that will be done in GnuPG itself. Afaik the
current plan is to have --locate-keys use a similar algorithm to return exactly
one "best" key if a mailbox is given. And if I understood werner correctly this
would then also be the key used when you would do a "gpg -er <mailbox>"

Should this be closed as Superseded?

werner closed this task as Resolved.Sep 28 2016, 9:17 AM
werner added a project: Duplicate.

Duplicate of T2359