Examples

32bit key ids are not secure

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 does not verify received keys

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)

Q&A

Where is the source code for the tool you used to duplicate the strong set?

The tool is called Scallion and the source can be found at https://github.com/lachesis/scallion.

Is your clone of the strong set publicly available?

Yes. You can download an 89MiB tar.gz file which contains all generated keys.

I saw that your clone of the strong set is revoked?

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.

How could GPG be fixed?

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.

When it's ambiguous what key an operation should act on (because of key id collisions or uuid collisions) GPG should refuse to perform the operation automatically. This would fix the issue of receiving keys.

If you specify a key id or fingerprint when using --recv-keys GPG should verify that the key/keys returned by the key server actually have the key id or fingerprint you requested.

Aren't you suppose to use the Web of Trust to verify the authenticity of keys?

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

I know about the problems with 32bit key ids, am I safe now?

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.

Who should I contact with questions?

If you have questions related to this page or scallion you should email scallion@aftbit.com

Who authored this page?

Richard Klafter

Email:

GPG fingerprint: CB7C8A7B567FB2C2ACC2873B04FAC2E9CC21424A

GPG key: download here

Eric Swanson

Email:

GPG fingerprint: 9E15397E4D537E3A3A238F87E620C8A74BAF5D09

GPG key: download here

