Fingerprint algorithm and SHA-1 usage [was: Re: SHA3 IANA registration - method?]

Andrey Jivsov openpgp at
Mon Dec 17 23:16:21 CET 2012

On 12/15/2012 06:03 AM, Christian Aistleitner wrote:
> Hi Andrey,
> On Fri, Dec 14, 2012 at 05:32:16PM -0800, Andrey Jivsov wrote:
>> The OpenPGP ecosystem uses fingerprints as a
>> shortcut for keys quite extensively.
> for whatever "OpenPGP ecosystem" means to you :-)
> IIRC, in RFC 4880 the fingerprint is used as "a shortcut for keys"
> only once [1] -- and the corresponding subpacket is not even
> mandatory.
> I would not call that "quite extensively".
> Part of the SHA-1 fingerprint also makes up the key id. But that can
> even less be expected to be unique. And it's useful only as sieve for
> keys (to limit the keys you have to check) than a unique handle to a
> key.
> So for whatever software or practice [2] you employ that mistakes
> fingerprints for unique key identifiers, fix that software or
> practice -- it's not the flaw of RFC 4880.
> Indeed SHA-1 /fingerprints/ are not a problem. As they are effectively
> not used in RFC 4880, it's up to us—the users and software
> developers—if we use them or what we use them for. We can switch at
> will [3].
> The problem is rather SHA-1 than fingerprints. And OpenPGP also uses
> SHA-1 for other things than fingerprints as well. RFC 4880 forces
> SHA-1 usage also in
> * § 5.5.3 Secret-Key Packet Formats (usage 254)
> * § 5.14 Modification Detection Code Packet
> Fortunately, SHA-1 in those packets does not do much harm. But it shows
> that, we do not get rid of SHA-1 by only changing the OpenPGP
> fingerprint algorithm.
> Furthermore, eight other packet types allow to set the used hash
> algorithm. But as SHA-1 is the only mandatory hashing algorithm, we
> may resort to using it, when trying to provide maximal
> interoperability within RFC 4880.
> So if we want to avoid SHA-1 (and I am all for it), we'd rather change
>    "Let's see how to change the fingerprint algorithm."
> to
>    "Let's avoid SHA-1"
> . And it's actually easy.
>> What do I personally hope for here? A think a  solution that introduces
>> a hardcoded Keccak fingerprint in the scope of RFC 4880 would be ideal,
> I tend do disagree.
> As said above switching the fingerprint algorithms, does not
> eliminate SHA-1 from OpenPGP.
> But even if. Forcing the fingerprint algorithm allows for effortless
> interoperability, but it limits the users' freedom to avoid using
> algorithms within the specification's borders.
> Even worse: as soon as the chosen algorithm is broken (for whatever
> value of broken), dependent applications are probably affected/broken
> as well and they cannot switch away quickly.
> We'd end up being in the same situation as now -- only having traded
> SHA-1 by whatever algorithm we'd settle on.
> Best regards,
> Christian
> [1] "Revocation Key" subpackets.
> And the key owner can decide for her-/himself whether she/he wants to add
> "Revocation Key" packets.
> [2] Yes, that includes typical key signing parties.
> [3] Shameless plug: You can for example allow others to avoid SHA-1 at
> key-signing parties, by adding additional (non-standard) SHA-512
> fingerprints to your paper slips:
> as described here

If I understand your proposal correctly, you are changing the hardwired 
SHA-1 fingerprint to SHA-512 without metadata/agility. I also favor this 
path (I was proposing to use Keccak for this to be future-proof, but 
this is the same general idea). Some work need to be done to take care 
of interoperability issues as far as when I see the fingerprint 
referenced, how do I calculate it (SHA-1 or using the new method)?

I was not proposing to get rid of SHA-1 anywhere else, only in the 
single found place where we depend on collision resistance. The NIST SP 
800 107 singles out SHA-1 for collision resistance usage. It's 
prohibiting the use of SHA-1 for digital signatures by the end of next 
year. With this in mind I am hoping for some (slow) process to update 
the fingerprints in OpenPGP. AFAIK, that's the only task that has some 
degree of urgency.

Thank you.

More information about the Gnupg-devel mailing list