GnuPG : representations of key IDs and fingerprints

encryptiongpg

In gpg's man page, there are examples of key IDs :

234567C4
0F34E556E
01347A56A
0xAB123456

234AABBCC34567C4
0F323456784E56EAB
01AB3FED1347A5612
0x234AABBCC34567C4

and fingerprints :

1234343434343434C434343434343434
123434343434343C3434343434343734349A3434
0E12343434343434343434EAB3484343434343434
0xE12343434343434343434EAB3484343434343434

My intuition would have been that a leading 0 is for octal and a leading 0x for hexadecimal, but it does not seem like it is.

What are the different representations?

Best Answer

NOTE: Before I begin, all the representations here are hexidecimal only. There isn't any other representation.

Key IDs

The man page seems pretty clear on where these values are coming from. The key IDs are a portion of the SHA-1 fingerprint.

The key Id of an X.509 certificate are the low 64 bits of its SHA-1 fingerprint. The use of key Ids is just a shortcut, for all automated processing the fingerprint should be used.

All these values are hex, the notation allows for either a number to be prefixed with 0x, a 0, or to simply begin with a non-zero value.

NOTE: Using key IDs is inherently a bad idea since they're essentially taking a portion of the fingerprint to identify a given key. The problem arises in that it's somewhat trivial to generate collisions among key IDs. See this article for more on this issue, titled: Short key IDs are bad news (with OpenPGP and GNU Privacy Guard).

excerpt

Summary: It is important that we (the Debian community that relies on OpenPGP through GNU Privacy Guard) stop using short key IDs. There is no vulnerability in OpenPGP and GPG. However, using short key IDs (like 0x70096AD1) is fundementally insecure; it is easy to generate collisions for short key IDs. We should always use 64-bit (or longer) key IDs, like: 0x37E1C17570096AD1 or 0xEC4B033C70096AD1.

TL;DR: This now gives two results: gpg --recv-key 70096AD1

Fingerprints

Whereas the fingerprints:

This format is deduced from the length of the string and its content or the 0x prefix. Note, that only the 20 byte version fingerprint is available with gpgsm (i.e. the SHA-1 hash of the certificate).

When using gpg an exclamation mark (!) may be appended to force using the specified primary or secondary key and not to try and calculate which primary or secondary key to use.

The best way to specify a key Id is by using the fingerprint. This avoids any ambiguities in case that there are duplicated key IDs.

I'd suggest taking a look at the wikipedia page titled: Public key fingerprint. It details how fingerprints are generated. Here's summary:

excerpt

A public key (and optionally some additional data) is encoded into a sequence of bytes. To ensure that the same fingerprint can be recreated later, the encoding must be deterministic, and any additional data must be exchanged and stored alongside the public key. The additional data is typically information which anyone using the public key should be aware of. Examples of additional data include: which protocol versions the key should be used with (in the case of PGP fingerprints); and the name of the key holder (in the case of X.509 trust anchor fingerprints, where the additional data consists of an X.509 self-signed certificate).

The data produced in the previous step is hashed with a cryptographic hash function such as MD5 or SHA-1.

If desired, the hash function output can be truncated to provide a shorter, more convenient fingerprint.

This process produces a short fingerprint which can be used to authenticate a much larger public key. For example, whereas a typical RSA public key will be 1024 bits in length or longer, typical MD5 or SHA-1 fingerprints are only 128 or 160 bits in length.

When displayed for human inspection, fingerprints are usually encoded into hexadecimal strings. These strings are then formatted into groups of characters for readability. For example, a 128-bit MD5 fingerprint for SSH would be displayed as follows:
   43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8

References

Fingerprint (computing)

Related Solutions

Security – Encrypt Files Using GPG and Symmetric Key Encryption in Unix

You can use GPG to symmetrically encrypt a file with a passphrase (gpg -c). If the passphrase has enough entropy, you don't need an extra step of generating a secret key. What does “enough entropy” mean? Your encryption needs to withstand offline attacks, where the attacker can make cracking attempts as fast as his hardware allows it. With a small PC farm, the attacker might be able to make a couple hundred billion attempts per second, which is roughly 2^69 per decade. So with an entropy of 2^70 you'll be safe. That means if your passphrase consists of completely random letters (lower or upper case) and digits, it should be 12 characters long.

Now to store that passphrase, you can use GPG with its usual key pairs. Use gpg --gen-key to generate a key pair, and gpg -e to encrypt the passphrase used to encrypt the large file for one or more key pairs.

Here's a sketch on how to do the encryption (note that I avoid putting the passphrase on the command line or in the environment, so as to make sure another user can't find it by looking at the ps output while the command is running):

passphrase=$(pwgen -s 12 -1)
echo "The passphrase for myiso.iso.gpg is: $passphrase" |
gpg -e -r somebody -r somebodyelse >passphrase.gpg
echo "$passphrase" | gpg -c --passphrase-fd 3 3<&0 <myiso.iso >myiso.iso.gpg

and how to decrypt:

passphrase=$(gpg -d <passphrase.gpg)
echo "$passphrase" | gpg -d --passphrase-fd 3 3<&0 <myiso.iso.gpg >myiso.iso

The reason to use a passphrase (a shared secret) rather than directly encrypt is that it allows the file to be shared between several people. Only the small passphrase needs to be reencrypted if you want to add a recipient (removing a recipient only makes sense if you know the recipient hasn't had access to the plaintext and requires reencoding the ciphertext anyway).

How to check openpgp (gpg) signature against a set of public key blocks

The program gpgv / gpgv2 is used for simple checking of signatures. The problem is that exported key files are not recognized as keyring. Thus you have to create a keyring in the first step:

cd /some/tmp/dir || exit 1
test -f pubring.gpg && { rm -f pubring.gpg || exit 1; }
gpg --no-options --no-default-keyring --keyring ./pubring.gpg \
  --secret-keyring ./secring.gpg --import /etc/ourapp/ourapps_trusted_pubkeys.asc

Now /some/tmp/dir/pubring.gpg is a keyring file gpgv can use:

gpgv --keyring /some/tmp/dir/pubring.gpg \
  /var/lib/ourapp/newcontent.tar.gz.asc /var/lib/ourapp/newcontent.tar.gz

If the data file path is the signature path without .asc (like in your example) then you can leave it out.