[openpgp] Pull request for 8-octet lengths

[brian m. carlson]

There was some question as to whether we should use four-octet or
eight-octet lengths for signatures (or some other technique), as one
might want to sign more the 2^32 bytes of data. I've submitted a pull
request[0] to use eight-octet lengths for all signatures.

I don't think the overhead of hashing an additional four bytes for short
signatures will matter, and I feel that simply overflowing the existing
four-byte counter could potentially collision issues down the line.

Other opinions are welcomed.

[0] https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/1

[brian m. carlson]

---
middle.mkd | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/middle.mkd b/middle.mkd
index 5182c7d..96be061 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -1654,7 +1654,7 @@ first the primary key and then the subkey being revoked.
A certification signature (type 0x10 through 0x13) hashes the User ID
being bound to the key into the hash context after the above data. A
V3 certification hashes the contents of the User ID or attribute
-packet packet, without any header. A V4 certification hashes the
+packet packet, without any header. A V4 or V5 certification hashes the
constant 0xB4 for User ID certifications or the constant 0xD1 for User
Attribute certifications, followed by a four-octet number giving the
length of the User ID or User Attribute data, and then the User ID or
@@ -1671,7 +1671,7 @@ unhashed subpacket data length value is set to zero.
Once the data body is hashed, then a trailer is hashed. 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. A V4 signature hashes the packet body
+four-octet signature time. A V4 or V5 signature hashes the packet body
starting from its first field, the version number, through the end of
the hashed subpacket data. Thus, the fields hashed are the signature
version, the signature type, the public-key algorithm, the hash
@@ -1683,6 +1683,11 @@ big-endian number that is the length of the hashed data from the
Signature packet (note that this number does not include these final
six octets).

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

[Werner Koch]

Hi Brian,

thanks for posting the text.

Post by brian m. carlson
There was some question as to whether we should use four-octet or
eight-octet lengths for signatures (or some other technique), as one
might want to sign more the 2^32 bytes of data. I've submitted a pull
request[0] to use eight-octet lengths for all signatures.

Although 64 bit numbers are often not easy to handle on small systems it
will be easy for such implementations to hash the required extra bytes
(thanks to Big Endian).

This is an easy and straightforward change. Unless someone objects, I
will add this to the next draft.


Salam-Shalom,

Werner

[Derek Atkins]

Post by Werner Koch
Hi Brian,
thanks for posting the text.

Post by brian m. carlson
There was some question as to whether we should use four-octet or
eight-octet lengths for signatures (or some other technique), as one
might want to sign more the 2^32 bytes of data. I've submitted a pull
request[0] to use eight-octet lengths for all signatures.

Although 64 bit numbers are often not easy to handle on small systems it
will be easy for such implementations to hash the required extra bytes
(thanks to Big Endian).
This is an easy and straightforward change. Unless someone objects, I
will add this to the next draft.

As long as we don't deprecate V4 Signatures I'm fine with this change.

Post by Werner Koch
Salam-Shalom,
Werner

-derek