Junio C Hamano <gits...@pobox.com> writes: > Adam Langley <a...@google.com> writes: > >> However, as I'm not a git developer, I've no opinion on whether the >> cost of carrying implementations of these functions is worth the speed >> vs using SHA-256, which can be assumed to be supported everywhere >> already. > > Thanks. > > My impression from this thread is that even though fast may be > better than slow, ubiquity trumps it for our use case, as long as > the thing is not absurdly and unusably slow, of course. Which makes > me lean towards something older/more established like SHA-256, and > it would be a very nice bonus if it gets hardware acceleration more > widely than others ;-)
Ah, I recall one thing that was mentioned but not discussed much in the thread: possible use of tree-hashing to exploit multiple cores hashing a large-ish payload. As long as it is OK to pick a sound tree hash coding on top of any (secure) underlying hash function, I do not think the use of tree-hashing should not affect which exact underlying hash function is to be used, and I also am not convinced if we really want tree hashing (some codepaths that deal with a large payload wants to stream the data in single pass from head to tail) in the context of Git, but I am not a crypto person, so ...
