Looking at a GnuPG manual on openskills, I notice that the main key id
GEBV933F is in a different format than the usual hexadecimal (
G is no hexadecimal digit).
How is this done?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
tl;dr: these are made up key IDs of somebody trying to hide the actual information. They're not valid OpenPGP key IDs.
Following RFC 4880, OpenPGP, 3.3 Key IDs, a
Key ID is an eight-octet scalar that identifies a key.
12.2 Key IDs and Fingerprints further specifies the calculation, but again no representation of those lower 64 bits to be used. Often, 32 bit values ("short key IDs") are used in practice. An example describes pretty well how the key IDs are related:
fingerprint: 0D69 E11F 12BD BA07 7B37 26AB 4E1F 799A A4FF 2279 (160 bits) long id: 4E1F 799A A4FF 2279 (64 bits) short id: A4FF 2279 (32 bits)
GEBV933F form weird key IDs. They can't be hexadecimal, which wouldn't allow
G. They're probably using a digit range matching pretty much including all decimal digits plus letters up to X, which means eight digit numbers would allow to store about
ld(36^8) ~= 41 bits -- not enough for a more compact representation of (long) key IDs.
Well, you don't really need to dig deep. Let's assume the documentation was written by somebody using real keys, who at the same time tries to hide his identity and either has a bad understanding of key IDs, or wants to reveal manipulation of the key IDs to the skilled eye.
The quoted manual also provides examples of encoded signatures. Let's have a look at those! A string
This is some text. gets signed, probably using the author's key. And we also get the quoted result, which the author stored as
The signed version will look something like this:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is some text. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: 'Email me for my public key' iD8DBQE+ycRnF1uP4b67kz8RArZdAJ9e98RkcYICyJktEpah5/RoQX93vgCfUuOh 1I3aTPTGXitruRjhms3Kx7Y= =ju77 -----END PGP SIGNATURE-----
The output showing the weird key IDs actually verifies a signature of exactly this file:
[you@tiger]$ gpg --verify test.txt.asc gpg: Signature made Tue 20 May 2003 04:00:07 PM EST using DSA key ID GEBV933F gpg: Good signature from "email@example.com"
Now, what happens if we run this on our own?
gpg: Signature made Tue May 20 08:00:07 2003 CEST gpg: using DSA key BEBB933F gpg: Good signature from "[uid removed]" gpg: aka "[uid removed]" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 3318 D8EC 1EAD 3771 3B54 2893 175B 8FE1 BEBB 933F
I removed the user ID as the user might have tried to stay anonymous. I didn't care about his key ID/fingerprint, as he indeed posted it anyway and everybody can query the information if he wants.
Surprised about a close-match of the key IDs?
real key ID: BEBB933F claimed key ID: GEBV933F
Obviously, the two non-hexadecimal digits have been scrambled. Now, what about
$ gpg --list-keys BEBB933F pub 1024D/BEBB933F 2003-04-09 uid [uid removed] uid [uid removed] sub 1024g/CAC476E9 2003-04-09
A new subkey! Again comparing the keys:
real key ID: CAC476E9 claimed key ID: XAF476E9
Again, two digits differ.