On Mon, Dec 8, 2014 at 8:57 AM, Jason Cooper tor@lakedaemon.net wrote: [...]
On a tangent, referring to keys by their short (or long, for that matter) keyid is not a good idea. How to verify Nick actually has the blessing of the Tor project (or any subset of people therein, etc) to sign tags is yet another problematic area without a real solution.
Yes, using the 32bit identifier certainly is prone to collisions, but we also aren't attempting to validate that key in this thread. At the 2013 Kernel Summit, Linus advised using 12 characters for abbreviated commit hashes over the current norm of 7. Same problem, different aspect.
Yeah; and it's not like generating collisions or second preimages on a 48-bit identifier is out-of-reach for a bored undergraduate. Using a 12-char abbreviated ID this long will prevent more accidental collisions, but for resisting deliberate collisions, I won't really be happy until git migrates away from SHA1 entirely.