3 ms·

So can anyone explain no one considered that you might want to ultimately use a different hashing algorithm than sha1? All hashing algorithms have a shelf life

by cletus 7y ago

So can anyone explain no one considered that you might want to ultimately use a different hashing algorithm than sha1? All hashing algorithms have a shelf life before it becomes feasible to compromise them such that you need to migrate to something more secure. Yet the Git format seems but built for this are all. No hash versioning, no allowance for multiple hashes and no way you define the hash size such that now it seems like moving on from sha1 is going to be a giant pain. TCP/IP had this from many years earlier (a version at least). This seems like such a glaring oversight. Or am I missing something?

stevekemp 7y ago
See this recent article from LWN: https://lwn.net/Articles/811068/ https://lwn.net/Articles/811068/ That contains a link to an early comment from Linux.
bebop 7y ago
It could be that they knew that the hash algorithm was good for uniqueness and they were unconcerned about security. The SHA1 hash provides no security in git, only whether a file has been changed or not. While collisions have been found in SHA1, it is still a decent hashing algorithm where collisions are extremely unlikely.
- dependenttypes 7y ago
  > collisions are extremely unlikely Random collisions are quite unlikely, intentional collisions not so much. > The SHA1 hash provides no security in git False. OpenPGP signatures in git depend on the SHA1 hash. Same for someone doing a checkout at a specific hash because they trust it.
tialaramex 7y ago
> All hashing algorithms have a shelf life before it becomes feasible to compromise them such that you need to migrate to something more secure. This is at best an unproven conjecture and more likely just plain wrong. Which doesn't make it any saner for Git to have chosen SHA-1 given its status at the time, (SHA-256 was the right choice then and remains a sound choice now) but it certainly isn't true that there's some cosmic law giving hashing algorithms a "shelf life" in this way.
tscheer 7y ago
Linus discussed this in: https://lore.kernel.org/lkml/Pine.LNX.4.58.0504090902170.1267@ppc970.osdl.org/ https://lore.kernel.org/lkml/Pine.LNX.4.58.0504090902170.126... The key point for me is his note that you have to more than copy the SHA1. That it will have to also be a valid zlib object with a matching header.

by cletus 7y ago

stevekemp 7y ago

See this recent article from LWN: https://lwn.net/Articles/811068/ https://lwn.net/Articles/811068/ That contains a link to an early comment from Linux.

bebop 7y ago

It could be that they knew that the hash algorithm was good for uniqueness and they were unconcerned about security. The SHA1 hash provides no security in git, only whether a file has been changed or not. While collisions have been found in SHA1, it is still a decent hashing algorithm where collisions are extremely unlikely.

dependenttypes 7y ago
> collisions are extremely unlikely Random collisions are quite unlikely, intentional collisions not so much. > The SHA1 hash provides no security in git False. OpenPGP signatures in git depend on the SHA1 hash. Same for someone doing a checkout at a specific hash because they trust it.

tialaramex 7y ago

> All hashing algorithms have a shelf life before it becomes feasible to compromise them such that you need to migrate to something more secure. This is at best an unproven conjecture and more likely just plain wrong. Which doesn't make it any saner for Git to have chosen SHA-1 given its status at the time, (SHA-256 was the right choice then and remains a sound choice now) but it certainly isn't true that there's some cosmic law giving hashing algorithms a "shelf life" in this way.

tscheer 7y ago

Linus discussed this in: https://lore.kernel.org/lkml/Pine.LNX.4.58.0504090902170.1267@ppc970.osdl.org/ https://lore.kernel.org/lkml/Pine.LNX.4.58.0504090902170.126... The key point for me is his note that you have to more than copy the SHA1. That it will have to also be a valid zlib object with a matching header.