On Mon, Dec 08, 2014 at 10:25:15AM -0500, Nick Mathewson wrote: > On Mon, Dec 8, 2014 at 8:57 AM, Jason Cooper <tor@xxxxxxxxxxxxxx> 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, For the most part, when a commit is referenced, it's not just the 12 character abbreviation, it's also the Subject line. See the 'Fixes: ...' tag used when flagging commits for the stable tree. This adds a little more robustness against accidental collisions, but as you say... > but for resisting deliberate collisions, I won't really be happy until > git migrates away from SHA1 entirely. Funny you should mention that. :) There's two aspects to that problem. The first, and easy one, is migrating the code away from sha1. Hopefully to something flexible, so new repos could specify core.hash=skein1024 or some other hash that floats the author's boat. The second problem is that of existing repos. My current thought is an enhanced signed tag that contains the following per commit: <full sha1 commit hash> <full XXX hash> <commit subject> Where XXX is the secondary hash of your choice. The hash would be computed exactly the same way as a 'native' repo commit hash using that hash function. This way, an attacker who can generate a sha1 collision to modify an existing commit would now have to generate a collision for a completely different hash function as well. This only protects people who check PGP signed tags, of course. I think it would be a good interim step to set up something like an Observatory that keeps tabs on the core projects (Linux, bash, libc, openssl, etc). It wouldn't even need author participation at first, as long as the observatory counter-signed the tag shortly after the author did. Then we could be reasonably confident that there wasn't time to generate a collision on a commit for which we hadn't signed yet. thx, Jason.
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev