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 fe

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.