[openpgp] Re: Review of draft-ietf-openpgp-replacementkey-04

Heiko Schäfer <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <[email protected]>
Hello Andrew, all,

On 8/7/25 1:46 AM, Andrew Gallagher wrote:
>> Why is the subfield "Record Length" field two octets?  a v6 fingerprint
>> is 32 octets long, and the imprint is the length of the signature's
>> digest.  The longest OpenPGP digest algorithms (SHA512 and SHA3-512) are
>> 64 octets long.  Even if we have some new key version with a 512-bit (64
>> octet) fingerprint,*and* the largest possible sig digest, we're still
>> only at 1+64+64=129 octets for the field.  The first octet will always
>> be zero.  why not make it one octet?
> I’ll admit this is a cautious design decsion. Yes, as far as we can tell now it seems unlikely that a digest algorithm of more than 512 bits will be necessary in the foreseeable future. But if it were, we could conceivably exceed the capacity of a single octet. Given the overall size of the target record, one spare octet is not that significant.

I'm leaning towards preferring a one byte length here.

To my understanding, it is currently considered unlikely that there will 
ever be a need for hash functions with digests larger than 512 bits.
Even 512 bit hashes are, as I understand it, already a design that 
embodies an excess of caution.

While defensive designs are attractive to me, having a two byte length 
here feels like overkill (that I expect would mostly seem baffling and 
odd to implementers).

But then, I'm not a domain expect. I'd be happy to defer to expert 
opinion that favors two byte lengths.

Thanks,
Heiko

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.