Evil 32: Check Your GPG Fingerprints(evil32.com)
evil32.com
Evil 32: Check Your GPG Fingerprints
https://evil32.com/
6 comments
Here's a pretty comprehensive guide:
https://help.riseup.net/en/gpg-best-practices
https://help.riseup.net/en/gpg-best-practices
I love gpg but openpgp tooling is just ancient piece of crap from CLI perspective.
- writing gpg just gives you cryptic “gpg: Go ahead and type your message ...” without any more information.
- `gpg --list-keys` apart from being hard to remember* has a table of misaligned values without any headers.
- I still can’t figure out how to make use of gpg-agent.
* I always tend to write --keys and I get another non-helpful info error “gpg: Option “--keys” is ambiguous”)
- writing gpg just gives you cryptic “gpg: Go ahead and type your message ...” without any more information.
- `gpg --list-keys` apart from being hard to remember* has a table of misaligned values without any headers.
- I still can’t figure out how to make use of gpg-agent.
* I always tend to write --keys and I get another non-helpful info error “gpg: Option “--keys” is ambiguous”)
See also: Trolling the Web of Trust[1]
The slides from Micah's original OHM2013 presentation are in trollwot.pdf
0xdeadbeef keys[2] have been around for quite a while, too. Generating a custom 32-bit key ID using a simple unoptimized brute force program takes under an hour on a midrange PC.
[1] https://github.com/micahflee/trollwot
[2] http://pgp.mit.edu/pks/lookup?search=0xdeadbeef&op=index
The slides from Micah's original OHM2013 presentation are in trollwot.pdf
0xdeadbeef keys[2] have been around for quite a while, too. Generating a custom 32-bit key ID using a simple unoptimized brute force program takes under an hour on a midrange PC.
[1] https://github.com/micahflee/trollwot
[2] http://pgp.mit.edu/pks/lookup?search=0xdeadbeef&op=index
Interesting, this article from 2011 shows the Debian community moving from short 8 char IDs to 16 chararters one.
Now I'm really confused, and I have to ask:
Why are we calling a 8 hexadecimal character word 32 bit when it reuqires 64 bit to encode, or a 16 hexadecimal character word 64 bit when it take 256 bit to encode?
Now I'm really confused, and I have to ask:
Why are we calling a 8 hexadecimal character word 32 bit when it reuqires 64 bit to encode, or a 16 hexadecimal character word 64 bit when it take 256 bit to encode?
Because while 8 characters of hexadecimal stored directly as themselves as individual bytes occupy 8 bytes, each pair of hexadecimal characters only encodes up to 1 byte of binary information.
00 -> FF only covers 0-255, which is the range of binary values representable in 1 byte.
The bit length they're talking about isn't about how many characters are in the human readable IDs (hex) but instead the technical range limit of the ID numbers.
00 -> FF only covers 0-255, which is the range of binary values representable in 1 byte.
The bit length they're talking about isn't about how many characters are in the human readable IDs (hex) but instead the technical range limit of the ID numbers.
So how do I know if my key ID is 32 bit?
It's not a property of the key itself, it's about how we communicate about keys.
For example, consider the key of Ryan Lackey, who posts here on HN. Some people (and software) might refer to that key as D2E0301F, which is its 32-bit key ID. A more secure way to refer to the same key is
B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F
which is called the fingerprint of the key. Both of these forms exist for every PGP key. Notice that the 32-bit key ID is the rightmost 32 bits of the fingerprint (D2E0 301F → D2E0301F. The problem with this is that it is easy (according to the linked article, now takes only four seconds) to make some other key that will also have 32-bit key ID D2E0301F, so if you tried to find or verify Ryan's key using only that ID, someone could trick you into using a fake one.
Another form sometimes used today is the 64-bit key ID, which is the rightmost 64 bits of the fingerprint (in Ryan's case, 07AD BE07 D2E0 301F → 07ADBE07D2E0301F).
Key IDs and key fingerprints have always both been part of PGP, but the idea was that you might use the key ID to download or talk about the key, and then use the fingerprint to verify that you had the right one. Some people have been skipping the second step, or might not even know it was ever there.
For example, consider the key of Ryan Lackey, who posts here on HN. Some people (and software) might refer to that key as D2E0301F, which is its 32-bit key ID. A more secure way to refer to the same key is
B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F
which is called the fingerprint of the key. Both of these forms exist for every PGP key. Notice that the 32-bit key ID is the rightmost 32 bits of the fingerprint (D2E0 301F → D2E0301F. The problem with this is that it is easy (according to the linked article, now takes only four seconds) to make some other key that will also have 32-bit key ID D2E0301F, so if you tried to find or verify Ryan's key using only that ID, someone could trick you into using a fake one.
Another form sometimes used today is the 64-bit key ID, which is the rightmost 64 bits of the fingerprint (in Ryan's case, 07AD BE07 D2E0 301F → 07ADBE07D2E0301F).
Key IDs and key fingerprints have always both been part of PGP, but the idea was that you might use the key ID to download or talk about the key, and then use the fingerprint to verify that you had the right one. Some people have been skipping the second step, or might not even know it was ever there.
By its length, obviously. If something it 8 hex digits, it's 32-bit.
Key IDs are just a part of the fingerprint, last 8 hex digits of the full 160-bit one. That is, the 32-bit ID is "2A8E4C02" while the full hash is "67819B343B2AB70DED9320872C6464AF2A8E4C02". The problem is, as article shows, finding another SHA-1 hash that ends with the same digits is relatively easy.
Fortunately, as I've heard, there are no known (at least, no publicly known) second preimage attacks on SHA-1, so comparing whole hashes should be fine for a time being. But as I'M NOT A CRYPTOGRAPHER, please consult a cryptographer on this and take my words with a grain of salt.
Key IDs are just a part of the fingerprint, last 8 hex digits of the full 160-bit one. That is, the 32-bit ID is "2A8E4C02" while the full hash is "67819B343B2AB70DED9320872C6464AF2A8E4C02". The problem is, as article shows, finding another SHA-1 hash that ends with the same digits is relatively easy.
Fortunately, as I've heard, there are no known (at least, no publicly known) second preimage attacks on SHA-1, so comparing whole hashes should be fine for a time being. But as I'M NOT A CRYPTOGRAPHER, please consult a cryptographer on this and take my words with a grain of salt.
However, some of its information about GnuPG is out of date. As of version 1.4.17 (released in June), GnuPG no longer blindly accepts responses from key servers:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit...
http://bugs.g10code.com/gnupg/issue1579
The fix was backported to wheezy-security as well:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725411