Werner Koch <wk(_at_)gnupg(_dot_)org> writes:
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.
Agreed.
* 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.
I still believe we should use b, with the knowledge that the hard
expiration is optional (could be 0). This would protect against an
attack where you lose control of your secret material and the attacker
creates a new self-sig with a new expiration time.
Salam-Shalom,
Werner
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp