Re: Hash algorithm analysis
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jul 21, 2018, 19:52 UTC
- Message-ID
- <87va98bc4a.fsf@evledraar.gmail.com>
- In-Reply-To
- <20180720215220.GB18502@genre.crustytoothpaste.net>
On Fri, Jul 20 2018, brian m. carlson wrote:
Show 31 quoted lines
> On Mon, Jun 11, 2018 at 12:29:42PM -0700, Jonathan Nieder wrote: >> 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.