Re: [openpgp] Fingerprint requirements for OpenPGP

[Werner Koch <[e-mail]>]

On Tue, 12 Apr 2016 02:40, [e-mail] said:

> Note that a human is always in the loop in these transfers.  If no human
> is in the loop, we do not need the fingerprint, and can (and probably
> should) use some other technique.

Given that the fingerprint is of constant size or at least has an upper
limit, it has advantages in protocol design too.  I can see only two
other options:

 - Some newly made-up identifier.  This brings us back to
   the X.509 mess of several ways to locate a key.

 - Using the the full public key: This would be fine for ECC, is
   troublesome for RSA, and for PQC it would be ridiculous large.

Thus I think a binary fingerprint is even preferable with no humans in
the loop.

>  * it should be cheap to compute from a given key -- you shouldn't need
>    a gig of RAM or a minute of CPU to calculate the fingerprints of any
>    key.

According to Peter, this means SHA-256.  There may be no proof-of-work
to for creating a key and thus a structured fingerprint.  (Sometimes you
have to create a lot of one-off keys.)

>  * it should be strong enough that we do not believe anyone can create a
>    key with a fingerprint that collides with another key's fingerprint

As Vincent pointed out, we only need preimage resistance.

> If not, what's missing?

Whether to hash a

  a) fixed string and a creation date,
  b) fixed string and creation date and a hard expiration date,
  c) fixed string,
  d) nothing

in addition to the algorithm parameters.  My conclusion from the
discussions is that we should to decide between a) and c).  I don't
really care given that using a creation date of 0 can be used when
needed.



Salam-Shalom,

   Werner

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