[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: So I received a gpg-signed email, can I trust it?



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 <enrico@enricozini.org>" imported
    gpg: no ultimately trusted keys found
    gpg: Total number processed: 1
    gpg:               imported: 1
    gpg: Good signature from "Enrico Zini <enrico@enricozini.org>" [unknown]
    gpg:                 aka "Enrico Zini <enrico@debian.org>" [unknown]
    gpg:                 aka "Enrico Zini <enrico@truelite.it>" [unknown]
    gpg:                 aka "Enrico Zini <enrico@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

Attachment: signature.asc
Description: PGP signature


Reply to: