On Thu, May 02, 2019 at 07:13:51PM +0200, Werner Koch wrote:
On Wed, 1 May 2019 21:29, HeikoStamer(_at_)gmx(_dot_)net said:
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?
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.
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
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp