Page MenuHome GnuPG

v5 document signatures verification.
Closed, ResolvedPublic

Description

Section 5.2.4 of draft-koch claims, that for v5 signatures:

-  Only for document signatures (type 0x00 or 0x01) the following
   three data items are hashed here:

   o  the one-octet content format,

   o  the file name as a string (one octet length, followed by the
      file name),

   o  a four-octet number that indicates a date,

-  the two octets 0x05 and 0xFF,

-  a eight-octet big-endian number that is the length of the
   hashed data from the Signature packet **stopping right before the
   0x05, 0xff octets**.
  • First impression was that length of the hashed data should include literal packet info, but investigating GnuPG sources it appears that it doesn't. Is this correct?
  • For the cleartext signed data, GnuPG hashes char 't' + 5 zeroes, however draft tells "For detached and cleartext signatures 6 zero bytes are hashed instead.". Is this a GnuPG issue?

Details

Version
2.4.0

Event Timeline

Regading your first point: From gnupg (2.4) sign.c:hash_sigversion_to_magic

/* Hash data from the literal data packet.  */
if (sig->version >= 5 && (sig->sig_class == 0x00 || sig->sig_class == 0x01))
  {
    /* - One octet content format
     * - File name (one octet length followed by the name)
     * - Four octet timestamp */
    if (extrahash)
      {
        buf[0] = extrahash->mode;
        buf[1] = extrahash->namelen;
        gcry_md_write (md, buf, 2);
        if (extrahash->namelen)
          gcry_md_write (md, extrahash->name, extrahash->namelen);
        buf[0] = extrahash->timestamp >> 24;
        buf[1] = extrahash->timestamp >> 16;
        buf[2] = extrahash->timestamp >>  8;
        buf[3] = extrahash->timestamp;
        gcry_md_write (md, buf, 4);
 [...]

/* Add some magic aka known as postscript.  The idea was to make it
 * impossible to make up a document with a v3 signature and then
 * turn this into a v4 signature for another document.  The last
 * hashed 5 bytes of a v4 signature should never look like a the
 * last 5 bytes of a v3 signature.  The length can be used to parse
 * from the end. */

So it implements the above description. The code is from early 2019.

For the second point (cearsign) the length of the filename is zero and thus we write 't', 0x00, 4*0x00. This is the mode 't' for clearsign, file name length of zero and z ero timestamp of the file. This seems to be correct. The description the specs is not correct. For a detached signature we indeed write 6*0x00 (mode, length, 4 byte timestamp) but for a cleartext signature the first byte will be a 't'. I'll fix the description.

The patch to the specs would be this:

        The three data items hashed for document signatures need to
-       mirror the values of the Literal Data packet.  For detached
-       and cleartext signatures 6 zero bytes are hashed instead.
+       mirror the values of the Literal Data packet.  Note that for a
+       detached signatures this means to hash 6 0x00 octets and for a
+       cleartext signature this means to hash a 't' followed by 5 0x00
+       octets.

Okay, will go into the next revision. Thanks.

werner claimed this task.