Hi Enrico, On Fri, 08 Jul 2016 at 11:21:27 +0200, Enrico Zini wrote: > gpg --verify tells me of a short key ID:
In fact the issuer subpacket is 8-bytes long [0], hence contains the
long key ID of the signer, as seen using ‘--list-packets’:
~$ gpg --list-packets </tmp/testsignature
# off=0 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid 03D6568C837275A9
version 4, created 1467968582, md5len 0, sigclass 0x01
digest algo 8, begin of digest ce ca
hashed subpkt 2 len 4 (sig created 2016-07-08)
subpkt 16 len 8 (issuer key ID 03D6568C837275A9)
data: [4092 bits]
(Where ‘/tmp/testsignature’ is the signature part of your previous
‘/tmp/testmessage’.) It's unfortunate that gpg used to only show the
second half of the subpacket (the “short key ID”) by default. However
2.1.13 introduces a new ‘--keyid-format=none’ - which is the new default
— to stop using keyids whenever possible: instead, the key fingerprint
is shown when available (e.g., for keys in the keyring); otherwise it
falls back to the “long key ID”.
~$ gpg --version | head
gpg (GnuPG) 2.1.13
libgcrypt 1.7.1-beta
~$ rm /tmp/keyring/gpg.conf
$ gpg --homedir /tmp/keyring --verify /tmp/testmessage
gpg: Signature made Fri 08 Jul 2016 11:03:02 AM CEST using RSA key ID
03D6568C837275A9
gpg: Can't check signature: No public key
$ gpg --homedir /tmp/keyring
--keyserver=hkps://hkps.pool.sks-keyservers.net
--keyserver-options=auto-key-retrieve --verify /tmp/testmessage
gpg: Signature made Fri 08 Jul 2016 11:03:02 AM CEST using RSA key ID
03D6568C837275A9
gpg: requesting key 03D6568C837275A9 from hkps server
hkps.pool.sks-keyservers.net
gpg: /tmp/keyring/trustdb.gpg: trustdb created
gpg: key 634F4BD1E7AD5568: public key "Enrico Zini <enr...@enricozini.org>"
imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
gpg: Good signature from "Enrico Zini <enr...@enricozini.org>" [unknown]
gpg: aka "Enrico Zini <enr...@debian.org>" [unknown]
gpg: aka "Enrico Zini <enr...@truelite.it>" [unknown]
gpg: aka "Enrico Zini <enr...@enricozini.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 1793 D6AB 7566 3E6B F104 953A 634F 4BD1 E7AD 5568
Subkey fingerprint: 1CC0 1267 007F ABE6 5846 6857 03D6 568C 8372 75A9
> I can switch to long key IDs, but I still get something that can match
> multiple keys:
64-bits key IDs are indeed vulnerable to collision attacks, but unlike
their 32-bits counterparts they are not known to be vulnerable to
preimage attacks. Thus long key ID impersonation is not known to be
possible at this point.
The OpenPGP Working Group is currently discussing an RFC 4880 revision
[1]. In particular, a new “Issuer Fingerprint” subpacket has been
proposed to deprecate the issuer subpacket and store full issuer
fingerprints rather than key IDs in OpenPGP signatures.
https://mailarchive.ietf.org/arch/msg/openpgp/LFtg4NzKEHIa8qTa4F0t7mr3JJQ
This would solve the problem of key impersonation if preimage attacks
become practical on 64-bits key IDs in the future, as
‘--keyserver-options=auto-key-retrieve’ would then be able to query the
issuing key based on its fingerprint not its (possibly colliding)
64-bits key ID. Moreover, I hope this would also make gpg able to
import two different keys colliding on their 64-bits key ID, which
currently fails (as keys are indexed by their 64-bits key ID ;-)
Cheers,
--
Guilhem.
[0] https://tools.ietf.org/html/rfc4880#section-5.2.3.5
[1] https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis
signature.asc
Description: PGP signature
