4 ms·

So wait, when is SHA-1 ever used for signing tags and commits in git? that's new to me.. My understanding was you're using a public key type of encryption such

So wait, when is SHA-1 ever used for signing tags and commits in git? that's new to me.. My understanding was you're using a public key type of encryption such as PGP at that point. I feel I may be missing the point here. (apologies if so)

zamalek 10y ago
My original statement is slightly incorrect; you can. The commit hash is probably used as part of the signature. It would have been better to sign the commit blob directly, as Git stores the length alongside the hash from that point down in the DAG (making prefix attacks impossible).
daurnimator 10y ago
I sign all my commits. Github even make it easy to see: https://github.com/blog/2144-gpg-signature-verification https://github.com/blog/2144-gpg-signature-verification And I also use it in a few places e.g. for http://hashbang.sh/ http://hashbang.sh/, we only allow signed commits into master However, as far as I know, when you sign a git commit you are actually sign the hash of the commit. With SHA-1 broken in the current way it essentially means someone with 110K to burn could forge a commit and reuse my PGP signature.
- moonshinefe 10y ago
  Well holy smokes. I don't know which repository you contribute to, but if you're getting undermined by such James Bond-esque deception by super villains, in addition to someone spending 6 figures into breaking your stuff, I'd hope you'd at least review the commits you sign with your key after glancing at it. In addition, you'd have to have everyone else not notice it, all the insanely cheaper exploits not been tried on your current setup, and all the other stars aligning...
  - moonshinefe 10y ago
    I'll also mention literally the first setup step to Git for most people: https://help.github.com/articles/set-up-git/ https://help.github.com/articles/set-up-git/ or similar. That might be a hint that Git isn't something which you should allow it to handle the security. Literally the first step to the entire thing: pick any email or name... Please provide reasonable security policies in your repos--and if someone is exploited, you've probably got far bigger problems than someone duplicating a sha-1. Not necessarily, but highly likely your system is owned.
- moonshinefe 10y ago
  Yes, if you sign off on commits you haven't reviewed to confirm the diffs at all, and they're carefully crafted files to make the collision, you may commit a duplicate sha-1, which still doesn't even break Git.
  - kzrdude 10y ago
    This is an important distinction. Without a preimage attack on sha-1, the only vulnerability is if some part (yet any part) of the git objects reachable from the signed tag or commit is one half of a prepared collision pair.
Perseids 10y ago
What you need to understand, is that Git's data structures are essentially annotated Merkle trees [1]. So whatever you sign, be it a tag or a commit, it will be nested sha1 hashes like [someData].sha1([someData].sha1([someData].[aFile]).[someData]).[someData] . And at every level you can conceivable construct a hash collision. So if e.g. you create your own commit on top of a commit of an attacker and sign your commit, you are only signing a (sha1 of a sha1 of a) sha1 of the commit of the attacker. If the attacker's commit was crafted to enable a sha1 collision somewhere, then your signed commit doesn't cover the files and commits you see, but only the sha1 hashes of those objects. This kind of hairy distinction of what a signature was supposed to mean and what it actually covers is what you get with (semi-)broken cryptographic primitives. It's awful and, frankly, unnecessary. [1] https://en.wikipedia.org/wiki/Merkle_tree https://en.wikipedia.org/wiki/Merkle_tree
- moonshinefe 10y ago
  I appreciate that info, +1. My main point was just if you're dealing with a repository where actors that have those 6 figures to spare to attack you (and that's a minority): 1) you've got to rely on a lot better security than the minimal if at all security provided by git (it assumes a web of trust). If people are signing off with PGP sigs but not watching diffs, you've got big problems. 2) You're probably far more likely to be exploited by far cheaper methods at this point. If they have access to a trusted contributor's keys, it's far more cost effective to slip in other tricks than sha-1 collisions right now. I'd say this is the main point so far, but admittedly maybe not in the future. 3) It sounds like Linus and the git devs have admitted they need to migrate from sha-1, but also I haven't seen any cheap, exploitable PoC for git yet based on this due to how they actually mix in other info instead of raw sha-1 hashes of the files. 4) As far as I know, and I'm sure I'm subject to correction, but there hasn't been a WebKit svn repo-esque calamity yet like what they've experienced dropping 2 sha-1 collision PDFs into the repo in a Git context yet. Again, I'm totally open to new info, but the sky-is-falling attitude right now is what I'm mainly arguing against.
  - 5ilv3r 10y ago
    If you drop two identical files into a linux repo then they will be rejected by the maintainers. You don't even need to get into a technical solution to prevent it.

zamalek 10y ago

My original statement is slightly incorrect; you can. The commit hash is probably used as part of the signature. It would have been better to sign the commit blob directly, as Git stores the length alongside the hash from that point down in the DAG (making prefix attacks impossible).

daurnimator 10y ago

I sign all my commits. Github even make it easy to see: https://github.com/blog/2144-gpg-signature-verification https://github.com/blog/2144-gpg-signature-verification And I also use it in a few places e.g. for http://hashbang.sh/ http://hashbang.sh/, we only allow signed commits into master However, as far as I know, when you sign a git commit you are actually sign the hash of the commit. With SHA-1 broken in the current way it essentially means someone with 110K to burn could forge a commit and reuse my PGP signature.

moonshinefe 10y ago
Well holy smokes. I don't know which repository you contribute to, but if you're getting undermined by such James Bond-esque deception by super villains, in addition to someone spending 6 figures into breaking your stuff, I'd hope you'd at least review the commits you sign with your key after glancing at it. In addition, you'd have to have everyone else not notice it, all the insanely cheaper exploits not been tried on your current setup, and all the other stars aligning...
- moonshinefe 10y ago
  I'll also mention literally the first setup step to Git for most people: https://help.github.com/articles/set-up-git/ https://help.github.com/articles/set-up-git/ or similar. That might be a hint that Git isn't something which you should allow it to handle the security. Literally the first step to the entire thing: pick any email or name... Please provide reasonable security policies in your repos--and if someone is exploited, you've probably got far bigger problems than someone duplicating a sha-1. Not necessarily, but highly likely your system is owned.
moonshinefe 10y ago
Yes, if you sign off on commits you haven't reviewed to confirm the diffs at all, and they're carefully crafted files to make the collision, you may commit a duplicate sha-1, which still doesn't even break Git.
- kzrdude 10y ago
  This is an important distinction. Without a preimage attack on sha-1, the only vulnerability is if some part (yet any part) of the git objects reachable from the signed tag or commit is one half of a prepared collision pair.

Perseids 10y ago

What you need to understand, is that Git's data structures are essentially annotated Merkle trees [1]. So whatever you sign, be it a tag or a commit, it will be nested sha1 hashes like [someData].sha1([someData].sha1([someData].[aFile]).[someData]).[someData] . And at every level you can conceivable construct a hash collision. So if e.g. you create your own commit on top of a commit of an attacker and sign your commit, you are only signing a (sha1 of a sha1 of a) sha1 of the commit of the attacker. If the attacker's commit was crafted to enable a sha1 collision somewhere, then your signed commit doesn't cover the files and commits you see, but only the sha1 hashes of those objects. This kind of hairy distinction of what a signature was supposed to mean and what it actually covers is what you get with (semi-)broken cryptographic primitives. It's awful and, frankly, unnecessary. [1] https://en.wikipedia.org/wiki/Merkle_tree https://en.wikipedia.org/wiki/Merkle_tree

moonshinefe 10y ago
I appreciate that info, +1. My main point was just if you're dealing with a repository where actors that have those 6 figures to spare to attack you (and that's a minority): 1) you've got to rely on a lot better security than the minimal if at all security provided by git (it assumes a web of trust). If people are signing off with PGP sigs but not watching diffs, you've got big problems. 2) You're probably far more likely to be exploited by far cheaper methods at this point. If they have access to a trusted contributor's keys, it's far more cost effective to slip in other tricks than sha-1 collisions right now. I'd say this is the main point so far, but admittedly maybe not in the future. 3) It sounds like Linus and the git devs have admitted they need to migrate from sha-1, but also I haven't seen any cheap, exploitable PoC for git yet based on this due to how they actually mix in other info instead of raw sha-1 hashes of the files. 4) As far as I know, and I'm sure I'm subject to correction, but there hasn't been a WebKit svn repo-esque calamity yet like what they've experienced dropping 2 sha-1 collision PDFs into the repo in a Git context yet. Again, I'm totally open to new info, but the sky-is-falling attitude right now is what I'm mainly arguing against.
- 5ilv3r 10y ago
  If you drop two identical files into a linux repo then they will be rejected by the maintainers. You don't even need to get into a technical solution to prevent it.