[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]