On Fri 2017-08-18 18:53:11 +0200, Vincent Breitmoser wrote:
From discussions so far I seem to be alone in my doubts that
increasing the bitsize of the fingerprint even further is a bad
idea. Still, I'm gonna submit a nay to the record here.
<erstwhile chair hat off, mailing list participant hat only>
I've been looking at, and thinking about, fingerprints and other
identifiers a fair amount for the last several years. I want to make a
couple observations:
* most people don't see (or need to see) the fingerprint explicitly.
for those people, this is a machine-readable value, and not something
to expose.
* for the minority who do actually want to "check fingerprints",
fingerprint-matching need not be done by text string comparison
today. there are lots of other clever ways people can do this with
modern machinery, and we don't need to specify those mechanisms here.
* some cryptosystems already expose full sha256 values to users in
marginal cases -- modern OpenSSH fingerprints are base64-encoded
sha256sums, so there's precedent.
* the difference in size (in terms of transit) between a 200-bit
truncation and a full 256-bit SHA256 sum is 7 octets.
* sha256 has had tons of cryptographic analysis. Truncated sha256 has
not had as much. I don't think there's a risk here, but why deviate
from what's been directly studied?
* simplicity is good.
So in balance, i think i lean toward the full sha256. I recognize that
the additional 7 octets is a downside in some extremely tight
circumstances. But i think the balance comes out in favor of simplicity
and uniformity for implementations.
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp