No, the information comes from the certificate kept in your public-key ring (or downloaded from a keyserver). The signature only contains some information needed to find the right certificate.
Use gpg --list-packets
or pgpdump
:
$ echo Foo. > foo.txt
$ gpg --detach-sign foo.txt
$ gpg --list-packets < foo.txt.sig
:signature packet: algo 1, keyid D24F6CB2C1B52632
version 4, created 1410762670, md5len 0, sigclass 0x00
digest algo 10, begin of digest 25 58
hashed subpkt 2 len 4 (sig created 2014-09-15)
subpkt 16 len 8 (issuer key ID D24F6CB2C1B52632)
data: [4091 bits]
A detached signature has one "signature" packet, containing the algorithms, the signing timestamp, and the signer's 8-byte key ID, which is used to look up the signer's certificate in your keyring. (If you don't have any public keys with that keyid, GnuPG will attempt to find one in public keyservers.)
(I don't know why it has the key ID twice.)
GnuPG obtains everything about the signer by looking up the keyid – both the public key for actually verifying the signature, as well as the userid fields (name, address, photo) used to describe the signer.
Aside: Note that your example has a short 4-byte keyid, which is very bad as there have been a few hundred known short-keyid collisions, both intentional and accidental. Using keyid-format long
in your ~/.gnupg/gnupg.conf would make it display longer keyids, though those are still easy to collide intentionally, so you should always check the fingerprint when importing a new key.
(The signature packets, however, always keep a 8-byte keyid inside. Some people configure GnuPG to put the fingerprint in a custom field (notation), but that's unfortunately not used by the software itself.)
Back to signatures. If you did gpg --list-packets
on a regular (inline) signature, you'd see some more things:
:compressed packet: algo=1
:onepass_sig packet: keyid D24F6CB2C1B52632
version 3, sigclass 0x00, digest 10, pubkey 1, last=1
:literal data packet:
mode b (62), created 1410762587, name="",
raw data: 5 bytes
:signature packet: algo 1, keyid D24F6CB2C1B52632
version 4, created 1410762587, md5len 0, sigclass 0x00
digest algo 10, begin of digest eb 31
hashed subpkt 2 len 4 (sig created 2014-09-15)
subpkt 16 len 8 (issuer key ID D24F6CB2C1B52632)
data: [4095 bits]
The actual signed message is in the "literal data" packet, usually compressed using DEFLATE (pgpdump
would show the actual algorithm being used).
It's preceded by a "onepass_sig" packet, whose only purpose is to provide the keyid without having to read until end of the whole message – so GnuPG can start searching for the keyid and proceed with verifying the message at once. (When reading from a pipe, e.g. cat|gpg
, it is impossible to seek forwards and backwards; everything must be read in one pass.)
If you want, you can do this with the signer's key (certificate) as well. Just export it to a file first:
# gpg --export D24F6CB2C1B52632 | gpg --list-packets
:public key packet:
version 4, algo 1, created 1256993643, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: D24F6CB2C1B52632
:user ID packet: "Mantas Mikul\xc4\x97nas "
:signature packet: algo 1, keyid D24F6CB2C1B52632
version 4, created 1256993643, md5len 0, sigclass 0x13
digest algo 10, begin of digest 5a e2
[many more lines]
The certificates also consist ouf of packets, starting with a public key, userid's (text labels) with a self-signature for each (to protect against someone attaching fake userids to the pubkey), then several public subkey packets (again with self-signatures).