Re: Suggestion on hashing

From: Jeff King <peff@peff.net>
Date: Dec 2, 2011, 18:09 UTC
Message-ID: <20111202180951.GC24093@sigill.intra.peff.net>
In-Reply-To: <CACsJy8CO1GtpZVo-oA2eKbQadsXYBEKVLfUH0GONR5jovuvH+Q@mail.gmail.com>

On Fri, Dec 02, 2011 at 09:22:31PM +0700, Nguyen Thai Ngoc Duy wrote:

Show 6 quoted lines

> > So the question is whether
> > using SHA-1 as an ID and SHA-256(?) as a digest is a better long term
> > solution than simply replacing SHA-1.
> 
> I would not stick with any algorithm permanently. No one knows when
> SHA-256 might be broken.

Yeah, you could stick a few bits of algorithm parameter in the beginning of each identifier. It would mean unique hashes get one character or so longer (and they would all start with "1", or whatever the identifier is).

SHA-256 doesn't suffer from SHA-1's problems, though they are based on related constructions, so I think there is some concern that it may eventually fail in the same way. SHA-3 is a better bet in that sense, but it will also be very unproven, even once it is actually standardized.

> > Replacing SHA-1 with something like SHA-256 sounds easier to implement,
> 
> SHA-1 charateristics (like 20 byte length) are hard coded everywhere
> in git, it'd be a big audit.

In theory, you could truncate a longer hash to 160-bits. It's not the bit-strength of SHA-1 that is the problem, but the attacks on the algorithm itself which reduce the bit-strength to something too low. I would think a truncated result would retain the same cryptographic properties, as one of the properties of the un-truncated hash is that changes in the input data are reflected throughout the hash. Some hashes, like Skein, explicitly have a big internal state, and then just let you output as many bytes as is appropriate (i.e., being a drop-in replacement for SHA-1 is an explicit goal).

But I'm not a cryptographer, so there may be some subtle issues with doing that to arbitrary hash functions.

-Peff