Re: [openpgp] Clarifiction on v5 signatures

[Werner Koch <[e-mail]>]

On Tue, 23 Oct 2018 12:46, [e-mail] said:

> by requirung that a v5 key must use a v5 signature.  That v5 signature
> now includes the meta data from the Literal Data packet.

I revisted the new scheme and changed it to make it easier to adapt by
existing implementations.  I also reworked the section on how to create
the the final trailer.  The new text reads:

--8<---------------cut here---------------start------------->8---
5.2.4.  Computing Signatures

   [...]
   Once the data body is hashed, then a trailer is hashed.  This trailer
   depends on the version of the signature.

   o  A V3 signature hashes five octets of the packet body, starting
      from the signature type field.  This data is the signature type,
      followed by the four-octet signature time.

   o  A V4 signature hashes the packet body starting from its first
      field, the version number, through the end of the hashed subpacket
      data and a final extra trailer.  Thus, the hashed fields are:

      *  the signature version (0x04),

      *  the signature type,

      *  the public-key algorithm,

      *  the hash algorithm,

      *  the hashed subpacket length,

      *  the hashed subpacket body,

      *  the two octets 0x04 and 0xFF,

      *  a four-octet big-endian number that is the length of the hashed
         data from the Signature packet stopping right before the 0x04,
         0xff octets.

      The four-octet big-endian number is considered to be an unsigned
      integer modulo 2^32.

   o  A V5 signature hashes the packet body starting from its first
      field, the version number, through the end of the hashed subpacket
      data and a final extra trailer.  Thus, the hashed fields are:

      *  the signature version (0x05),

      *  the signature type,

      *  the public-key algorithm,

      *  the hash algorithm,

      *  the hashed subpacket length,

      *  the hashed subpacket body,

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

         +  the one-octet content format,

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

         +  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.

      The three data items hashed for document signatures need to mirror
      the values of the Literal Data packet.  For detached signatures 6
      zero bytes are hashed instead.

   After all this has been hashed in a single hash context, the
   resulting hash field is used in the signature algorithm and placed at
   the end of the Signature packet.
--8<---------------cut here---------------end--------------->8---


A possible drawback of these new V5 signatures is that they make it
impossible to convert a detached signatures into a standard signature.
I am not aware of any actual attack due the possibility of converting
From detached to standard signature but it seems to be more safe to
inhibit this.  And well, to protect the file name etc also by the
signature.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.