On Wed, 6 May 2015 09:16, look@my.amazin.horse said:
There is such a thing as over-engineering, and increasing a fingerprint
bit length upwards of 160 bits "just because we can" seems to go in that
We also need to consider policy requirements. As Phillip already
mentioned it is hard to explain why SHA-1 is sufficient. In particular
because we use it in a crypto context. It seems to be hard enough to
explain why using SHA-1 would be sufficient to map a string to a
restricted character set (for DNS) even without any crypto context.
For example: RedHat did a FIPS-140 validation of Libgcrypt and this
required that RMD-160 is disabled in Libgcrypt. Now, for historic
reasons GnuPG uses this hash algorithm to map user ids to fixed length
strings for use in trustdb.gpg. With the Libgcrypt change I had to put
separate RMD-160 code into GnuPG to avoid regressions (only Libgcrypt
was validated). Eventually the same will happen to SHA-1.
To be future proof we should get away from SHA-1 for fingerprints and
use SHA-256 (or SHA-512) instead. The external representation and even
the internal use in OpenPGP is a different issue and I am all in favor
for truncating it to 32 bytes for internal use and printing only up to
20 bytes. This avoids extra work and SHA-256 is anyway required.
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