On Mon, Jul 23, 2018 at 5:48 AM Sitaram Chamarty <sitar...@gmail.com> wrote:
>
> I would suggest (a) hash size of 256 bits and (b) choice of any hash
> function that can produce such a hash. If people feel strongly that 256
> bits may also turn out to be too small (really?) then a choice of 256 or
> 512, but not arbitrary sizes.
Honestly, what's the expected point of 512-bit hashes?
The _only_ point of a 512-bit hash is that it's going to grow objects
in incompressible ways, and use more memory. Just don't do it.
If somebody can break a 256-bit hash, you have two choices:
(a) the hash function itself was broken, and 512 bits isn't the
solution to it anyway, even if it can certainly hide the problem
(b) you had some "new math" kind of unexpected breakthrough, which
means that 512 bits might not be much better either.
Honestly, the number of particles in the observable universe is on the
order of 2**256. It's a really really big number.
Don't make the code base more complex than it needs to be. Make a
informed technical decision, and say "256 bits is a *lot*".
The difference between engineering and theory is that engineering
makes trade-offs. Good software is well *engineered*, not theorized.
Also, I would suggest that git default to "abbrev-commit=40", so that
nobody actually *sees* the new bits by default. So the perl scripts
etc that use "[0-9a-f]{40}" as a hash pattern would just silently
continue to work.
Because backwards compatibility is important (*)
Linus
(*) And 2**160 is still a big big number, and hasn't really been a
practical problem, and SHA1DC is likely a good hash for the next
decade or longer.
