Git hash function transition plan

But does not solve the problem. Multihashes are not unique identifiers of a message, which is what git mostly uses hashes for. Now, instead of a single unique identifier, you have N possible ones, where N is the number of hash implementations your multihash library has. And it is not possible to convert between two hash types without having the original message.

Wasn't there an issue with JWT that was summarized as this:

"This is a good idea, but it doesn't solve the underlying problem: attackers control the choice of algorithm" ?

Here's another quote from the Wireguard paper[1]:

"Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update"

[1]: https://www.wireguard.com/papers/wireguard.pdf

Well-designed protocols generally include algorithm identifiers. It doesn't mean that upgrade will always be easy though.

I really don't like given this a new name ("multihash"). We have a name already: algorithm agility. We should use that name.

I also don't like this idea of having a standard for algorithm agility for hash functions (and another for encryption algorithms, and...).

It's also not obvious that making every hash/MAC/public key payload carry an algorithm ID is the right design for every protocol (it's not), though for git it is.

Something about multihash makes me worry it's a security risk. Like I worry that it encourages this mistake:

1. Define a new protocol with multihash somewhere in it.

2. Import a super convenient multihash library.

3. Verify all hashes with a simple library function.

That sounds super natural and convenient to me, but if it means that you support MD4 by default, then you've introduced a downgrade attack into your protocol.

They actually considered the reverse (search for `Using hash functions in parallel`)

Here is a rich text version of the same document: https://www.kernel.org/pub/software/scm/git/docs/technical/h...

It's written an asciidoc, which GitHub can render too. It's a matter of changing the extension or adding vim modeline.

For something as widespread as Git, there is no "post-transition", I'm afraid: while maintained code will get migrated, old repositories will hang around Forever.

Note that Git is a protocol - all of its implementations will eventually need to change, and each repo using it as well. This is decentralized by the very purpose of Git.

It explains this further rather later in the document.

There's a compatibility mode, where it understands a translation between SHA-1 named objects and NewHash named objects, and translates them at the boundary - i.e. during a pull or a push.

Obviously you're at risk to some extent of flaws in SHA-1 being exploited in your remote, although presumably if the translation layer detects the SHA-1 of something didn't change but the NewHash did then it'll scream.

It does seem this is a temporary situation though, as it mentions in one small sentence that for the final transition stage they envisage the protocol also supporting NewHash, so they can throw away all SHA-1 metadata everywhere. What they don't address in that plan is how the protocol gets extended, but they do clearly rely on that happening for the full transition to take place.

He makes excellent points on tags; the one I hadn't considered before is that tags indeed can be separated from the tree, which makes them a unique asset in a git tree.

The problem with that however is how we use tags today. Creating a tag in the modern lingua franca of git means creating a new version. If you push that tag to Github or Gitlab or what have you, a handy "release" will be created for you. If you're signing all your commits for some security reason, you don't want that, aye?

So you'd want tags that are tracked separately and that's not easy to do. `git commit --sign` is going to include the signature in the commit, not create a separately-tracked tag with an appropriate name or whatever. It certainly sounds interesting, albeit unintuitive, and that summarizes git perfectly :)

Mike Gerwitz on signing commits: https://mikegerwitz.com/papers/git-horror-story.

That analogy presumes that the hash function's output is uniformly random; when you know how to manipulate it s.t. its output is not random, then obviously it doesn't hold.

The question of accidental collisions is still relevant, even with SHA-256, and the answer is still the same: it's so vanishingly improbable that it is assumed to be impossible.

Not sure what K12 is (Keccak?), but BLAKE2 is a very attractive option.

SHA3 is slow.

I was under the impression that it's just a placeholder until the actual new hash function was decided on.

Also the whole point of this transition plan is that it will be a completely optional, per local repository, transition. So less technically savvy users won't have to worry about it in the first place.

Can someone explain the name? It does not look like a good name. Or is NewHash just a placeholder name for the git project because the haven't made a final decision on a new hash function? (It's hard to google and find out)

Chains of Git commits are already a blockchain - at least, already a DAG, and to be more specific, they are both Merkle trees. Internally, each commit contains the hash of the previous commit it was based on:

    $ git cat-file -p HEAD
    tree e013f4d121199d60b70043f525aef4a7e641b5f6
    parent 152bbb43b30ced1b32e9ed6f5ba2ac448de725b6
    author Linus Torvalds <torvalds@linux-foundation.org> 1510512373 -0800
    committer Linus Torvalds <torvalds@linux-foundation.org> 1510512373 -0800

    Linux 4.14

(Kids these days with their blockchains...)

git already is a hash linked datastore with the ability to sign your 'transactions'. The doc just points out that SHA1 is not a reliable hash to address objects anymore.

> ...it seems like a block chain would be ideal

If I could get just 1 satoshi every time I see this suggestion...