It takes 4 seconds to generate a colliding 32bit key id on a GPU (using scallion). Key servers do little verification of uploaded keys and allow keys with colliding 32bit ids. Further, GPG uses 32bit key ids throughout its interface and does not warn you when an operation might apply to multiple keys.
Key servers do not use transport encryption (e.g. SSL) and GPG does not verify keys received when using
--recv-keys leaving communicaiton with key servers vulnerable to MITM (man in the middle) or DNS attacks. GPG assumes you have manually checked your keys with
In the example below, a key is requested with its 32bit key id. The key server has two keys with the specified key id and GPG imports both keys. It is easy to generate and publish a key that looks identical if you only use 32 bits when specifying a key.
free@turing ~$ gpg --keyserver pgp.mit.edu --recv-keys 10000001 gpg: requesting key 10000001 from hkp server pgp.mit.edu gpg: key 10000001: public key "John Doe" imported gpg: key 10000001: public key "Jane Doe" imported gpg: Total number processed: 2 gpg: imported: 2 (RSA: 2)
GPG simply imports whatever the key server sends. No verfication of the response is done before importing.
GPG assumes users will manually verify keys received with
--recv-keys. In the example below, a key is requested and GPG blindly imports a different key.
free@turing ~$ gpg --keyserver pgp.mit.edu --recv-keys 10000001 gpg: requesting key 10000001 from hkp server pgp.mit.edu gpg: key 0BADBEEF: public key "Evil32" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1)
The tool is called Scallion and the source can be found at https://github.com/lachesis/scallion.
Yes. You can download an 89MiB tar.gz file which contains all generated keys.
Someone downloaded our copy of the strong set and uploaded all of the keys to the SKS keyserver network. :( While we took on this project to help prompt GPG to build a more secure ecosystem, this mass clone made the keyservers harder for everyone to use. Of course anyone could use our tools to regenerate their own strong set clone and do this again, but we'd rather our keys not be used that way.
Key exchange is hard and there are no perfect solutions. That being said, there are some changes that could be made to GPG to make things better.
--recv-keys GPG should verify that the key/keys returned by the key server actually have the key id or fingerprint you requested.
Absolutely! The web of trust is a great mechanism by which to verify keys but it's complicated. As a result, it is often not used. There are examples of GPG being used without the Web of Trust all over the web.
The Warning: "no ultimately trusted keys found" means that gpg was not configured to ultimately trust a specific key. Trust settings are part of OpenPGPs Web-of-Trust which does not apply here. - Debian SecureApt Wiki
That depends. Many tools use GPG behind-the-scenes and have the same problems, but never directly show you fingerprints or prompt you. Check that maintainers of software you use are aware of these problems as well.
GPG key: download here
GPG key: download here