On Sat, Mar 04, 2017 at 06:35:38PM -0800, Linus Torvalds wrote: > On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > > > > This document is still in flux but I thought it best to send it out > > early to start getting feedback. > > This actually looks very reasonable if you can implement it cleanly > enough. In many ways the "convert entirely to a new 256-bit hash" is > the cleanest model, and interoperability was at least my personal > concern. Maybe your model solves it (devil in the details), in which > case I really like it.
If you think you can do it, I'm all for it. > Btw, I do think the particular choice of hash should still be on the > table. sha-256 may be the obvious first choice, but there are > definitely a few reasons to consider alternatives, especially if it's > a complete switch-over like this. > > One is large-file behavior - a parallel (or tree) mode could improve > on that noticeably. BLAKE2 does have special support for that, for > example. And SHA-256 does have known attacks compared to SHA-3-256 or > BLAKE2 - whether that is due to age or due to more effort, I can't > really judge. But if we're switching away from SHA1 due to known > attacks, it does feel like we should be careful. I agree with Linus on this. SHA-256 is the slowest option, and it's the one with the most advanced cryptanalysis. SHA-3-256 is faster on 64-bit machines (which, as we've seen on the list, is the overwhelming majority of machines using Git), and even BLAKE2b-256 is stronger. Doing this all over again in another couple years should also be a non-goal. -- 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
signature.asc
Description: PGP signature
