3 ms·

It's pretty much the same thing as detecting unintentional changes - very important distinction! Something like CRC32 might catch some 99.999% of the cases of

It's pretty much the same thing as detecting unintentional changes - very important distinction! Something like CRC32 might catch some 99.999% of the cases of unintentional corruption. But you could probably figure out how to generate a collision using pen and paper, without being a cryptography expert of any sort, in which case CRC32 will only catch the cases where you forget to carry a one! EDIT: SHA1's naturally a bit tougher to beat than CRC32, but there's plenty of whitespace and comments and identifiers to rename without affecting the execution of a program. Your typical binary format will have plenty of uninitialized padding bytes to tweak as well. Plenty of room to change unimportant data to generate a collision.

ams6110 13y ago
OK, so I think "a bit tougher" is an understatement to say the least. If they're really worried, compare file sizes too. Then compile the code and verify that the checksum on the executable is the same as before. I just think it would be really hard to pull this off, maybe the NSA could do it but they wouldn't have tipped their hand by defacing the site too.
- MaulingMonkey 13y ago
  > OK, so I think "a bit tougher" is an understatement to say the least. Sure. But the point is that a detecting corruption is a far different beast than detecting intentional collision attempts. > If they're really worried, compare file sizes too. This adds nearly no security. > Then compile the code and verify that the checksum on the executable is the same as before. Compare the whole binary! If you don't trust a SHA1 on the source, trusting a SHA1 on the binary is merely moving the goalposts around. This also requires deterministic builds - this isn't the default or necessairly easy, but it's possible and is the approach the TOR project takes at least: https://blog.torproject.org/category/tags/deterministic-builds https://blog.torproject.org/category/tags/deterministic-buil... Alternatively, even without deterministic builds, compare the whole source tree! The whole file must be read to compute the hash in the first place, so why not compare all those bytes? > I just think it would be really hard to pull this off And while I would agree with you on that point, the point I'm trying to make is simply that this has absolutely nothing to do with the fact that git attempts to detect accidental corruption -- the specifics are paramount! While SHA1 is not the weakest cryptographic hash, it is not the strongest cryptographic hash either. Git was not designed to focus on cryptographic security, and it was written by a programmer who is not a cryptographic security expert. I would also stress that "really hard" is quite different from "impossible" (an in the general case, quite different from even "unlikely".) (That said, sneaking in a benign-looking backdoor through standard channels sounds way easier.)
klodolph 13y ago
> SHA1's naturally a bit tougher to beat than CRC32... That's like saying that bank vaults are tougher to break into than cardboard boxes. Bank vaults are actively guarded and designed to prevent unauthorized access, cardboard boxes are just for organizing your junk and can't even keep a small child out. Making a CRC32 collision is easy if you try. You just have to solve a mathematical equation in a small, well-understood finite ring. By comparison, SHA1 does not have a simple equation. It was purposefully designed to be difficult to solve. NOBODY has yet found two different pieces of data with the same SHA1 hash, or if they have they have kept it secret.

ams6110 13y ago

OK, so I think "a bit tougher" is an understatement to say the least. If they're really worried, compare file sizes too. Then compile the code and verify that the checksum on the executable is the same as before. I just think it would be really hard to pull this off, maybe the NSA could do it but they wouldn't have tipped their hand by defacing the site too.

MaulingMonkey 13y ago
> OK, so I think "a bit tougher" is an understatement to say the least. Sure. But the point is that a detecting corruption is a far different beast than detecting intentional collision attempts. > If they're really worried, compare file sizes too. This adds nearly no security. > Then compile the code and verify that the checksum on the executable is the same as before. Compare the whole binary! If you don't trust a SHA1 on the source, trusting a SHA1 on the binary is merely moving the goalposts around. This also requires deterministic builds - this isn't the default or necessairly easy, but it's possible and is the approach the TOR project takes at least: https://blog.torproject.org/category/tags/deterministic-builds https://blog.torproject.org/category/tags/deterministic-buil... Alternatively, even without deterministic builds, compare the whole source tree! The whole file must be read to compute the hash in the first place, so why not compare all those bytes? > I just think it would be really hard to pull this off And while I would agree with you on that point, the point I'm trying to make is simply that this has absolutely nothing to do with the fact that git attempts to detect accidental corruption -- the specifics are paramount! While SHA1 is not the weakest cryptographic hash, it is not the strongest cryptographic hash either. Git was not designed to focus on cryptographic security, and it was written by a programmer who is not a cryptographic security expert. I would also stress that "really hard" is quite different from "impossible" (an in the general case, quite different from even "unlikely".) (That said, sneaking in a benign-looking backdoor through standard channels sounds way easier.)

klodolph 13y ago

> SHA1's naturally a bit tougher to beat than CRC32... That's like saying that bank vaults are tougher to break into than cardboard boxes. Bank vaults are actively guarded and designed to prevent unauthorized access, cardboard boxes are just for organizing your junk and can't even keep a small child out. Making a CRC32 collision is easy if you try. You just have to solve a mathematical equation in a small, well-understood finite ring. By comparison, SHA1 does not have a simple equation. It was purposefully designed to be difficult to solve. NOBODY has yet found two different pieces of data with the same SHA1 hash, or if they have they have kept it secret.