Subject: [openpgp] Summary v5 fingerprint proposal

From: Werner Koch <[email-masked]>
Date: Thu, 23 Mar 2017 08:53:07 +0100

Hi!

I try to summarize the positions on the v5 fingerprint porposal:

In favor of SHA-512 truncated to 200 bits:

  - Thijs: Not a strong preference, though.

  - Jon: Speed of fingerprint computing doesn't matter.  SHA-512 is more
         future proof.

In favor of SHA-256 truncated to 200 bits:

  - Vincent: Even wants to truncate to 160 bits.

  - Derek: Better for small systems.  He gave numbers and showed that
           for fingerprints SHA-256 is even faster on systems where
           SHA-512 is in general faster.

  - Peter Gutmann: Better for small systems.

  - Werner: Allows SHA-256 only implementation to support IoST systems.

Other comments:

  - Jon: Use SHA-512/t to have a well defined truncation scheme.

  - Peter Todd: Do not truncated because the saving is not worth using a
                non-standard scheme.

  - Brian: Use SHAKE128 or 256, will be needed anyway if we add
           Curve448.

  - Werner: Using SHA-512 would allow compliant applications in case
            Ed25519 would be a mandatory algorithm.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Nicholas Cole <[email-masked]>
Date: Thu, 23 Mar 2017 11:18:05 +0000

>             Ed25519 would be a mandatory algorithm.

I'd add this one:

any time a spec does something non-standard it is a lightening rod for
criticism and FUD.  Even if there are good and rational reasons for
doing something else, I'd advocate using a standard hash without
truncating for that reason.

Nicholas

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Thu, 23 Mar 2017 14:00:45 +0000

On 3/23/17, 7:18 AM, "openpgp on behalf of Nicholas Cole" <[email-masked] on behalf of [email-masked]> wrote:

    On Thu, Mar 23, 2017 at 7:53 AM, Werner Koch <[email-masked]> wrote:
    >> . . .
    >> . . .

>    truncating for that reason.

I’m with Jon on this one – if you’re going to do truncation, then use a scheme that’s DESIGNED to generate a truncated value. And the only one that’s been discussed that meets that criteria is SHA2-512/t. 

But I also find Derek’s desire to use SHA2-256 to be compelling because of performance.

	Tony Hansen

---

From: Werner Koch <[email-masked]>
Date: Thu, 23 Mar 2017 17:49:21 +0100

On Thu, 23 Mar 2017 15:00, [email-masked] said:

> I’m with Jon on this one – if you’re going to do truncation, then use
> a scheme that’s DESIGNED to generate a truncated value. And the only
> one that’s been discussed that meets that criteria is SHA2-512/t.

OpenPGP has always used a truncated hash for the keyid.  The change is
that with v5 we will use use the leftmost 64 bits instead of the
rightmost 64 bit.

I explained in the original proposal the reasons why truncating certain
uses of the fingerprint makes sense.

Jon's suggestion of using SHA2-512/t does not work: if we ever need to
switch to the full fingerprint for the two signature subpackets, we
would need to define a v6 key format because the fingerprint changes by
using a different t with SHA2-512/t.

What we put into the signature subpackets is an abbreviation of the
fingerprint and this can be changed easily by introducing new signature
subpackets.  This would be the same as our migration from the /Issuer/
to the /Issuer Fingerprint/ subpacket.  This is an non-intrusive change
to fix the problems with the use of the 64 bit truncated fingerprint in
the /Issuer/ subpacket.

> But I also find Derek’s desire to use SHA2-256 to be compelling because of performance.

Noted.

Shalom-Salam,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Thu, 23 Mar 2017 11:55:00 -0700

> On Mar 23, 2017, at 9:49 AM, Werner Koch <[email-masked]> wrote:
> 

I don't have any objection to truncating the fingerprint to get the KeyID. The KeyID is merely a database key (as in key-value, not crypto) and has no security value. Implementations already need to consider the possibility that there could be a collision in the KeyID.

> using a different t with SHA2-512/t.

You don't need a new format, you'd just specify the new fingerprint. You can consider SHA512/t to be a family of hashes of output 't'.

If you're mentioning using SHA512/64 for a key id — no, no, that's just unnecessary.

>> But I also find Derek’s desire to use SHA2-256 to be compelling because of performance.

For the record, I don't object to using SHA-256. I observe that there are a set of cases where someone finds problems in SHA2 that would have a longer runway for replacement if we're using SHA-512, and *that* is either a bug or a feature since arguably once someone finds some actual problem in SHA-256 (e.g. of the sort that has plagued SHA-1 since 2004), that should be the event that leads to tossing all of SHA2.

 I also observe that the performance issue is real, but hardly fatal — small devices will be with us always and fingerprints can be computed once and cached no matter what. This is why I didn't bring up the counter-argument which is that ARM64 is already sub- one euro per core.

The real reason to use a wider hash is that every time we've compromised on security for the sake of small devices, it bites us in the ass. This will also bite us in the ass. It's a small bite in the grand scheme of things, but it's going to happen and it will be inconvenient.

Do we have a meta-strategy for an upgrade? For example, if we know that you'd pick whatever hash at that time the cool kids recommend, change a couple of parameters (like simply bump the key version to v6 and go), that could be a recommendation in the RFC.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Thu, 23 Mar 2017 20:16:50 +0100

On Thu, 23 Mar 2017 19:55, [email-masked] said:

> I don't have any objection to truncating the fingerprint to get the
> KeyID. The KeyID is merely a database key (as in key-value, not
> crypto) and has no security value. Implementations already need to
> consider the possibility that there could be a collision in the KeyID.

Okay, let us split the discussion between crypto use and mere database
lookup:

  * Revocation key and Issuer Fingerprint:

    - For a V5 key the 25 leftmost octets are used.

The /Revocation key/ is sensitive in that a preimage attack can be used
to revoke a key.  That is mostly a DOS and thus not really dangerous.
However, I am fine with using the full hash here.

The /Issuer Fingerprint/ is a key to a database to retrieve the key for
verification of signatures.  Thus it does not even need 200 bits but we
could also simply keep it at 160 without problems.  We could also allow
to let the sender decide how long the /Issuer Fingerprint/ shall be.
But a fixed length makes the implementation easier.  I decided for 200
bits to match the probably used human readable format of the
fingerprint.

> You don't need a new format, you'd just specify the new
> fingerprint. You can consider SHA512/t to be a family of hashes of
> output 't'.

I was under the impression that we already agreed that there shall be
only one fingerprint scheme per key.

> Do we have a meta-strategy for an upgrade? For example, if we know
> that you'd pick whatever hash at that time the cool kids recommend,
> change a couple of parameters (like simply bump the key version to v6
> and go), that could be a recommendation in the RFC.

I think this is a good suggestion.

Salam-Shalom,

   Werner

---

From: Vincent Breitmoser <[email-masked]>
Date: Thu, 23 Mar 2017 20:58:18 +0100

Jon Callas([email-masked])@Thu, Mar 23, 2017 at 11:55:00AM -0700:
> The real reason to use a wider hash is that every time we've
> compromised on security for the sake of small devices, it bites us in
> the ass. This will also bite us in the ass. It's a small bite in the
> grand scheme of things, but it's going to happen and it will be
> inconvenient.

Is your point that we should use *more* than 256 bits for an identifier
that doesn't even need preimage resistance?

There are four use cases for such an identifier:

 - provide a reference to a key in signatures. note that this is not a
   cryptograhpic purpose, since the actual signatures are calculated
   over the entire key. we have been using 64 bit key ids for this
   purpose so far.

 - show to humans to have them verify two keys are identical. by
   definition, we trust the person showing this fingerprint, which
   renders collision a pointless attack scenario.

 - use as a handle for a designated revoker. assuming there is a
   collision, either colliding key could be used for revocation. since
   those would both be generated by an attacker in either case, there's
   no issue.

 - use as a handle for obtaining (downloading / updating) a key. a
   keyserver (or equivalent) could equivocate here, but *only* if they
   control the looked-up fingerprint in the first place, or at least
   generated the (colliding) key.

Am I missing a use case? Even including a ton of security margin, 256
bits already seems way overkill to me for any of those purposes.

 - V