On Tue, May 5, 2015 at 7:48 PM, Christoph Anton Mitterer
<calestyo(_at_)scientia(_dot_)net> wrote:
On Tue, 2015-05-05 at 23:26 +0200, Vincent Breitmoser wrote:
I would like to pick up on this point again: What's wrong with 160 bit
fingerprints? The bit length seems more than sufficient to cover any
Mooreian doubts, a more relevant issue would be weaknesses in the
hashing algorithm itself,
The problem isn't the bit length, it is the fact that it is really
hard for the IETF to endorse use of SHA-1 in some places but not
others. There is really no reason to think that the current attacks
make SHA-1 risky in the WebPKI but we are having to swap it out
anyway.
At some level, the cost of explaining why SHA-1 is safe for a
particular use outweighs the benefits of keeping it.
Hmm but if it can be easily done, is there anything that speaks against?
I don't think so. Particularly if we are going to Base32 encoding and
make sure that there is no confusion between the legacy SHA-1
fingerprints and the new ones.
I think hashes up to 512 bit are still commonly "accepted" (even with
just hex encoding)... and I see no strong reason why we couldn't move to
e.g. RFC 4648 base32.
Actually others do similar things as well (e.g. OpenSSH).
Which is why I would like to move to a fingerprint format that can be
used with any protocol. Do it once, do it right and we don't have to
do it again.
And if it doesn't hurt, I rather go for the stronger, even if it should
never become necessary.
We do not even need to decide on a strength. Just make is so that the
number of significant bits is however many bits that are provided. We
can all use SHA-2-512 or SHA-3-512 and truncate to 125, 150, 250...
bits as the application requires.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp