Re: [openpgp] v5 in the crypto-refresh draft

[Daniel Kahn Gillmor <[e-mail]>]

Thanks for raising this concern, and for proposing text, Peter.

While the standard itself actually uses fingerprints and keys rarely
(only in the "issuer", "issuer fingerprint" and "revocation key"
subpackets), I think for this discussion we should remember the most
sensitive context for use of key IDs and fingerprints, which i'll call
the "comparison-verification" practice:

Key ID or fingerprint comparison has been recommended in the past by the
OpenPGP community as a reasonable way that one communications peer can
confirm that they have the "right key".

I grant that comparison-verification is not specified in RFC 4880, but
we can't pretend it doesn't happen either.  (the fact that people are
not actually very good at performing comparison-verification is itself a
separate issue)

Peter Gutmann wrote:

>> There are no cryptographic issues introduced by this

I'm concerned about the unclear antecedent to "this" here.

It might be read as saying that there are no cryptographic issues
introduced by 64-bit key ID collisions, but i think it's talking only
about 160-bit fingerprint collisions.

There may well be cryptographic risks for any user or implementation
that uses comparison-verification based on key IDs specifically -- it's
downright cheap for a third party to generate a colliding 32-bit key ID
(cf evil-32), and within plausibility for a third party to generate a
colliding 64-bit key ID, even assuming a theoretically perfect hash
function (particularly if any one of a pool of potential keys can be
targeted: the larger the pool, the faster the brute-force attack).

>> since the fingerprint is merely a fixed-length opaque value used to
>> identify the variable-length structured data that makes up a public
>> key.

I don't think this sentence characterizes the entire argument.  If the
fingerprint were calculated over any *externally-supplied* data in
addition to the data generated by the keyholder, it *would* be a
cryptographic issue, because the provider of that external data might be
able to manipulate the fingerprint, which could then be used to break
any comparison-verification practice that uses full fingerprints.

The fact that the fingerprint is calculated over data that is intended
to be supplied uniquely by the keyholder is what makes SHA-1's weak
collision-resistance a non-issue in this context.

>> In particular the move to SHA-256 for V5 fingerprints was made not to
>> address any cryptographic vulnerability but to avoid the perception
>> that something insecure might be happening due to the use of SHA-1.

On Mon 2021-06-07 14:45:53 -0400, Paul Wouters wrote:
> With no hats on, I would probably change the latter bit to:
>
>    In particular the move to SHA-256 for V5 fingerprints was not made to address
>    any cryptographic vulnerability, but was made to follow the generic
>    guidelines of the cryptograhic community to sunset the use of SHA-1.

I'm fine with either of these two framings, with a slight preference for
Paul's text as it captures a bit more of the shifting landscape.

       --dkg