On Mon, Jun 11, 2018 at 11:19:10PM +0200, Ævar Arnfjörð Bjarmason wrote: > This is a great summary. Thanks. > > In case it's not apparent from what follows, I have a bias towards > SHA-256. Reasons for that, to summarize some of the discussion the last > time around[1], and to add more details: To summarize my view, I think my ordered preference of hashes is BLAKE2b, SHA-256, and SHA3-256. I agree with AGL that all three of these options are secure and will be for some time. I believe there's sufficient literature on all three of them and there will continue to be for some time. I've seen and read papers from the IACR archves on all three of them, and because all three are widely used, they'll continue to be interesting to cryptologists for a long time to come. I'm personally partial to having full preimage resistance, which I think makes SHAKE128 less appealing. SHAKE128 also has fewer crypto library implementations than the others. My rationale for this ordering is essentially performance. BLAKE2b is quite fast on all known hardware, and it is almost as fast as an accelerated SHA-256. The entire rationale for BLAKE2b is to give people a secure algorithm that is faster than MD5 and SHA-1, so there's no reason to use an insecure algorithm. It also greatly outperforms the other two even in pure C, which matters for the fallback implementation we'll need to ship. I tend to think SHA3-256 is the most conservative of these choices as far as security. It has had an open development process and has a large security margin. It has gained a lot of cryptanalysis and come out quite well, and the versatility of the Keccak sponge construction means that it's going to get a lot more attention. Pretty much the only downside is its performance relative to the other two. I placed SHA-256 in the middle because of its potential for acceleration on Intel hardware. I know such changes are coming, but they won't likely be here for another two years. While hashing performance isn't a huge concern for Git now, I had planned to implement an rsync-based delta algorithm for large files that could make storing some large files in a Git repository viable (of course, there will still be many cases where Git LFS and git-annex are better). The algorithm is extremely sensitive to hash performance and would simply not be viable with an unaccelerated SHA-256 or SHA3-256, although it would perform reasonably well with BLAKE2b. Having said that, I'd be happy with any of the three, and would support a consensus around any of them as well. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
