related posts
277 sats \ 0 replies \ @Brunswick 27 Oct 2022
SHA256 has been the world standard for secure hashes for quite a long time. its the backbone almost all secure internet encryption systems such as TLS, SSL, PGP, SSH, IPsec, and S/MIME
About 3 years ago, a research group announced they had found a way to produce a SHA256 collision under controlled circumstances this is another way of saying the algorithm has been 'cracked'. Within a day they backtracked and said it was an incorrect conclusion from using faulty equipment. You'll have to believe what you want to believe in this case.
Here are a couple pages to start learning more about how SHA256 works
- https://sectigostore.com/blog/sha-256-algorithm-explained-by-a-cyber-security-consultant/
- https://www.simplilearn.com/tutorials/cyber-security-tutorial/sha-256-algorithm
- https://sha256algorithm.com/
reply
267 sats \ 1 reply \ @godlikeXi 27 Oct 2022
Everything is breakable. Eventually. Everything.
reply
0 sats \ 0 replies \ @8 OP 27 Oct 2022
Flexible says "Hold my beer"
reply
258 sats \ 3 replies \ @l0k1 27 Oct 2022
SHA1 was "broken" but its still secure enough for Git. Not sure why they haven't upgraded it anyway. "Broken" cryptographic hash function essentially means a downgrade to simple digest checksum function. This is partly why Git didn't upgrade yet. The signatures are SHA256 based PGP, RSA/DSA or EC.
reply
0 sats \ 2 replies \ @Brunswick 27 Oct 2022
It's an obvious critique of git to wonder why SHA1 was chosen over a seemingly free alternative that offers more guarantees.
Git uses SHA1 because it doesen't need a universally secure hash for it to work. What git is after is a "unique id" based on the content and within the key space. SHA1's shorter length is preferable because the guarantee isn't required for the design, and because occasionally it needs to be copied around by hand and compared visually.
After handling git for a while, you will notice the convention used to identify hashes within a project is a truncated hash. This is because the full hash can be implied by only a fraction of its content, this because of the very limited scope of the hash. The hash only refers to the state of a particular source code repository, and the repo has a practical key space requirement of only around 100 to 10,000,000 waypoints, not even close to 2^32. Therefore a collision of git identifiers is acceptable across different contexts.
The secure aspect of git is done with pgp git revision signing which is a completely different toolset. Here uniqueness must be guaranteed universally and something more secure like sha256 can be stored in the signing data where key size doesen't effect usability.
reply
0 sats \ 1 reply \ @Brunswick 27 Oct 2022
There is actually a push away from sha1 on security grounds, but as you can see Linus is trying to avoid it.
Again, git hashes arent global uniqueness guarantees and this is the purpose of commit signing.
Here it is shown that git signing will generate a secure signature based on the entire contents of the revision and not only some metadata using the sha1 hash. So it appears the movement to sha256 is more of a belt-and-suspenders solution to a problem created by inexperienced users.
reply
25 sats \ 0 replies \ @l0k1 27 Oct 2022
I have been signing my commits by default for a long time. Just because it seems like the right thing to do.
reply
100 sats \ 0 replies \ @benstern 27 Oct 2022 freebie
You can consider not breakable (therefore secure) as long as producing same hash value for two different inputs and guessing input with given hash value is beyond practical limits.
reply