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

From: Peter Gutmann <[email-masked]>
Date: Sun, 6 Jun 2021 07:53:39 +0000

Daniel Kahn Gillmor writes:

>If folks really want to re-litigate it, 

Oh, I don't want to re-do the whole debate but was more thinking that the
draft should provide a rationale for why -1 was dropped in favour of -256,
both to explain to implementers and users who aren't on the mailing list what
properties are and aren't required for fingerprints, and to provide guidance
in the future when it's decided to move off -256 to something else.

Peter.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 6 Jun 2021 11:30:35 -0400 (EDT)

> in the future when it's decided to move off -256 to something else.

We are happy to accept such proposed text, please send it to the list :)

Paul

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 7 Jun 2021 13:41:41 +0000

>We are happy to accept such proposed text, please send it to the list :)

Well, if I write it people may be less happy with the text :-).  OK, how
about, after the paragraph "Note that it is possible for there to be
collisions of Key IDs", add:

-- Snip --

There are no cryptographic issues introduced by this since the fingerprint is
merely a fixed-length opaque value used to identify the variable-length
structured data that makes up a public key.  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.

-- Snip --

Peter.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 7 Jun 2021 14:45:53 -0400 (EDT)

> collisions of Key IDs", add:

Thanks :)

> but to avoid the perception that something insecure might be happening due to

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.

This would then also capture other reasons than the one you mention,
such as possible unavailability in crypto libaries or runtime modes
(FIPS) etc etc.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 09 Jun 2021 15:09:46 -0400

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.

>    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