2

I want to mentally visualize or just understand a gpg-signature. When running

$ gpg2 --list-packets --verbose < test.sig

the output is

# off=0 ctb=89 tag=2 hlen=3 plen=540
:signature packet: algo 1, keyid C109A1FD84E2C2E5
    version 4, created 1510595093, md5len 0, sigclass 0x00
    digest algo 8, begin of digest cd 94
    hashed subpkt 2 len 4 (sig created 2017-11-13)
    subpkt 16 len 8 (issuer key ID C109A1FD84E2C2E5)
    data: 6198169E372BE3023D812F6E7AB24E600C326D77D6F8E690CDE45027F402F20325DEA9FEE9D2E32E04F798F5DB8700F734D65972C150DDF2B8ADD823D00190A5C9722E39C699D45D237343C741D991B78476270D5C5FBD996F032671BCA20890B0B994B4997A500D3AFC8B7446EAE3FF4F66A32DF8ED8E0B7741E4DD17B15D265D19C13D7349CC09E1094381C2BAE20375454A3825C842CC1E968428ABB451AA1B26555F081CE9D3C3A4F0222F86BAD0597A61B2B2FC4846FF400F52D3C58C7E29B2379E6022FBF0FC4C539421F4445EA7C905ABD98380D1218D82EB1ABCB9756B4A5F45AC668499E1405C72BEB5D2BF4F732EF0129B4EFE90C4F4308C4C6B6883A1A44A4A03C355A1D50F8E6172BCEC5F3A0D95696A1481F02D98D68A4CB52DD70E24C3535E2BCEE1DCD4D39DCFD0185DB06CE7BDE45DF5A723FB309819C79F27FBE602C26443D5E68F73911233E71C62D03099CCEF94431B37E17197E45475849938BDD6486E91204D17FE2E56C20F2B083FF44F6B1F63E747B73AAC9E21AFB2C15BD345D3F79AAA6F058D6D1288136727390879509928D874DEA5E285C6952F74137173AC2454FAAC06AEE90F94EC812E449C8E5F09F3419A8BE6981CBF9FB5D4E2DD6424AC316A7EDAB3AE98B9BD8979BB85E97328E882803C8AA522630C4E19B583682BA9F0575DDE642BA2BA3B7FECBCFFEF99C95B2D322B7FFDC30D2D

What is data here? [It's 4095 bits long. (My private key has this length, too.)]

Is data the actual signature (sha256-hash)?

0

2 Answers 2

3

You're looking at a version 4 signature packet.

From RFC 4880:

5.2.3.  Version 4 Signature Packet Format

   The body of a version 4 Signature packet contains:

     - One-octet version number (4).

     - One-octet signature type.

     - One-octet public-key algorithm.

     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket data.
       Note that this is the length in octets of all of the hashed
       subpackets; a pointer incremented by this number will skip over
       the hashed subpackets.

     - Hashed subpacket data set (zero or more subpackets).

     - Two-octet scalar octet count for the following unhashed subpacket
       data.  Note that this is the length in octets of all of the
       unhashed subpackets; a pointer incremented by this number will
       skip over the unhashed subpackets.

     - Unhashed subpacket data set (zero or more subpackets).

     - Two-octet field holding the left 16 bits of the signed hash
       value.

     - One or more multiprecision integers comprising the signature.
       This portion is algorithm specific, as described above.

Above it says:

   Algorithm-Specific Fields for RSA signatures:

     - multiprecision integer (MPI) of RSA signature value m**d mod n.

So what you're seeing is indeed the integer denoting the RSA signature (which naturally can't be larger than your key that is the RSA modulus).

4
  • Can you please also incorporate in your answer which algorithm is used for what? You can read my assumption on that in the comments of Luc's answer. Commented Nov 14, 2017 at 14:55
  • 1
    @user1511417 I gave that answer over to your post at crypto.
    – Arminius
    Commented Nov 14, 2017 at 14:59
  • 1
    @Arminius Ah dang, I misread that. I was skimming through it, saw something about some-precision integers, and just skipped it because ints typically aren't kilobytes. Now that I see your answer I'm kicking myself for how obvious it is :P
    – Luc
    Commented Nov 14, 2017 at 15:19
  • @Luc Heh, your entropy analysis was a great read though. :P
    – Arminius
    Commented Nov 14, 2017 at 15:20
1

I've read most of section "5.2. Signature Packet" of RFC 4880, the RFC which specifies the data format of PGP. I cannot cite anything that says "finally, the signature data is added" but all other things from your list-packets citation has been explained. Only the data part I can't find, and it doesn't seem to be mentioned where the signature data goes, so this is the only place where it makes sense.

The entropy of the data is very high, so it could be the output of an encryption algorithm. I computed this with the ent command (make sure to decode the hex first) and compared it with the entropy of 512 bytes of /dev/urandom data. It matches perfectly.

Algorithm 1, mentioned after "signature packet" on the second line, is RSA. I guess you would have to look into how RSA is used to generate signature data.

4
  • I could post this (concerning RSA) as another question here, for those who are interested in that aswell. Commented Nov 14, 2017 at 14:01
  • @user1511417 If you find the answer, you could just answer your own question here. I don't think a new question is needed. I'm also curious so if you find an answer, I'll upvote! ;)
    – Luc
    Commented Nov 14, 2017 at 14:13
  • Ah if algo 1 is RSA than this should be used for encrypting the hash and there is algo 8 in the console output, which should be the hashing algorithm. What is algo 8? Where can I look this up? Commented Nov 14, 2017 at 14:23
  • 1
    @user1511417 In the same RFC. There are sections that list the IDs for all hashing, encryption, etc. algorithms. If I remember correctly, it's SHA256.
    – Luc
    Commented Nov 14, 2017 at 14:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .