4 ms·

Is it used to sign a commit, right ? Which are the probabilities to have a collision that: a) is still code b) is still code AND is code similar to a previous

Is it used to sign a commit, right ? Which are the probabilities to have a collision that: a) is still code b) is still code AND is code similar to a previous commit c) is still code AND is code similar to a previous commit AND is valid d) is still code AND is code similar to a previous commit AND is valid AND makes sense for something OR at least a) is still code b) is still code AND is valid d) is still code AND is valid AND makes sense for something Let me know.

chasil 3y ago
Doesn't it also have to be the same size in bytes?
- deleted 3y ago
  [deleted]
dist-epoch 3y ago
Due to the way hashing works, any change is equivalent to any other one for the purpose of finding a collision. So you can just alter the formatting to a different convention, alter spacing, add a comment, reorder equivalent lines. So you can insert a comment and continue altering it until you get a match by varying the line breaking, switching words with synonyms.
keybored 3y ago
I believe there is one more step. You have to somehow get the collision into the repository. Because if you have <hash> in your own repo and pull something from another repo with the same <hash>, the remote changes will not overwrite your blob for <hash> (it will stay the same). Or at least that’s what I seem to remember from something that Torvalds wrote.
- hn_p4ttern 3y ago
  > "I believe there is one more step. You have to somehow get the collision into the repository." Yes, Exactly. So, is it necessary to change SHA-1 having in git ? At the moment, I think there is no reason because SHA-1 doesn't expose security vulnerabilities or functional issues.
IncreasePosts 3y ago
Brave of you to assume I'm committing valid and sensical code to git
Rygian 3y ago
For the choices after your "OR at least" line, just consider that most of the collision material could be padded into a comment, so achieving a), b) and d) would be "trivial."
- hn_p4ttern 3y ago
  IMHO "be padded into a comment" is included in "is valid code", still 1 in <number_of_particles_in_universe_here^1E100> is a good approximation of that probability. Please, correct me if I'm wrong.
  - Rygian 3y ago
    That's what I meant.
  - maxcoder4 3y ago
    Do you mean with the current public knowledge or hypothetically? For md5 all of these are doable right now (except maybe code that "makes sense"for human reader). Also in practice it's much easier to do this with a data file, as demonstrated for SHA1 with a "backdoored" certificate.
    - hn_p4ttern 3y ago
      1) We are talking about sha1, md5 is out of topic 2) This is the main topic ! Being able to generate >>valid code<< with a >>specific purpose<< , so that GIT have to change its hashing algorithm; 3) A.K.A your answer is total nonsense. Everyone else, ok, I'm listening, give proof that you can change code on GitHub stealthy messing with hashing, moreover inserting a "payload" creating a SHA-1 collision in a reasonable computational time, everything else is BS.
      - maxcoder4 3y ago
        1) yes, I gave you an example of a hash algorithm that is broken right now. SHA1 is only getting there, because the attacks are always only getting stronger. Responsible people don't wait until the attacks are practical and devastating, but instead react by predicting the obvious things that will happen in the future. Overall I don't think you're arguing in good faith, so I'm going to walk away from this discussion.
jacobgorm 3y ago
It is used to name a a commit, not to sign it. So the data structure itself will be corrupted if there is a collision, as it relies on the invariant that each commit has a unique name. And the collision has to happen within a single repo.
- cyph3r0 3y ago
  > It is used to name a a commit, not to sign it. This is bullshit. Really. If you have only to "name a a commit" you can use a sequence from 0 to N. Why someone should waste computation power to calculate an hash that's also a naming system really not user friendly? Think about it. The correct answer is to signing the commit AND for database indexing: "Git uses hashes in two important ways. When you commit a file into your repository, Git calculates and remembers the hash of the contents of the file. When you later retrieve the file, Git can verify that the hash of the data being retrieved exactly matches the hash that was computed when it was stored. In this fashion, the hash serves as an integrity checksum, ensuring that the data has not been corrupted or altered. For example, if somebody were to hack the DVCS repository such that the contents of file2.txt were changed to “Fred”, retrieval of that file would cause an error because the software would detect that the SHA-1 digest for “Fred” is not 63ae94dae606… Git also uses hash digests as database keys for looking up files and data. If you ask Git for the contents of file2.txt, it will first look up its previously computed digest for the contents of that file[45], which is 63ae94dae606… Then it looks in the repository for the data associated with that value and returns “Erik” as the result. (For the moment, you should try to ignore the fact that we just used a 40 character hex string as the database key for four characters of data.)" Source: https://ericsink.com/vcbe/html/cryptographic_hashes.html#:~:text=Git%20uses%20hashes%20in%20two,computed%20when%20it%20was%20stored https://ericsink.com/vcbe/html/cryptographic_hashes.html#:~:.... ~
  - jacobgorm 2y ago
    Earlier systems like perforce used the totally ordered integer naming scheme you describe, but it requires a centralized entity to keep the names globally unique. Using hashes for naming avoids this, and the way they are used in git imposes a partial order.
pornel 3y ago
For now the SHA-1 collisions are easily detectable, but it could get worse. In case of MD5, there is now a collision I wouldn't expect was possible: in readable ASCII. https://mastodon.social/@Ange/112124123552605003 https://mastodon.social/@Ange/112124123552605003
- hn_p4ttern 3y ago
  > "For now the SHA-1 collisions are easily detectable, but it could get worse." Your opinion: prove it! And Again, if you instead of trolling actually read the post in THIS BRANCH , the question is: shout SHA-1 inn GIT be substituted ?

chasil 3y ago

Doesn't it also have to be the same size in bytes?

deleted 3y ago
[deleted]

dist-epoch 3y ago

Due to the way hashing works, any change is equivalent to any other one for the purpose of finding a collision. So you can just alter the formatting to a different convention, alter spacing, add a comment, reorder equivalent lines. So you can insert a comment and continue altering it until you get a match by varying the line breaking, switching words with synonyms.

keybored 3y ago

I believe there is one more step. You have to somehow get the collision into the repository. Because if you have <hash> in your own repo and pull something from another repo with the same <hash>, the remote changes will not overwrite your blob for <hash> (it will stay the same). Or at least that’s what I seem to remember from something that Torvalds wrote.

hn_p4ttern 3y ago
> "I believe there is one more step. You have to somehow get the collision into the repository." Yes, Exactly. So, is it necessary to change SHA-1 having in git ? At the moment, I think there is no reason because SHA-1 doesn't expose security vulnerabilities or functional issues.

IncreasePosts 3y ago

Brave of you to assume I'm committing valid and sensical code to git

Rygian 3y ago

For the choices after your "OR at least" line, just consider that most of the collision material could be padded into a comment, so achieving a), b) and d) would be "trivial."

hn_p4ttern 3y ago
IMHO "be padded into a comment" is included in "is valid code", still 1 in <number_of_particles_in_universe_here^1E100> is a good approximation of that probability. Please, correct me if I'm wrong.
- Rygian 3y ago
  That's what I meant.
- maxcoder4 3y ago
  Do you mean with the current public knowledge or hypothetically? For md5 all of these are doable right now (except maybe code that "makes sense"for human reader). Also in practice it's much easier to do this with a data file, as demonstrated for SHA1 with a "backdoored" certificate.
  - hn_p4ttern 3y ago
    1) We are talking about sha1, md5 is out of topic 2) This is the main topic ! Being able to generate >>valid code<< with a >>specific purpose<< , so that GIT have to change its hashing algorithm; 3) A.K.A your answer is total nonsense. Everyone else, ok, I'm listening, give proof that you can change code on GitHub stealthy messing with hashing, moreover inserting a "payload" creating a SHA-1 collision in a reasonable computational time, everything else is BS.
    - maxcoder4 3y ago
      1) yes, I gave you an example of a hash algorithm that is broken right now. SHA1 is only getting there, because the attacks are always only getting stronger. Responsible people don't wait until the attacks are practical and devastating, but instead react by predicting the obvious things that will happen in the future. Overall I don't think you're arguing in good faith, so I'm going to walk away from this discussion.

jacobgorm 3y ago

It is used to name a a commit, not to sign it. So the data structure itself will be corrupted if there is a collision, as it relies on the invariant that each commit has a unique name. And the collision has to happen within a single repo.

cyph3r0 3y ago
> It is used to name a a commit, not to sign it. This is bullshit. Really. If you have only to "name a a commit" you can use a sequence from 0 to N. Why someone should waste computation power to calculate an hash that's also a naming system really not user friendly? Think about it. The correct answer is to signing the commit AND for database indexing: "Git uses hashes in two important ways. When you commit a file into your repository, Git calculates and remembers the hash of the contents of the file. When you later retrieve the file, Git can verify that the hash of the data being retrieved exactly matches the hash that was computed when it was stored. In this fashion, the hash serves as an integrity checksum, ensuring that the data has not been corrupted or altered. For example, if somebody were to hack the DVCS repository such that the contents of file2.txt were changed to “Fred”, retrieval of that file would cause an error because the software would detect that the SHA-1 digest for “Fred” is not 63ae94dae606… Git also uses hash digests as database keys for looking up files and data. If you ask Git for the contents of file2.txt, it will first look up its previously computed digest for the contents of that file[45], which is 63ae94dae606… Then it looks in the repository for the data associated with that value and returns “Erik” as the result. (For the moment, you should try to ignore the fact that we just used a 40 character hex string as the database key for four characters of data.)" Source: https://ericsink.com/vcbe/html/cryptographic_hashes.html#:~:text=Git%20uses%20hashes%20in%20two,computed%20when%20it%20was%20stored https://ericsink.com/vcbe/html/cryptographic_hashes.html#:~:.... ~
- jacobgorm 2y ago
  Earlier systems like perforce used the totally ordered integer naming scheme you describe, but it requires a centralized entity to keep the names globally unique. Using hashes for naming avoids this, and the way they are used in git imposes a partial order.

pornel 3y ago

For now the SHA-1 collisions are easily detectable, but it could get worse. In case of MD5, there is now a collision I wouldn't expect was possible: in readable ASCII. https://mastodon.social/@Ange/112124123552605003 https://mastodon.social/@Ange/112124123552605003

hn_p4ttern 3y ago
> "For now the SHA-1 collisions are easily detectable, but it could get worse." Your opinion: prove it! And Again, if you instead of trolling actually read the post in THIS BRANCH , the question is: shout SHA-1 inn GIT be substituted ?