On 24 February 2017 at 18:23, Jason Cooper <git@xxxxxxxxxxxxxx> wrote:
> Hi Ian,
>
> On Fri, Feb 24, 2017 at 03:13:37PM +0000, Ian Jackson wrote:
>> Joey Hess writes ("SHA1 collisions found"):
>> > https://shattered.io/static/shattered.pdf
>> > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/
>> >
>> > IIRC someone has been working on parameterizing git's SHA1 assumptions
>> > so a repository could eventually use a more secure hash. How far has
>> > that gotten? There are still many "40" constants in git.git HEAD.
>>
>> I have been thinking about how to do a transition from SHA1 to another
>> hash function.
>>
>> I have concluded that:
>>
>> * We can should avoid expecting everyone to rewrite all their
>> history.
>
> Agreed.
>
>> * Unfortunately, because the data formats (particularly, the commit
>> header) are not in practice extensible (because of the way existing
>> code parses them), it is not useful to try generate new data (new
>> commits etc.) containing both new hashes and old hashes: old
>> clients will mishandle the new data.
>
> My thought here is:
>
> a) re-hash blobs with sha256, hardlink to sha1 objects
> b) create new tree objects which are mirrors of each sha1 tree object,
> but purely sha256
> c) mirror commits, but they are also purely sha256
> d) future PGP signed tags would sign both hashes (or include both?)
IMHO that is a great idea that needs more attention.
You get to keep 2 or more hash-functions for extra security in a PQ world.
And to keep sketches for the future so far,
SHA-3 must be always one of the new hashes.
Actually, you can get rid of SHA-1 completely, and land on Linus's
current sketches for the way ahead.
Thanks,
Kostis
>
> Which would end up something like:
>
> .git/
> \... #usual files
> \objects
> \ef
> \3c39f7522dc55a24f64da9febcfac71e984366
> \objects-sha2_256
> \72
> \604fd2de5f25c89d692b01081af93bcf00d2af34549d8d1bdeb68bc048932
> \info
> \...
> \info-sha2_256
> \refs #uses sha256 commit identifiers
>
> Basically, keep the sha256 stuff out of the way for legacy clients, and
> new clients will still be able to use it.
>
> There shouldn't be a need to re-sign old signed tags if the underlying
> objects are counter-hashed. There might need to be some transition
> info, though.
>
> Say a new client does 'git tag -v tags/v3.16' in the kernel tree. I would
> expect it to check the sha1 hashes, verify the PGP signed tag, and then
> also check the sha256 counter-hashes of the relevant objects.
>
> thx,
>
> Jason.