0xdeadbeef comes of age: making keysteak with GnuPG

David Leon Gil coruus at gmail.com
Fri Oct 10 17:06:07 CEST 2014


Replying a little late to Thijs's message to oss-security. First:

"keysteak", a PoC keyserver-in-the-middle that generates fake V3
public keys with the same long keyid as V4 public keys requested from
a keyserver. It uses the classic 0xdeadbeef attack and a (novel?) V3
key/V4 signature  crossgrade.*) Available at:
https://github.com/coruus/cooperpair/tree/master/keysteak

As an example, a spoofed key for a Linux distro is attached. You can
confirm that the spoofed key is *not* the real key (which is available
at https://tails.boum.org/tails-signing.key) by doing either
       gpg2 --list-packets spoofed_tails.asc
or,
       mkdir test; chmod go-rwx test
       gpg2 --home ./test --import spoofed_tails.asc
       gpg2 --home ./test -k --fingerprint

* V3 signatures are not accepted without an explicit option in 2.1;
they produce a warning in 2.0 (and maybe recent 1.x as well).

(In summary: If you don't use the WoT, get OpenPGP keys via HTTPS.
E.g.: keybase.io or pgp.mit.edu (the latter thanks to Yan Zhu's
lobbying).)

Some details/comments:

Date: Mon, 1 Sep 2014 20:33:20 +0200
From: Thijs Kinkhorst <thijs at ...ian.org>
Subject: gpg blindly imports keys from keyserver responses

> It is however argued that . . . specifying the full fingerprint is a safe way to retreive
> a key for a known-good fingerprint. But this argument is again somewhat countered
> by an attack on V3 [fingerprints] making such a request dubious again.

This isn't quite right.

- V3 fingerprints are 16 bytes (32 hex digits) long; they're an MD5
digest of the RSA modulus.
- V4 fingerprints are 20 bytes (40 hex digits) long; they're an SHA1
digest of the public key packet (kind of).

So: V3 and V4 fingerprints are easily distinguishable. Long keyids aren't:

- V3 long keyids are 8 bytes long. They're the low 8 bytes of the RSA modulus.
- V4 long keyids are 8 bytes long. They're the low 8 bytes of the V4
fingerprint.

As Greg Rose demonstrated (and Paul Leyland had earlier noted)[1],
this makes it trivial to forge long V3 keyids: You can control up to
about half the bits of an RSA modulus without affecting the strength
of the resulting key.

Note: Once you have a key with a given 64-bit keyid in your keychain,
GnuPG will not import any other key with the same 64-bit keyid.[2]
Even if you specify the new key by fingerprint.

It's been 18 years since the 0xdeadbeef attack. Maybe it's time to
deprecate V3 OpenPGP keys?

(There's a discussion on gnupg-devel on this presently; I am hopeful...)

[1] Raph Levien's excellent explanation of the history and math of the
0xdeadbeef attack:
https://groups.google.com/forum/#!topic/sci.crypt/JSSM6NbfweQ

[2] Thus the spoofed key and the real key are a "cooper pair".
-------------- next part --------------
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQIPA1IAAAAAAAEP+wTjDob0f11hgMumSe9OA3z05hFwsgDpr152QACoZYVt4rRp
YVqBFCv3cckvd6mgldmxe7MdSa5C+IgWRiMYt8xIJKCN4gF/tNumsOjshptVLkiO
bdb2XI+AqwuUbVIzNzKr+zYVhHOUwm87QA5HapVo1Mm4zE2i99YLV30BfDxQMQOV
Ux6cnxLicS6edSvHqwO0rlOJGwp8XJT/DLJvfmkdHtkv4FNLKDEHLhsC9xSnm5y6
hrkwghRDJO69NenJWJbqAK63NIEGZhdgyaFBwls3JDIqKPenOjORoybuqw69MPcM
snk3Z0cXHD+bHUPm0cQNhFiZYEWXQMjm9RTW5AvP0JeW2RFBPBzqtxUKntQBrdRF
GU8Voas9SXUyBiaebrx5wzFBzBjbKZByTOA3T90S5FKTWJ3l4FBfSsSVjT/4WXn4
4QF26ATy0iowAe4l/089mp7qzEKSLCmTQPhhcPz1gX9OZOpkgBBi7dm55R08OX5y
4W98nnSiPQXNVf5DRWmKuWmrJHY7xan2E1A19z+7R/mG3AxUKboNerl3mD+3vLmk
HAwZKo0bA297oOhZAY4TXnUNhwLazcGIgctETfuw63HMNvj7hbYAoJb7ghH1cpw9
6NNrVOMoz6A6JFFUYz3L0GPkP/lCukn637Zy9uixBtzss/QyFhICghy+LNnBABEB
AAG0L1RhaWxzIGRldmVsb3BlcnMgKHNpZ25pbmcga2V5KSA8dGFpbHNAYm91bS5v
cmc+iQI3BBMBCgAhBQJUNrtTAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ
EBICghy+LNnBz6YP+gLUXsvi+4IwNxTt/8yQWAwo5C7yVYq4t7X4Z9LTU/v4BQ2u
Ogs2E+E8Jd4u9bpTk9RWxg+wc3dm9BpsM3Mfsk23ryO6xqVS2/s+OiKMlK8C6QUT
shGw2Kd7FwbSUEHvzSO7f6oIpWs0HC/B1DNsIYCVMHj9xWHOF6osYkumVikVlYzJ
70dNlDNFvLiOR2kmneZ/8/q8NAcBLmPknE/m9iV9QBb4a8UIWhqbrUPoF5MKilCG
FgJW85pzWT9Q9SPlwvE7+UqrSBiRmG6EFKWFqGf4bPXZBaBsDHxBcc+UOGQDwHD7
3KfYV5arB6LdNPiF1eeJPscJxmIf6H9PNZ2DDU6BDmN6wK+L8V2fDo4TlLsWGOKH
rY8Ga6G0xuGWvIb5uL4nShMkF3E4PP3Z00mawx/cVQbrrH8UY4F51y9WKBRzdbw9
BuCzKBXxkymHVR3V01mEzBLVb80iBFBcOpyS/U66Dk6VsvtCF1g8JnxeRlg/UENp
+G6vdSUYKQdxQmY5Imlw64ote8/SHxAPlGnWBmT3eBsqaJpwV84zlBEncZS/WcCr
Gn+EzVr0MqRG8DvOfgqsBcgoxhUxldtqsOqTHBLjgwdOHIJnEv3nfEDus8PtMFZk
s3ixRFVikd0LSKV/F+02iEDLXQRIsha5Fb5BGodkr/IlaZhLYtqXaReLkKhQ
=PPAV
-----END PGP PUBLIC KEY BLOCK-----


More information about the Gnupg-devel mailing list