On Mon, Jul 23, 2018 at 5:41 AM demerphq <demerphq@xxxxxxxxx> wrote: > > 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. By Git user base you actually mean millions of people? (And they'll have different opinions and needs) One of the goals of the hash transition is to pick a hash function such that git repositories are compatible. If users were to pick their own hashes, we would need to not just give a SHA-1 -> <newhash> transition plan, but we'd have to make sure the full matrix of possible hashes is interchangeable as we have no idea of what the user would think of "safer". For example one server operator might decide to settle on SHA2 and another would settle on blake2, whereas a user that uses both servers as remotes settles with k12. Then there would be a whole lot of conversion going on (you cannot talk natively to a remote with a different hash; checking pgp signatures is also harder as you have an abstraction layer in between). I would rather just have the discussion now and then provide only one conversion tool which might be easy to adapt, but after the majority converted, it is rather left to bitrot instead of needing to support ongoing conversions. On the other hand, even if we'd provide a "different hashes are fine" solution, I would think the network effect would make sure that eventually most people end up with one hash. One example of using different hashes successfully are transports, like TLS, SSH. The difference there is that it is a point-to-point communication whereas a git repository needs to be read by many parties involved; also a communication over TLS/SSH is ephemeral unlike objects in Git. > 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. I do not object to this in theory, but I would rather not want to burden the need to write code for this on the community. > I am not a cryptographer. Same here. My personal preference would be blake2b as that is the fastest IIRC. Re-reading brians initial mail, I think we should settle on SHA-256, as that is a conservative choice for security and the winner in HW accelerated setups, and not to shabby in a software implementation; it is also widely available. Stefan
