Re: Hash algorithm analysis
From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2018-07-21 19:52:10
On Fri, Jul 20 2018, brian m. carlson wrote:
On Mon, Jun 11, 2018 at 12:29:42PM -0700, Jonathan Nieder wrote:quoted
My understanding of the discussion so far: Keccak team encourages us[1] to consider a variant like K12 instead of SHA3. AGL explains[2] that the algorithms considered all seem like reasonable choices and we should decide using factors like implementation ease and performance. If we choose a Keccak-based function, AGL also[3] encourages using a variant like K12 instead of SHA3. Dscho strongly prefers[4] SHA-256, because of - wide implementation availability, including in future hardware - has been widely analyzed - is fast Yves Orton and Linus Torvalds prefer[5] SHA3 over SHA2 because of how it is constructed.I know this discussion has sort of petered out, but I'd like to see if we can revive it. I'm writing index v3 and having a decision would help me write tests for it. To summarize the discussion that's been had in addition to the above, Ævar has also stated a preference for SHA-256 and I would prefer BLAKE2b over SHA-256 over SHA3-256, although any of them would be fine. Are there other contributors who have a strong opinion? Are there things I can do to help us coalesce around an option?
I have a vague recollection of suggesting something similar in the past, but can't find that E-Mail (and maybe it never happened), but for testing purposes isn't in simplest if we just have some "test SHA-1" algorithm where we pretent that all inputs like "STRING" are really "PREFIX-STRING" for the purposes of hashing, or fake shortening / lengthening the hash to test arbitrary lenghts of N (just by repeating the hash from the beginning is probably good enough...). That would make such patches easier to review, since we wouldn't need to carry hundreds/thousands of lines of dense hashing code, but a more trivial wrapper around SHA-1, and we could have some test mode where we could compile & run tests with an arbitrary hash length to make sure everything's future proof even after we move to NewHash.