8 ms·

I decided to start signing all my commits as a matter of policy, since the cost to break SHA1 is now estimated at $75k. There are certainly git repos that it wo

by joeyh 11y ago

I decided to start signing all my commits as a matter of policy, since the cost to break SHA1 is now estimated at $75k. There are certainly git repos that it would be worth $75k to compromise, and a single birthday attack collision in SHA1 can be reused to compromise multiple git repositories (requires some social engineering). So I think that is a good policy now. Github could have a setting like "flag unsigned commits from me after $date" that allows this kind of policy to be communicated.

ryan-c 11y ago
Git's use of SHA1 is explicitly not intended to provide any security (per Linus), so this argument really doesn't make sense. On github, right now, I can commit as you all I want, no exploits required, and that seems like a much more pressing reason to sign commits. The other thing is that the SHA1 weaknesses are collisions. It's not likely to be possible in the foreseeable future to create a commit that matches an arbitrary hash - to generate colliding commits, the committer would need to generate the good and evil commit at the same time.
- joeyh 11y ago
  The existence of things that claim to have been committed as me, with no proof and not in the history of my master branch or a released tag, is irrelevant. My users use my release tags, and my master branch, they don't use random commits you make "as me" elsewhere. Before SHA1 is broken, you can't change things that I have committed, unless you have access to my account. If a SHA1 preimage attack becomes available, you can. If a SHA1 bithday attack becomes available (for the low low price of $75k, croudfund one today!), you can, by sending me some particularly evil forms of merge requests.
  - espadrine 11y ago
    > If a SHA1 preimage attack becomes available, you can. Actually, no. You need a SHA-1 second-preimage attack, which is vastly more difficult. However, even if there was one, it would cause git pull to fail, as downloading the objects would likely require terabytes of garbage data.
    - _asummers 11y ago
      What evidence do you have for the terabytes claim? Not saying you're incorrect, but I'm unfamiliar with any literature that suggests that.
      - cjbprime 11y ago
        If there is another input that SHAs to the same commit hash, it's not going to be as small, and it's not going to look like a standard patch. I'm not sure "terabytes" is justified either, but the point's a good one.
      - espadrine 11y ago
        Like I said, finding a SHA-1 second-preimage attack is vastly more difficult than finding a SHA-1 preimage attack. You can claim to have found one as soon as you have any means that is not brute-force which produces a colliding preimage, no matter how practical it is (ie, it could require the use of humanity's entire energy spending for a thousand years, and more disk space than can be built with the Earth's atoms). In theory, nothing I know forbids the possibility of finding an algorithm which yields a 160-bit solution within a few years. In practice, such an algorithm is tremendously more difficult (and potentially impossible) to find than simply finding a SHA-1 second-preimage attack, which is already vastly more difficult to find than a preimage attack, which is also vastly more difficult than getting a non-bruteforce collision. It would certainly be a phenomenal achievement, however. We still don't have a practical preimage attack on MD5, 10 years after the first actual collision found… Regardless, we're only now beating the first challenge after 20 years. It is likely to take more to go from there to a second-preimage attack, and more still to have it be a 160-bit solution within a practical amount of time. git will double its lifetime multiple times before then. Something shinier will have replaced it.
    - jepler 11y ago
      nah, "terabytes of garbage data" is unlikely to be required. Consider the case of taking the SHA1 of a message only 1024 bits (128) characters long (shorter than a tweet, let alone this reply). There are 2^1024 such messages, but only 2^160 hashes. So on average, there are 2^(1024-160) = 2^864 ~= 1.2x10^260 messages of length 1024 that must share each SHA1 hash. It would be a very interesting result if you could prove that you had some 1024-bit message that didn't share a SHA1 hash with any other message of length less than 1TB ~= 8x10^12 bits, and this property couldn't be true of very many 1024-bit messages, because this means you "take away" from the hash space of messages of length 1032 to length 8x10^12. If you took away just 2^140 out of the 2^160 hashes, for instance, we'd readily see hash collisions in those in-between sizes, because there would just be 2^20 hashes left. But even then, this special property you imagine would only apply to 1 in 2^884 ~= 1 in 1.2x10^254 of all 1024-bit messages so you'd have trouble finding one of them in the first place, and more to the point it's almost impossible that your victim would have selected one of these hashes that would require your hypothetical terabyte file to collide the SHA1 hash.
ikeboy 11y ago
If you sign the SHA1, how does that make you any more secure against collisions?
- jacques_chester 11y ago
  Because an attack will need both your signing key/certificate and a plausible collision text.
  - jessaustin 11y ago
    ISTM if an attacker had the former she wouldn't need the latter? That is she would produce the evil commit and its hash herself, and then sign that hash. I may be misunderstanding something?
  - minitech 11y ago
    No, just the header of the commit (i.e. just the SHA-1) is signed. The signature you used on the valid commit would work if tacked onto the malicious one.
    - jacques_chester 11y ago
      Gotcha.
JoshTriplett 11y ago
The main thing stopping me from doing the same is that I do my work on three different machines: my personal laptop, my work laptop, and a build server in a lab. Those represent three different trust levels. So I'd need to make two more GPG keys than I currently have, and handle key management, which at the moment doesn't yet seem worth the trouble. Apart from that, half the patches I prepare go out via git format-patch rather than a push and a pull request. So I'll need to confirm if the signature survives that workflow, and if it produces unwanted noise or other effects on development mailing lists.
- lotyrin 11y ago
  Signatures do survive, format-patch uses RFC 3676 (dashes) signature separator line, iirc., whichever, git apply-mail definitely understands them.
- diakritikal 11y ago
  A single offline key and three sub-keys would be easier to manage than three distinct private keys.
sleepyhead 11y ago
"Signing each commit is totally stupid." Linus Torvalds http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
- epistasis 11y ago
  That's a pretty unconvincing rant.
  - shopkins 11y ago
    How so?
    - epistasis 11y ago
      Once you strip away the insults, what's left appears to be: 1) It's unclear what we should sign on a commit, therefore we shouldn't. I'm not sure what to make of that. 2) Since a key may be revoked, any signatures should not go into the commit. Presumably Torvalds thinks that tags should be deletable, but commits should not, or something. 3) That if all commits are signed, then it become automated, and therefore somehow not worthwhile. Meanwhile, automated signing seems awesome because we know that at least the signer had possession of the key. I can't really extract much more logic out of that post, and none of it sways me in the slightest.
      - pdkl95 11y ago
        While I think that Linus is relying too much on SHA1[1], he makes several good points. His primary concern is the difference between adding signed content as part of the commit vs using "git tag -s"[2] which also signs the commit with GPG. The difference is that "git tag -s" includes the DAG metadata so the git history itself is verified. This isn't about using GPG siged vs nothing, it's "GPG signed in the commit" vs "GPG signed commit and metadata". The bit about revoking keys is also interesting. He's pointing out that if you keep the signature in the commit, you have permanently bound that particular signature with the commit data. It's mixing two different types of data into one storage location. The alternative is using tags, which shadow the main branch. This way you have the option of using those tags, or you can create new tags (with new signatures) with a new key. This gives flexibility for the future. > insults I don't see Linus insulting anyone in that post. Explaining the problems with a method is not an insult. > therefore we shouldn't Is that post really that hard to read? I find it obvious that he is saying you should use the builtin signing with "git tag -s". [1] It's worth observing that this is a comment from 2009; I'm curious if he has changed his opinion on SHA1 in over the last 6 years. [2] -s, --sign Make a GPG-signed tag, using the default e-mail address’s key
epistasis 11y ago
Note that signed commits only validate the commit file contents up to the SHA1 of the top level tree, it's not a GPG signature of the entire tree state. This means that a SHA1 collision on the tree object, or any blob object, still results in a valid GPG signature. So git GPG doesn't provide any additional security over SHA1; it only provides proof that a certain person signed a SHA1 and the commit message.
- emmelaich 11y ago
  I wonder who much it would be worth to sign the output of git ls-tree -r HEAD
- gpm 11y ago
  I was curious so I ran git in a debugger and found the buffer it is actually signing, it looks like this in case anyone else is wondering: "tree 33191145e9a307b7ca5c6e4aa6e74a4904426cba\nparent a2c6664cf085720cba3f92e4a7348c46369a869e\nauthor Greg Morenz <morenzg@gmail.com> 1459911016 -0400\ncommitter Greg Morenz <morenzg@gmail.com> 1459911016 -0400\n\nthe commit message\n"
- lmm 11y ago
  If you sign every commit then someone would have to find a collision for one object such that all subsequent commits that touch that object still made sense, no? Which would make an ongoing compromise harder.
ngoldbaum 11y ago
Is that $75k for a preimage attack? You would need to generate a collision that could be reasonably interpreted as a valid commit. It's my understanding that preimage attacks against SHA-1 are still considered to be impossible, even for a state actor.
zachrose 11y ago
Apologies for being completely off-topic, but reading this comment gave me a flashback to whenever it was when I started reading Hacker News. Try to imagine that you know nothing about version control or cryptography and then read the above comment. It's like someone is telling you that they always schnarkel their schnops with shaush, now that the cost of schnacking a schnill is a mere $75k. After however many days, I pretty much understand all of what joeyh is saying, except maybe for how the social engineering part would work. Thanks Hacker News.

by joeyh 11y ago

ryan-c 11y ago

Git's use of SHA1 is explicitly not intended to provide any security (per Linus), so this argument really doesn't make sense. On github, right now, I can commit as you all I want, no exploits required, and that seems like a much more pressing reason to sign commits. The other thing is that the SHA1 weaknesses are collisions. It's not likely to be possible in the foreseeable future to create a commit that matches an arbitrary hash - to generate colliding commits, the committer would need to generate the good and evil commit at the same time.

joeyh 11y ago
The existence of things that claim to have been committed as me, with no proof and not in the history of my master branch or a released tag, is irrelevant. My users use my release tags, and my master branch, they don't use random commits you make "as me" elsewhere. Before SHA1 is broken, you can't change things that I have committed, unless you have access to my account. If a SHA1 preimage attack becomes available, you can. If a SHA1 bithday attack becomes available (for the low low price of $75k, croudfund one today!), you can, by sending me some particularly evil forms of merge requests.
- espadrine 11y ago
  > If a SHA1 preimage attack becomes available, you can. Actually, no. You need a SHA-1 second-preimage attack, which is vastly more difficult. However, even if there was one, it would cause git pull to fail, as downloading the objects would likely require terabytes of garbage data.
  - _asummers 11y ago
    What evidence do you have for the terabytes claim? Not saying you're incorrect, but I'm unfamiliar with any literature that suggests that.
    - cjbprime 11y ago
      If there is another input that SHAs to the same commit hash, it's not going to be as small, and it's not going to look like a standard patch. I'm not sure "terabytes" is justified either, but the point's a good one.
    - espadrine 11y ago
      Like I said, finding a SHA-1 second-preimage attack is vastly more difficult than finding a SHA-1 preimage attack. You can claim to have found one as soon as you have any means that is not brute-force which produces a colliding preimage, no matter how practical it is (ie, it could require the use of humanity's entire energy spending for a thousand years, and more disk space than can be built with the Earth's atoms). In theory, nothing I know forbids the possibility of finding an algorithm which yields a 160-bit solution within a few years. In practice, such an algorithm is tremendously more difficult (and potentially impossible) to find than simply finding a SHA-1 second-preimage attack, which is already vastly more difficult to find than a preimage attack, which is also vastly more difficult than getting a non-bruteforce collision. It would certainly be a phenomenal achievement, however. We still don't have a practical preimage attack on MD5, 10 years after the first actual collision found… Regardless, we're only now beating the first challenge after 20 years. It is likely to take more to go from there to a second-preimage attack, and more still to have it be a 160-bit solution within a practical amount of time. git will double its lifetime multiple times before then. Something shinier will have replaced it.
  - jepler 11y ago
    nah, "terabytes of garbage data" is unlikely to be required. Consider the case of taking the SHA1 of a message only 1024 bits (128) characters long (shorter than a tweet, let alone this reply). There are 2^1024 such messages, but only 2^160 hashes. So on average, there are 2^(1024-160) = 2^864 ~= 1.2x10^260 messages of length 1024 that must share each SHA1 hash. It would be a very interesting result if you could prove that you had some 1024-bit message that didn't share a SHA1 hash with any other message of length less than 1TB ~= 8x10^12 bits, and this property couldn't be true of very many 1024-bit messages, because this means you "take away" from the hash space of messages of length 1032 to length 8x10^12. If you took away just 2^140 out of the 2^160 hashes, for instance, we'd readily see hash collisions in those in-between sizes, because there would just be 2^20 hashes left. But even then, this special property you imagine would only apply to 1 in 2^884 ~= 1 in 1.2x10^254 of all 1024-bit messages so you'd have trouble finding one of them in the first place, and more to the point it's almost impossible that your victim would have selected one of these hashes that would require your hypothetical terabyte file to collide the SHA1 hash.

ikeboy 11y ago

If you sign the SHA1, how does that make you any more secure against collisions?

jacques_chester 11y ago
Because an attack will need both your signing key/certificate and a plausible collision text.
- jessaustin 11y ago
  ISTM if an attacker had the former she wouldn't need the latter? That is she would produce the evil commit and its hash herself, and then sign that hash. I may be misunderstanding something?
- minitech 11y ago
  No, just the header of the commit (i.e. just the SHA-1) is signed. The signature you used on the valid commit would work if tacked onto the malicious one.
  - jacques_chester 11y ago
    Gotcha.

JoshTriplett 11y ago

The main thing stopping me from doing the same is that I do my work on three different machines: my personal laptop, my work laptop, and a build server in a lab. Those represent three different trust levels. So I'd need to make two more GPG keys than I currently have, and handle key management, which at the moment doesn't yet seem worth the trouble. Apart from that, half the patches I prepare go out via git format-patch rather than a push and a pull request. So I'll need to confirm if the signature survives that workflow, and if it produces unwanted noise or other effects on development mailing lists.

lotyrin 11y ago
Signatures do survive, format-patch uses RFC 3676 (dashes) signature separator line, iirc., whichever, git apply-mail definitely understands them.
diakritikal 11y ago
A single offline key and three sub-keys would be easier to manage than three distinct private keys.

sleepyhead 11y ago

"Signing each commit is totally stupid." Linus Torvalds http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

epistasis 11y ago
That's a pretty unconvincing rant.
- shopkins 11y ago
  How so?
  - epistasis 11y ago
    Once you strip away the insults, what's left appears to be: 1) It's unclear what we should sign on a commit, therefore we shouldn't. I'm not sure what to make of that. 2) Since a key may be revoked, any signatures should not go into the commit. Presumably Torvalds thinks that tags should be deletable, but commits should not, or something. 3) That if all commits are signed, then it become automated, and therefore somehow not worthwhile. Meanwhile, automated signing seems awesome because we know that at least the signer had possession of the key. I can't really extract much more logic out of that post, and none of it sways me in the slightest.
    - pdkl95 11y ago
      While I think that Linus is relying too much on SHA1[1], he makes several good points. His primary concern is the difference between adding signed content as part of the commit vs using "git tag -s"[2] which also signs the commit with GPG. The difference is that "git tag -s" includes the DAG metadata so the git history itself is verified. This isn't about using GPG siged vs nothing, it's "GPG signed in the commit" vs "GPG signed commit and metadata". The bit about revoking keys is also interesting. He's pointing out that if you keep the signature in the commit, you have permanently bound that particular signature with the commit data. It's mixing two different types of data into one storage location. The alternative is using tags, which shadow the main branch. This way you have the option of using those tags, or you can create new tags (with new signatures) with a new key. This gives flexibility for the future. > insults I don't see Linus insulting anyone in that post. Explaining the problems with a method is not an insult. > therefore we shouldn't Is that post really that hard to read? I find it obvious that he is saying you should use the builtin signing with "git tag -s". [1] It's worth observing that this is a comment from 2009; I'm curious if he has changed his opinion on SHA1 in over the last 6 years. [2] -s, --sign Make a GPG-signed tag, using the default e-mail address’s key

epistasis 11y ago

Note that signed commits only validate the commit file contents up to the SHA1 of the top level tree, it's not a GPG signature of the entire tree state. This means that a SHA1 collision on the tree object, or any blob object, still results in a valid GPG signature. So git GPG doesn't provide any additional security over SHA1; it only provides proof that a certain person signed a SHA1 and the commit message.

emmelaich 11y ago
I wonder who much it would be worth to sign the output of git ls-tree -r HEAD
gpm 11y ago
I was curious so I ran git in a debugger and found the buffer it is actually signing, it looks like this in case anyone else is wondering: "tree 33191145e9a307b7ca5c6e4aa6e74a4904426cba\nparent a2c6664cf085720cba3f92e4a7348c46369a869e\nauthor Greg Morenz <morenzg@gmail.com> 1459911016 -0400\ncommitter Greg Morenz <morenzg@gmail.com> 1459911016 -0400\n\nthe commit message\n"
lmm 11y ago
If you sign every commit then someone would have to find a collision for one object such that all subsequent commits that touch that object still made sense, no? Which would make an ongoing compromise harder.

ngoldbaum 11y ago

Is that $75k for a preimage attack? You would need to generate a collision that could be reasonably interpreted as a valid commit. It's my understanding that preimage attacks against SHA-1 are still considered to be impossible, even for a state actor.

zachrose 11y ago

Apologies for being completely off-topic, but reading this comment gave me a flashback to whenever it was when I started reading Hacker News. Try to imagine that you know nothing about version control or cryptography and then read the above comment. It's like someone is telling you that they always schnarkel their schnops with shaush, now that the cost of schnacking a schnill is a mere $75k. After however many days, I pretty much understand all of what joeyh is saying, except maybe for how the social engineering part would work. Thanks Hacker News.