On Sun, Feb 26, 2017 at 12:16:07AM +0000, Jason Cooper wrote: > Hi, > > On Sat, Feb 25, 2017 at 01:31:32AM +0100, ankostis wrote: > > That is why I believe that some HASH (e.g. SHA-3) must be the blessed one. > > All git >= 3.x.x must support at least this one (for naming and > > cross-referencing between objects). > > I would stress caution here. SHA3 has survived the NIST competition, > but that's about it. It has *not* received nearly as much scrutiny as > SHA2. > > SHA2 is a similar construction to SHA1 (Merkle–Damgård [1]) so it makes > sense to be leery of it, but I would argue it's seasoning merits serious > consideration. > > Ideally, bless SHA2-384 (minimum) as the next hash. Five or so years > down the road, if SHA3 is still in good standing, bless it as the next > hash. I don't think we want to be changing hashes that frequently. Projects frequently last longer than five years. I think using a 256-bit hash is the right choice because it fits on an 80-column screen in hex format. 384-bit hashes do not. This matters because line wrapping makes copy-paste hard, and user experience is important. I've mentioned this on the list earlier, but here are the contenders in my view: SHA-256: Common, but cryptanalysis has advanced. Preimage resistance (which is even more important than collision resistance) has gotten to 52 of 64 rounds. Pseudo-collision attacks are possible against 46 of 64 rounds. Slowest option. SHA-3-256: Less common, but has a wide security margin. Cryptanalysis is ongoing, but has not advanced much. Somewhat to much faster than SHA-256, unless you have SHA-256 hardware acceleration (which almost nobody does). BLAKE2b-256: Lower security margin, but extremely fast (faster than SHA-1 and even MD5). My recommendation has been for SHA-3-256, because I think it provides the best tradeoff between security and performance. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: https://keybase.io/bk2204