4

What information does a gpg2 signature contain?

If you clearsign an empty file, the signature looks like this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

jQIcBAEBCAAGBJaPoTMAoJEMEJof2E4sLl4hgP/355iZSmAWcgF8ADUMcL85Wa
...
KyugtYr0DewOPPA83kd7BCBpi1Cen9ltAJfK47RVsPPKqlxn+yNUt+YOBpYdNC
mKhDc/j156f4S1vxB/LI
=wkGU
-----END PGP SIGNATURE-----

For example with S/MIME, you would

$openssl enc -base64 -d < signature > signature.dec

and

$der2ascii -i signature.dec

which would print out more information. How can you do something equivalent with gpg-signatures?

1
  • Did you try gpg --list-packets on the signature? – RubberStamp Dec 23 '17 at 18:46
4

Here's an example.

Create a key:

gpg --full-gen-key
...
pub   rsa3072 2017-12-23 [SC]
      9727B646039D8D463EE2394531EA459B1AA5A792
uid                      tester (Delete Me) <tester@tester>
sub   rsa3072 2017-12-23 [E]

Create an empty file:

touch empty

Create a detached signature:

gpg --detach-sign --default-key 9727B646039D8D463EE2394531EA459B1AA5A792 empty
gpg: using "9727B646039D8D463EE2394531EA459B1AA5A792" as default secret key for signing

Examine signature:

gpg --list-packets empty.sig
# off=0 ctb=89 tag=2 hlen=3 plen=435
:signature packet: algo 1, keyid 31EA459B1AA5A792
    version 4, created 1514055133, md5len 0, sigclass 0x00  digest algo 10, begin of digest 05 74
hashed subpkt 33 len 21 (issuer fpr v4 9727B646039D8D463EE2394531EA459B1AA5A792)
hashed subpkt 2 len 4 (sig created 2017-12-23)
subpkt 16 len 8 (issuer key ID 31EA459B1AA5A792)
data: [3072 bits]

UPDATE:

Where is the message digest?

As can be seen from the output of --list-packets the message digest, in my example, is algorithm 10 and begins with the hexidecimal byte pattern of 05 74. According to RFC4880 Section 9.4, algorithm 10 is SHA-512.

For this part, we'll need to look at the hexidecimal representation of the signature packet:

00000000:  89 01 b3 04 00 01 0a 00  1d 16 21 04 97 27 b6 46  ..........!..'.F
00000010:  03 9d 8d 46 3e e2 39 45  31 ea 45 9b 1a a5 a7 92  ...F>.9E1.E.....
00000020:  05 02 5a 3e a5 dd 00 0a  09 10 31 ea 45 9b 1a a5  ..Z>......1.E...
*00000030:  a7 92 05 74 0c 00 a7 b5  50 c7 26 98 b9 48 7c df  ...t....P.&..H|.*
00000040:  68 e4 8e 4f 07 82 5a 5f  78 a1 c6 30 93 05 9b dd  h..O..Z_x..0....
00000050:  aa 36 ec 89 72 20 4f 06  75 6e 1b 89 ff 2c 2b d5  .6..r O.un...,+.
00000060:  1a af 73 82 a6 e0 85 50  be 59 8a 05 13 d7 ca 2c  ..s....P.Y.....,
00000070:  cd 61 f0 f1 52 c5 47 c2  f9 f0 cd 69 a9 8c 54 8e  .a..R.G....i..T.
00000080:  79 a6 82 b2 1b 15 c0 cf  96 0a c7 88 a9 6e 54 31  y............nT1
00000090:  3d e0 96 62 14 94 6e aa  6b 7d c4 9c 4b c1 14 c8  =..b..n.k}..K...
000000a0:  bb ce ce 22 44 9c 3b df  64 cd ad f5 71 80 e0 d0  ..."D.;.d...q...
000000b0:  63 71 00 df 74 8e cd 82  bc 94 46 26 42 97 85 af  cq..t.....F&B...
000000c0:  84 ea e7 e7 39 2d 45 70  f0 8e 42 65 a2 57 2b ca  ....9-Ep..Be.W+.
000000d0:  75 95 e1 7e cd 2d ab c0  a5 7f 7a 8a e1 e7 7a 65  u..~.-....z...ze
000000e0:  d2 b1 83 46 e0 0a b3 ac  83 66 f9 45 2a a5 b0 7c  ...F.....f.E*..|
000000f0:  8a 64 d7 28 30 68 ee 2f  8f 3a 1c 1e b9 09 ca 92  .d.(0h./.:......
00000100:  27 85 6e 11 da 0a a0 1d  99 b5 e5 04 66 cf 2d 0b  '.n.........f.-.
00000110:  22 57 5d ab 56 70 75 28  81 06 a9 ba 06 92 8d 89  "W].Vpu(........
00000120:  f3 fa 3f 11 45 9e 9c 58  28 a2 6d 54 45 86 a8 19  ..?.E..X(.mTE...
00000130:  5d b4 b3 50 ee c0 ca d3  16 8c 45 be 9d fa b2 40  ]..P......E....@
00000140:  dc c2 1e 0d c1 a8 48 e5  80 61 d8 b9 b6 54 96 78  ......H..a...T.x
00000150:  6b 60 83 ed 63 20 64 6c  ee eb 33 b1 ee fd f1 34  k`..c dl..3....4
00000160:  ab c8 c7 46 1b 20 c8 1e  b6 70 2a c2 2c b4 4c c4  ...F. ...p*.,.L.
00000170:  5d 58 a3 16 e2 73 19 c1  35 6c da 4f dc 67 fa 25  ]X...s..5l.O.g.%
00000180:  1a 99 31 6a 69 21 c5 ca  f1 d7 24 d7 d1 51 ff bb  ..1ji!....$..Q..
00000190:  34 fe a8 b9 fd 2c 4a 68  26 44 cb df 8f 61 7a 24  4....,Jh&D...az$
000001a0:  13 4f 63 26 c5 41 6a 19  7b 9b 24 3d 5a 5c fd 62  .Oc&.Aj.{.$=Z\.b
000001b0:  7a 39 37 1f 5f bd -- --  -- -- -- -- -- -- -- --  z97._.----------

You can see that this byte pattern occurs on the highlighted line. Since the hash type is known to be SHA-512, the length must be 64 bytes. So, in my example, the message digest is:

05740c00a7b550c72698b9487cdf68e48e4f07825a5f78a1c63093059bddaa36ec8972204f06756e1b89ff2c2bd51aaf7382a6e08550be598a0513d7ca2ccd61

It's important to note that a PGP signature message hash is not only a hash of the signed file or text. There are several variables including the time of signature which are hashed together. So, the hash of the file or text is not retrievable from the signature.

It's easy to demonstrate that the message hash changes.... simply create two signatures separated by a few moments in time.

$gpg --list-packets empty1.sig
# off=0 ctb=89 tag=2 hlen=3 plen=435
:signature packet: algo 1, keyid 31EA459B1AA5A792
    version 4, created 1514138633, md5len 0, sigclass 0x00
        digest algo 10, begin of digest b3 66
    hashed subpkt 33 len 21 (issuer fpr v4 9727B646039D8D463EE2394531EA459B1AA5A792)
    hashed subpkt 2 len 4 (sig created 2017-12-24)
    subpkt 16 len 8 (issuer key ID 31EA459B1AA5A792)
    data: [3070 bits]

$ gpg --list-packets empty2.sig
# off=0 ctb=89 tag=2 hlen=3 plen=435
:signature packet: algo 1, keyid 31EA459B1AA5A792
    version 4, created 1514138639, md5len 0, sigclass 0x00
    digest algo 10, begin of digest 04 0c
    hashed subpkt 33 len 21 (issuer fpr v4 9727B646039D8D463EE2394531EA459B1AA5A792)
    hashed subpkt 2 len 4 (sig created 2017-12-24)
    subpkt 16 len 8 (issuer key ID 31EA459B1AA5A792)
    data: [3069 bits]

You can clearly see that the message hash has changed, since the two beginning bytes have changed. So, even though the signed document is the same and the keys are the same, the signatures are not identical.

5
  • But (most important,) where is the digest of the message? – user1511417 Dec 24 '17 at 5:15
  • But $ openssl dgst -sha512 empty returns cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e – user1511417 Dec 24 '17 at 17:19
  • @user1511417: That's because the message contained in the signature is not the hash of the input file... it's a hash of multiple variables including the time of signature. Therefore, the hash of the file itself is not retrievable. – RubberStamp Dec 24 '17 at 18:04
  • What else is in the signature? There must be more information in 3096 bits of data. How can I visualize this? – user1511417 Dec 28 '17 at 23:08
  • @user1511417 : The best way to get a visceral visualization is by reviewing the source code for gpg ... I can update the answer with a brief review to show the basics of a signature. The general idea is that there are subpackets and each one gets hashed and then all the hashes are put together in a bigger packet... The signature is over all subpackets. It should be fairly easy to see that the things that are unique to signature must be included in plaintext so that the signature can be verified. So, the time is included, the key fingerprint, the input file is known, etc... – RubberStamp Dec 29 '17 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.