4 ms·

I'm curious to hear people's thoughts about git. Git is "crypto" to some extent, Linus does not appear to have tons of crypto expertise, and it uses SHA1 as a

I'm curious to hear people's thoughts about git. Git is "crypto" to some extent, Linus does not appear to have tons of crypto expertise, and it uses SHA1 as a MAC AFAICT (which according to tptacek's earlier comment is invalid). And yet I've never heard about attacks on its crypto. This was interesting for me to think about because it seems like a counterpoint to the article, in that it is a very successful project that came about in a very "quick and dirty" way as opposed to starting with formal protocol design. -- I see that Linus disclaims the idea that SHA1 is about security: "Git uses SHA-1 in a way which has nothing at all to do with security.... It's just the best hash you can get.... It's about the ability to trust your data. I guarantee you, if you put your data in Git, you can trust the fact that five years later, after it was converted from a hard disk to a DVD to whatever new technology and you copied it, five years later you can verify that the data that you get back out is the exact same data you put in." But it seems like avoiding attacks like this must also be a goal: http://lkml.indiana.edu/hypermail/linux/kernel/0311.0/0621.html http://lkml.indiana.edu/hypermail/linux/kernel/0311.0/0621.h...

alinajaf 13y ago
AFAIK the only "crypto" in git is GPG used to sign tags. The content addressable data store where all the objects are kept is basically a filesystem where every filename is the SHA1 of its contents. If you were to generate an object that was a SHA1 collision of an existing object and inject it via a commit (without access to filesystem, otherwise the point is sort of moot) then git won't overwrite the original object with that SHA1[1]. Maybe there's some other mechanism in Git that you're referring to that uses SHA1 as a MAC that I'm perhaps unaware of? [1]: http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob http://stackoverflow.com/questions/9392365/how-would-git-han...
- haberman 13y ago
  Git assumes that a matching SHA1 means that the content is equal to the original content. Is that not crypto? For example, if you sign a tag, it appears to sign the SHA1 of the associated content. This is definitely outside of my expertise, so I'm sure that my understanding is incomplete. The larger questions for me are: - if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from software like git that uses cryptographic primitives for useful purposes? - is a project like git a safe/sane thing for a non-cryptographer to design and implement? If so, why do all the warnings in this article not apply?
  - Nursie 13y ago
    SHA1 is a hash. That alone does not make it 'crypto'. It's just a hash. It happens to be a hash with fairly good collision resistance. Maybe not the best we have for modern crypto purposes, but that's not what it's being used for. It's being used to check and record unique tags for patches (as far as I know, my git knowledge is far from complete). Cryptography does concern itself with data integrity but the reverse does not have to be true if you're not talking about part of a system you care about mitigating attacks on. That's my take anyway. --Edit-- for completeness I should add that SHA1 by itself is absolutely not a MAC
  - alinajaf 13y ago
    I'm not a cryptography expert either, but I'll give this a crack... In as much as SHA1 is a "cryptographic hash function", Linus isn't taking advantage of a few of it's cryptographic properties in his usage of it in git. It would for example, make no difference to the workings of git if you could reverse-engineer the contents of an object from its SHA1. In the same way, it doesn't matter much to the operation of git that you can generate collisions for SHA1, though if you were running into collisions all the time, it would make everyday usage difficult. > if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from software like git that uses cryptographic primitives for useful purposes? If I'm understanding you correctly, software that "uses cryptographic primitives for useful purposes" is usually trying to guarantee one or more of the following: * Confidentiality - Keeping data secret * Integrity - Making sure data hasn't been tampered with * Authentication - Making sure that the person you think sent the data is in fact the person who sent the data. * Non-repudiation - Ensuring that the person who sent the data can't deny that they in fact sent the data. Git makes guarantees about none of the above in its usage of SHA1. You could argue that it makes a guarantee of integrity in its content addressable file store, but it doesn't. If you can modify the files in the .git/ directory, you can screw up the repository to your hearts content. There's no way to do so remotely, i.e. by creating and pushing a Git commit with an existing SHA1. You typically protect Git from local tampering by only allowing access via SSH, which has plenty of crypto in it. When it does make guarantees about authentication (signing tags) it uses GPG more or less off the shelf. In that case the SHA1 is a reference to a commit object, and you're saying that "I, Najaf Ali, sign off on the commit with this SHA1". It doesn't guarantee anything about the contents of that commit if the repository has been tampered with. > is a project like git a safe/sane thing for a non-cryptographer to design and implement? If so, why do all the warnings in this article not apply? See above on git not making the guarantees that software that "uses cryptographic primitives for useful purposes" tend to make. Since Git makes none of those guarantees, it's (I think) a safe/sane thing for a non-cryptographer to design and implement. In practice, what Linus has done has let other off-the-shelf crypto (SSH and GPG) make the required guarantees for him.
- rcxdude 13y ago
  git's SHA1 is useful in one sense cryptographically: If you have a sha1 hash, then it represents the entire state of the repository and its history, so if you have a copy of the hash you can verify that any given copy of the repo has not been tampered with (but a way to generate collisions would subvert this). This has been used in a few cases when repository servers have been broken into (and a similar feature in bitkeeper allowed the detection of an attempted backdoor insertion in linux).
josephlord 13y ago
You can use hashes for security but you can also use them in non-security critical systems to get a unique (with a very high probability) number for use as an ID. Git uses them for this I believe. Attacks like mentioned can be prevented by a number of mechanisms and checks for changes. If a hash being secure helps that is great but that isn't why git uses hashes. Or by separately signing commits. git does use crypto but reuses existing crypto (https and ssl to communicate between repos and someone mentions you can use GPG to sign commits) rather than developing it's own secure protocol.
eliteraspberrie 13y ago
A Git commit history is a Merkle tree. The hash is not used for authentication.

alinajaf 13y ago

AFAIK the only "crypto" in git is GPG used to sign tags. The content addressable data store where all the objects are kept is basically a filesystem where every filename is the SHA1 of its contents. If you were to generate an object that was a SHA1 collision of an existing object and inject it via a commit (without access to filesystem, otherwise the point is sort of moot) then git won't overwrite the original object with that SHA1[1]. Maybe there's some other mechanism in Git that you're referring to that uses SHA1 as a MAC that I'm perhaps unaware of? [1]: http://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob http://stackoverflow.com/questions/9392365/how-would-git-han...

haberman 13y ago
Git assumes that a matching SHA1 means that the content is equal to the original content. Is that not crypto? For example, if you sign a tag, it appears to sign the SHA1 of the associated content. This is definitely outside of my expertise, so I'm sure that my understanding is incomplete. The larger questions for me are: - if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from software like git that uses cryptographic primitives for useful purposes? - is a project like git a safe/sane thing for a non-cryptographer to design and implement? If so, why do all the warnings in this article not apply?
- Nursie 13y ago
  SHA1 is a hash. That alone does not make it 'crypto'. It's just a hash. It happens to be a hash with fairly good collision resistance. Maybe not the best we have for modern crypto purposes, but that's not what it's being used for. It's being used to check and record unique tags for patches (as far as I know, my git knowledge is far from complete). Cryptography does concern itself with data integrity but the reverse does not have to be true if you're not talking about part of a system you care about mitigating attacks on. That's my take anyway. --Edit-- for completeness I should add that SHA1 by itself is absolutely not a MAC
- alinajaf 13y ago
  I'm not a cryptography expert either, but I'll give this a crack... In as much as SHA1 is a "cryptographic hash function", Linus isn't taking advantage of a few of it's cryptographic properties in his usage of it in git. It would for example, make no difference to the workings of git if you could reverse-engineer the contents of an object from its SHA1. In the same way, it doesn't matter much to the operation of git that you can generate collisions for SHA1, though if you were running into collisions all the time, it would make everyday usage difficult. > if git's SHA1 content-addressable design is not crypto, how do you distinguish crypto from software like git that uses cryptographic primitives for useful purposes? If I'm understanding you correctly, software that "uses cryptographic primitives for useful purposes" is usually trying to guarantee one or more of the following: * Confidentiality - Keeping data secret * Integrity - Making sure data hasn't been tampered with * Authentication - Making sure that the person you think sent the data is in fact the person who sent the data. * Non-repudiation - Ensuring that the person who sent the data can't deny that they in fact sent the data. Git makes guarantees about none of the above in its usage of SHA1. You could argue that it makes a guarantee of integrity in its content addressable file store, but it doesn't. If you can modify the files in the .git/ directory, you can screw up the repository to your hearts content. There's no way to do so remotely, i.e. by creating and pushing a Git commit with an existing SHA1. You typically protect Git from local tampering by only allowing access via SSH, which has plenty of crypto in it. When it does make guarantees about authentication (signing tags) it uses GPG more or less off the shelf. In that case the SHA1 is a reference to a commit object, and you're saying that "I, Najaf Ali, sign off on the commit with this SHA1". It doesn't guarantee anything about the contents of that commit if the repository has been tampered with. > is a project like git a safe/sane thing for a non-cryptographer to design and implement? If so, why do all the warnings in this article not apply? See above on git not making the guarantees that software that "uses cryptographic primitives for useful purposes" tend to make. Since Git makes none of those guarantees, it's (I think) a safe/sane thing for a non-cryptographer to design and implement. In practice, what Linus has done has let other off-the-shelf crypto (SSH and GPG) make the required guarantees for him.
rcxdude 13y ago
git's SHA1 is useful in one sense cryptographically: If you have a sha1 hash, then it represents the entire state of the repository and its history, so if you have a copy of the hash you can verify that any given copy of the repo has not been tampered with (but a way to generate collisions would subvert this). This has been used in a few cases when repository servers have been broken into (and a similar feature in bitkeeper allowed the detection of an attempted backdoor insertion in linux).

josephlord 13y ago

You can use hashes for security but you can also use them in non-security critical systems to get a unique (with a very high probability) number for use as an ID. Git uses them for this I believe. Attacks like mentioned can be prevented by a number of mechanisms and checks for changes. If a hash being secure helps that is great but that isn't why git uses hashes. Or by separately signing commits. git does use crypto but reuses existing crypto (https and ssl to communicate between repos and someone mentions you can use GPG to sign commits) rather than developing it's own secure protocol.

eliteraspberrie 13y ago

A Git commit history is a Merkle tree. The hash is not used for authentication.