ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Fingerprint requirements for OpenPGP

2016-04-12 12:05:37
On Tue, 12 Apr 2016 02:40, dkg(_at_)fifthhorseman(_dot_)net 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.

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp