[openpgp] Summary v5 fingerprint proposal

[Werner Koch]

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

[Nicholas Cole]

Post by Werner Koch
Hi!
- Thijs: Not a strong preference, though.
- Jon: Speed of fingerprint computing doesn't matter. SHA-512 is more
future proof.
- 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.
- 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.

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

[HANSEN, TONY L]

Post by Nicholas Cole

Post by Werner Koch
Hi!
. . .
- 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.
. . .
- 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.

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.

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

[Werner Koch]

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

[Jon Callas]

Post by Werner Koch

Post by HANSEN, TONY L
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.

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.

Post by Werner Koch
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.

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.

Post by Werner Koch
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.

Post by HANSEN, TONY L
But I also find Derek’s desire to use SHA2-256 to be compelling because of performance.

Noted.

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

[Werner Koch]

Post by Jon Callas
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.

Post by Jon Callas
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.

Post by Jon Callas
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

[Vincent Breitmoser]

Post by Jon Callas
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