GPG encrypts using a key of a partial recipient match instead of exact match
Closed, WontfixPublic

Description

gpg 2.0.22 (Linux) and 1.4.19 (Windows) both sign a message using a partial email match
instead
of exact match even if one is available. This could in theory be used to fool end user to
sign
the message with an attacker's key instead of the intended recipient's key.

How to reproduce:

Create a non-expiring 1024-bit key using DSA and Elgamal for
"Test User <test.user@domain.tld>"

Create a non-expiring 1024-bit key using DSA and Elgamal for
"Real User <user@domain.tld>"

Export these two public keys and import them in another user's (here
another.user@nonexisting.tld) keyring.

$ gpg --list-keys

pub 1024D/C54B0EF7 2016-09-14
uid Test User <test.user@domain.tld>
sub 1024g/1B3AFE1A 2016-09-14

pub 1024D/326E92B6 2016-09-14
uid Real User <user@domain.tld>
sub 1024g/6DF17CD7 2016-09-14

pub 1024D/2DD32AC0 2016-09-14
uid Another User <another.user@nonexisting.tld>
sub 1024g/61CEB02E 2016-09-14

Encrypt and sign a message for user@domain.tld
$ gpg -se -r "user@domain.tld" -a|gpg

You need a passphrase to unlock the secret key for
user: "Another User <another.user@nonexisting.tld>"
1024-bit DSA key, ID 2DD32AC0, created 2016-09-14

Hello, this is a test message.
gpg: encrypted with 1024-bit ELG-E key, ID 1B3AFE1A, created 2016-09-14

"Test User <test.user@domain.tld>"

gpg: decryption failed: secret key not available

The message was actually signed using test.user@domain.tld keys even when user@domain.tld
was
requested.

Attached are the public keys (2 pubkeys, ascii armored) used in this bug report.

Versions found affected:
(Windows, Git Bash)
$ gpg --version
gpg (GnuPG) 1.4.19
Copyright (C) 2015 Free Software Foundation, Inc.

(Linux RHEL 7.2)
$ gpg --version
gpg (GnuPG) 2.0.22
libgcrypt 1.5.3
Copyright (C) 2013 Free Software Foundation, Inc.

(Raspbian)
$ gpg --version
gpg (GnuPG) 1.4.12
Copyright (C) 2012 Free Software Foundation, Inc.

Details

Version
1.4, 2.0.22, master
tvenhola set Version to 2.0.22.Sep 14 2016, 2:01 PM
tvenhola added a subscriber: tvenhola.
justus added a subscriber: justus.Sep 14 2016, 3:25 PM

Indeed, this is unfortunate, but not as bad as you make it sound (unless the
user uses always trust).

Note that this is not about signing (which uses the private key), but about
encryption. I've changed the bug title accordingly.

This happens also with master, and it seems the order of keys in the public
keyring is important:

teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.TR2cSoWHMb/pubring.kbx' created
gpg: /tmp/tmp.TR2cSoWHMb/trustdb.gpg: trustdb created
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: 1A7265CF27F9E78E: There is no assurance this key belongs to the named user
sub rsa2048/1A7265CF27F9E78E 2016-09-14 test.user@example.org
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Primary key fingerprint: CA77 8656 2AAC BBB2 6A50 3A50 8D62 594F 1FE9 0C7B

      Subkey fingerprint: 52CB E9DC 1812 9F78 3054  6569 1A72 65CF 27F9 E78E

It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting
130 teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % export
GNUPGHOME=$(mktemp -d)
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keybox '/tmp/tmp.Hfjbb2jvji/pubring.kbx' created
gpg: /tmp/tmp.Hfjbb2jvji/trustdb.gpg: trustdb created
gpg: key 00988FEC00B5CA77: public key "user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % gpg2 --import test.user.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 8D62594F1FE90C7B: public key "test.user@example.org" imported
gpg: Total number processed: 1
gpg: imported: 1
teythoon@europa ~/repos/g10/gnupg/obj (git)-[master] % echo huhu|gpg2 -e -r
"user@example.org" -a|gpg2
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: DAB278A8736B0D2C: There is no assurance this key belongs to the named user
sub rsa2048/DAB278A8736B0D2C 2016-09-14 user@example.org
Primary key fingerprint: 6680 B181 D853 CEB5 6671 ECC7 0098 8FEC 00B5 CA77

      Subkey fingerprint: 3909 7C31 399C A746 87B3  5D74 DAB2 78A8 736B 0D2C

It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

gpg: signal gpgInterrupt: signal caught ... exiting
Interrupt caught ... exiting

justus renamed this task from GPG signs using a key of a partial recipient match instead of exact match to GPG encrypts using a key of a partial recipient match instead of exact match.Sep 14 2016, 3:25 PM
justus lowered the priority of this task from High to Normal.
justus added a project: gnupg (gpg22).
justus changed Version from 2.0.22 to 1.4, 2.0.22, master.
werner added a project: gnupg (gpg21).
werner added a subscriber: werner.

Look at what the man page says on how to specify a user id:

  • By exact match on an email address. This is indicated by enclosing the email address in the usual way with left and right angles. <heinrichh@uni-duesseldorf.de>

The default however is a substring match on the entire user id. Note that
issue2359 is also about this and it may introduce a slighlty modified way on how
a key is specified by a mail address.

Should only be chnaged for master, though.

werner closed this task as Wontfix.
werner claimed this task.

Won't we fixed for 1.4 and 2.0 (which is too close to EOL). Has been fixed for master; see T2359.