Subject: [openpgp] Question on computing v5 signatures

From: Heiko Stamer <[email-masked]>
Date: Wed, 1 May 2019 21:29:09 +0200

Dear friends of OpenPGP,

regarding compution of v5 signatures we have the following lines
in section 5.2.4 of the current draft RFC 4880bis-06:

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

I am wondering why a number of eight-octet size is used here. The
biggest field, AFAIS i.e. the hashed subpacket data area, is limited
by the included two-octet hashed subpacket length. So why 64 bit?

--
Heiko

---

From: "Neal H. Walfield" <[email-masked]>
Date: Thu, 02 May 2019 08:35:42 +0200

Hi Heiko,

On Wed, 01 May 2019 21:29:09 +0200,
Heiko Stamer wrote:
> biggest field

I don't know about this.

> , AFAIS i.e. the hashed subpacket data area, is limited

Actually, the MPIs can be larger.  They take up the remainder of the
packet.  In practice, the MPIs are just a few kilobytes today, but
with post-quantum crypto, they could get very large.

:) Neal

---

From: Heiko Stamer <[email-masked]>
Date: Thu, 2 May 2019 18:34:58 +0200

Hi Neal,

> with post-quantum crypto, they could get very large.

However, according to the current description these fields are not
included in the computation of the hash and thus large MPIs (except
those included e.g. by Embedded Signature subpackets in the hashed
subpacket area) should not increase this specific 64-bit counter.
Where I am wrong?

--
Heiko

---

From: Werner Koch <[email-masked]>
Date: Thu, 02 May 2019 19:13:51 +0200

Hello!

> by the included two-octet hashed subpacket length. So why 64 bit?

That seems to be a misunderstanding.  The original patch from Brian
(9b846b7e from 2017-02-13) had this text:

  V5 signatures instead hash in a ten-octet trailer: the version of the
  Signature packet, i.e., 0x05; 0xFF; and an eight-octet, big-endian
  number that is the length of the hashed data from the Signature packet
  (note that this number does not include these final ten octets).

He might have extended the counter to eight octets to better distinguish
a V5 signature form a V4 signature.  Reading this I falsely concluded
that the 32 bit counter of a V4 signature might overflow and thus added

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

to the V4 signature desciption.  Obviously we both missed that a 32 bit
counter is sufficient for a a max of 2*2^16+something octets.

Shalom-Salam,

   Werner

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

---

From: "brian m. carlson" <[email-masked]>
Date: Thu, 2 May 2019 23:52:19 +0000

> counter is sufficient for a a max of 2*2^16+something octets.

Yes, I think I overlooked that. The goal was to avoid using a four-octet
length for the length of the actual data in a binary or text document
signature, but I misread and didn't realize that this is the length of
the signature packet, not the length of the data to be signed.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204