4 ms·

I supposed you are advocating two distinct Merkle trees? Because otherwise the prefixes will change anyway. But the only reason this would be attractive is bec

by patrec 7y ago

I supposed you are advocating two distinct Merkle trees? Because otherwise the prefixes will change anyway. But the only reason this would be attractive is because then people could keep using the existing prefixes to refer to the whole commit. But of course doing this would be insecure. So for this to make any sense at all, people would need to make good choices on when to use an insecure prefix and when to use the whole hash, because it's security relevant. This seems a bit doubtful to me.

GlitchMr 7y ago
To be fair, the prefix problem would exist no matter what hash function would you pick. GitHub displays 7 characters of a hash, giving 28 bits. You could very quickly generate collisions with birthday attack in pretty much no time. Prefixes are always going to be insecure because they are so short. In fact, https://github.com/bradfitz/gitbrute https://github.com/bradfitz/gitbrute exists.
- patrec 7y ago
  Correct, but backwards compatibility does make a difference here, as in: there are surely quite a few cases where it would not be attractive to use a shortened hash if git hashes are changed incompatibly anyway, but where it will be attractive to use the shortened hash, because that keeps an existing setup working as before. Also: the prefixing increases the length of the hash (and hence the desire to shorten it) without adding any security.
  - GlitchMr 7y ago
    Yeah, kinda agreeing here. The hash length will need to be increased anyway, but concatenation of SHA1 and SHA256 will be 104 bytes in total when displayed (40 + 64), which is a lot. It may be a better to display SHA-256 commit hashes, but accept SHA-1 hash prefixes for old commits. It may be confusing for git to accept hashes that aren't visible in `git log`, but it's probably for the better.

4 ms·

I supposed you are advocating two distinct Merkle trees? Because otherwise the prefixes will change anyway. But the only reason this would be attractive is bec

by patrec 7y ago

GlitchMr 7y ago
To be fair, the prefix problem would exist no matter what hash function would you pick. GitHub displays 7 characters of a hash, giving 28 bits. You could very quickly generate collisions with birthday attack in pretty much no time. Prefixes are always going to be insecure because they are so short. In fact, https://github.com/bradfitz/gitbrute https://github.com/bradfitz/gitbrute exists.
- patrec 7y ago
  Correct, but backwards compatibility does make a difference here, as in: there are surely quite a few cases where it would not be attractive to use a shortened hash if git hashes are changed incompatibly anyway, but where it will be attractive to use the shortened hash, because that keeps an existing setup working as before. Also: the prefixing increases the length of the hash (and hence the desire to shorten it) without adding any security.
  - GlitchMr 7y ago
    Yeah, kinda agreeing here. The hash length will need to be increased anyway, but concatenation of SHA1 and SHA256 will be 104 bytes in total when displayed (40 + 64), which is a lot. It may be a better to display SHA-256 commit hashes, but accept SHA-1 hash prefixes for old commits. It may be confusing for git to accept hashes that aren't visible in `git log`, but it's probably for the better.