One thing SHA-256 has going for it is that millions can be made from finding pre-image weaknesses in it, because it's used in Bitcoin mining. If you could "figure out" SHA-256, and use it to take over Bitcoin mining, you'd make $2M the first 24 hours, at current rates. And if you play it wise, it could take a long time before anyone figure out what's going on. With regards to market price for a successful attack, I d…
Linus on Git and SHA-1
61–70 of 187 posts
Re: Linus on Git and SHA-1
#62Earlier quoted context omitted.
The HN guidelines specifically ask not to express the expectation of downvotes. You may be downvoted purely for ignoring the guidelines, regardless of the rest of your comment. Please don't bait other users by inviting them to downvote you or proclaim that you expect to get downvoted. https://news.ycombinator.com/newsguidelines.html
A generally reasonable guideline, but in this case, I am actually criticizing the tribalism that makes people rise to that bait. It similarly leads to the discussion of how "I can't believe Linus is trying to defend SHA-1 when The Tribe already knows it is cryptographically 'bad'."
[deleted]
Re: Linus on Git and SHA-1
#63Linus's transition plan seems to involve truncating SHA-256 to 160-bits. This is bad for several reasons: - Truncating to 160-bits still has a birthday bound at 80-bits. That would still require a lot more brute force than the 2^63 computations involved to find this collision, but it is much weaker than is generally considered secure - Post-quantum, this means there will only be 80-bits of preimage resistance (Also:…
> "A hash that is used for security is basically a statement of trust [..] In contrast, in a project like git, the hash isn't used for "trust". I don't pull on peoples trees because they have a hash of a4d442663580. Our trust is in people, and then we end up having lots of technology measures in place to secure the actual data." This is horseshit, and Linus should not be saying these hugely misleading statements abou…
Yes, exactly.
If Linus truly doesn't care about security, then git could use any error correcting code that produces a uniform distribution of tags, such as CRC64. The size of the tag only affects the number of objects we'd expect to be able to commit before we see a collision: over 4 billion in the case of CRC64.
Linux mistakenly claims using a cryptographic hash function helps avoid non-malicious collisions, but this is not the case.
Where the choice of a cryptographic hash function matters is specifically if we expect an attacker to be trying to collide tags. CRC64 is a linear function of the input data and therefore fails miserably at preventing attackers from colliding tags, but still produces a uniform distribution of tags for non-malicious inputs.
git seems to be in the odd place where Linus argues he's using a cryptographic hash function but not for security purposes.
Re: Linus on Git and SHA-1
#64I'm mystified as to why this is even a discussion. SHA1 is busted. That impacts some git users. The fix is not invasive. Fix the bug. Make the transition. Move on. Super unprofessional.
It's not that simple. Git is a widely used software integrated into many places, so keeping some backwards compatibility is important. Just going ahead and start breaking things would really be unprofessional.
They did break backwards compatibility with git v2.0 but sadly they did not bother to change the hash function.
Re: Linus on Git and SHA-1
#65Earlier quoted context omitted.
The HN guidelines specifically ask not to express the expectation of downvotes. You may be downvoted purely for ignoring the guidelines, regardless of the rest of your comment. Please don't bait other users by inviting them to downvote you or proclaim that you expect to get downvoted. https://news.ycombinator.com/newsguidelines.html
A generally reasonable guideline, but in this case, I am actually criticizing the tribalism that makes people rise to that bait. It similarly leads to the discussion of how "I can't believe Linus is trying to defend SHA-1 when The Tribe already knows it is cryptographically 'bad'."
If you are taking the view that you're expecting downvotes to prove the point that people who are trying to uphold community standards are doing so blindly or ignorantly, you'll very likely think you're proven correct when you do receive downvotes. Can you blame them? You're explicitly flaunting the guidelines they choose to abide by while telling them they're wrong to do so in your special case.
Re: Linus on Git and SHA-1
#66One thing that I think is worth mentioning: This was completely avoidable. Git isn't that old, it wasn't taken by surprise by the SHA1 attacks.
The first paper from Wang et al, which should've put SHA1 to rest, was published in 2004, the year before the first ever Git version was released. It could have been easy: Just take a secure hash from the beginning.
Re: Linus on Git and SHA-1
#67Earlier quoted context omitted.
Then you have stuff like 1, I and l, which are difficult to distinguish. Which was why base58 was invented (basically the range you suggested, without visually similar characters).
This really should not be a problem since that's task #1 that a programmer's good font needs to solve.
I often run into git hashes places where a programming font wouldn't apply, like URLs and web pages.
Re: Linus on Git and SHA-1
#68Have there been writings on what exactly git's migration strategy to a new hash function will be? Apparently they have a seamless transition designed that won't require anyone to update their repositories, which seems like a pretty crazy promise in the absence of details.
In git the SHA-1 hash is simply an identifier for an object - it's used in the filename, but not stored in the object. And when a commit or tree object references others, it's just a name that can be looked up in the database. So a commit object hashed with SHA-256 can easily reference a previous commit that was hashed with SHA-1.
During the switch, a bit of deduplication may be lost. But the only interesting issue I can see is how git fsck will tell which hash an object was created with when verifying the hash (maybe with length?).
Re: Linus on Git and SHA-1
#69Linus's transition plan seems to involve truncating SHA-256 to 160-bits. This is bad for several reasons: - Truncating to 160-bits still has a birthday bound at 80-bits. That would still require a lot more brute force than the 2^63 computations involved to find this collision, but it is much weaker than is generally considered secure - Post-quantum, this means there will only be 80-bits of preimage resistance (Also:…
>Preimage resistance does matter Is there a preimage weakness though? I thought this attack only reduced collision resistance.
GP said that in reference to quantum attacks.
Re: Linus on Git and SHA-1
#70Earlier quoted context omitted.
This really should not be a problem since that's task #1 that a programmer's good font needs to solve.
I often run into git hashes places where a programming font wouldn't apply, like URLs and web pages.
>where a programming font wouldn't apply, like URLs
Any phisher's wet dream is a URL displayed in a font where l and I look the same. For anything that routinely displays URLs, font matters a lot. And any website displaying git hashes is likely to be programming related and have some code-font (good monospace or similar) in it's repertoir.