3 ms·

For most cases that would suffice and would be ergonomic, but what if a full SHA1 also qualifies as a prefix of one or more SHA256, and you want the SHA1? There

by jolmg 7y ago

For most cases that would suffice and would be ergonomic, but what if a full SHA1 also qualifies as a prefix of one or more SHA256, and you want the SHA1? There's still a need for a mechanism to disambiguate for these cases, even if it ends up very rarely needed.

loeg 7y ago
You're talking about a 160 bit truncated hash collision on SHA256, which is extraordinarily unlikely if SHA256 is not itself completely broken (moreso than SHA1 already is!). I don't think any syntax is needed for that in the porcelain CLI; it could be handled with non-user-facing commands if it ever came up (it won't).
- jolmg 7y ago
  > extraordinarily unlikely if SHA256 is not itself completely broken (moreso than SHA1 already is I was hoping I captured that by saying "very rarely". However, if SHA1 collisions can be made willingly, doesn't that mean that one can also willingly make a SHA1 hash that matches with the prefix of an existing SHA256 hash?
  - loeg 7y ago
    As far as I know, that kind of collision isn't practical at this time. So predicating UI decisions on that basis seems like a mistake to me (given how long git has already ignored the looming threat of SHA1 being broken). When and if someone injects a SHA1 attack into your repository, and the main git CLI throws up its hands and says "hash collision" trying to access it, I'm not seeing major problems here. The git CLI doesn't need to provide convenient commands to interact with attacks that are not practical today. To the extent that these will become practical, I think git should drop the SHA1 lookup after a migration period regardless, and it would not hurt to provide a gitconfig knob to disable SHA1 lookup.
  - minitech 7y ago
    > doesn't that mean that one can also willingly make a SHA1 hash that matches with the prefix of an existing SHA256 hash? No, the “prefix of an existing SHA256 hash” stops being relevant at that point – that’s just a full preimage attack on SHA1. Isn’t known to be feasible yet. > I was hoping I captured that by saying "very rarely" It’s rarer than that. :)

by jolmg 7y ago

loeg 7y ago

You're talking about a 160 bit truncated hash collision on SHA256, which is extraordinarily unlikely if SHA256 is not itself completely broken (moreso than SHA1 already is!). I don't think any syntax is needed for that in the porcelain CLI; it could be handled with non-user-facing commands if it ever came up (it won't).

jolmg 7y ago
> extraordinarily unlikely if SHA256 is not itself completely broken (moreso than SHA1 already is I was hoping I captured that by saying "very rarely". However, if SHA1 collisions can be made willingly, doesn't that mean that one can also willingly make a SHA1 hash that matches with the prefix of an existing SHA256 hash?
- loeg 7y ago
  As far as I know, that kind of collision isn't practical at this time. So predicating UI decisions on that basis seems like a mistake to me (given how long git has already ignored the looming threat of SHA1 being broken). When and if someone injects a SHA1 attack into your repository, and the main git CLI throws up its hands and says "hash collision" trying to access it, I'm not seeing major problems here. The git CLI doesn't need to provide convenient commands to interact with attacks that are not practical today. To the extent that these will become practical, I think git should drop the SHA1 lookup after a migration period regardless, and it would not hurt to provide a gitconfig knob to disable SHA1 lookup.
- minitech 7y ago
  > doesn't that mean that one can also willingly make a SHA1 hash that matches with the prefix of an existing SHA256 hash? No, the “prefix of an existing SHA256 hash” stops being relevant at that point – that’s just a full preimage attack on SHA1. Isn’t known to be feasible yet. > I was hoping I captured that by saying "very rarely" It’s rarer than that. :)