On Sun, 22 Jul 2018 at 01:59, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > I will admit that I don't love making this decision by myself, because > right now, whatever I pick, somebody is going to be unhappy. I want to > state, unambiguously, that I'm trying to make a decision that is in the > interests of the Git Project, the community, and our users. > > I'm happy to wait a few more days to see if a consensus develops; if so, > I'll follow it. If we haven't come to one by, say, Wednesday, I'll make > a decision and write my patches accordingly. The community is free, as > always, to reject my patches if taking them is not in the interest of > the project. Hi Brian. I do not envy you this decision. Personally I would aim towards pushing this decision out to the git user base and facilitating things so we can choose whatever hash function (and config) we wish, including ones not invented yet. Failing that I would aim towards a hashing strategy which has the most flexibility. Keccak for instance has the interesting property that its security level is tunable, and that it can produce aribitrarily long hashes. Leaving aside other concerns raised elsewhere in this thread, these two features alone seem to make it a superior choice for an initial implementation. You can find bugs by selecting unusual hash sizes, including very long ones, and you can provide ways to tune the function to peoples security and speed preferences. Someone really paranoid can specify an unusually large round count and a very long hash. Also frankly I keep thinking that the ability to arbitrarily extend the hash size has to be useful /somewhere/ in git. cheers, Yves I am not a cryptographer. -- perl -Mre=debug -e "/just|another|perl|hacker/"
