I'm not an expert of SHA-1 collisions, but I'd take Linus word for it. :)
Linus' reply on Git and SHA-1 collision
241–250 of 273 posts
Re: Linus' reply on Git and SHA-1 collision
#242Downloading the PDFs [1] and comparing their sizes takes less than a minute. They're the exact same size. Yet here we have Linus making one bet after another that size has to be different for this attack. Now to be fair, he also keeps repeating that he hasn't seen the attack yet . Which leads me to question why is this post interesting to HN? Is it to show how Linus aimlessly speculates and gets his guesses wrong? --…
> Downloading the PDFs [1] and comparing their sizes takes less than a minute.
shattered-1.pdf and shattered-2.pdf have the same size and sha-1 hash, but git is still able to recognize that those are two different files and creates two different commit hashes for them. So clearly just having the same size and sha-1 hash is not enough to fool git.
Re: Linus' reply on Git and SHA-1 collision
#243Earlier quoted context omitted.
We're talking about a conversation amongst kernel/software developers about a very technical software issue. Anyone who doesn't understand why the risk was so small doesn't belong in the conversation. Can you even imagine where our medical field would be if we expected surgeons to talk amongst themselves as if they were speaking to the general public? It is absolutely acceptable for the speaker to make assumptions ab…
> Can you even imagine where our medical field would be if we expected surgeons to talk amongst themselves as if they were speaking to the general public? The Git devs are not heart surgeons, software development is not a medical field. Again, you are using an analogy to "prove" your point. Can you, please, use a real argument? >> The purpose of an analogy is to simplify something that's too hard to understand for th…
An analogy isn't a proof.
When someone uses an analogy they're not trying to prove anything, they're trying to get you to see things from a specific perspective, or they're trying to communicate an idea.
You can still walk away from the analogy and disagree with them, but you should have a better understanding of their perspective or their argument.
> Do you disagree that using an analogy is oversimplification?
I think your entire approach to analogies is unnecessarily combative. You view an analogy as someone trying to prove something rather than trying to communicate their position better (or just an idea in general).
And your approach is to point out that the analogy isn't perfect, and therefore you've "disproved" the analogy.
Only analogies are, by their very nature, imperfect. When an analogy is perfect it ceases to be an analogy and becomes the thing being discussed.
It should automatically be understood that there are the analogy isn't perfect and anyone can find flaws in it. That doesn't mean it isn't an effective way to communicate.
Re: Linus' reply on Git and SHA-1 collision
#244Earlier quoted context omitted.
I don't like the living-on-the-edge-attitude that Linus and others here promote regarding Sha1 in git. First, attacks only get faster over time. What costs millions today is likely to be achievable on commodity hardware in the coming years. Second, attacks only get more flexible over time. A contrived collision on MD5 in 2004 got perfected to a single block collision in 2010 [1]. Third, devising an update strategy an…
"On the edge" "A contrived collision on MD5 in 2004 got perfected to a single block collision in 2010 [1]" so they'd have at least years to fix it were they using md5? He says they'll migrate, but it's no reason to go crazy. If anything, calmness of this sort is what we need more of (this industry, anyway... we go crazy about stuff way too much).
Sha1 was already a questionable idea in 2005 when git came out, because it was then already understood to have fundamental flaws.
https://www.schneier.com/blog/archives/2005/02/cryptanalysis...
Re: Linus' reply on Git and SHA-1 collision
#245Pertinent facts for the worried: 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n). 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's…
I don't like the living-on-the-edge-attitude that Linus and others here promote regarding Sha1 in git. First, attacks only get faster over time. What costs millions today is likely to be achievable on commodity hardware in the coming years. Second, attacks only get more flexible over time. A contrived collision on MD5 in 2004 got perfected to a single block collision in 2010 [1]. Third, devising an update strategy an…
[deleted]
Re: Linus' reply on Git and SHA-1 collision
#246Pertinent facts for the worried: 1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. 2) Even if git did rely on SHA-1, there's no imminent threat. What happened today was a SHA-1 collision, not a preimage attack. If a collision costs 2^n, a preimage attack costs 2^(2n). 3) Even if someone managed to pull off a preimage attack, creating a "poisonous" version of one your git repository's…
>1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust.
This is a big lie. When the -S flag is used, git signs the SHA-1 of the commit. Moreover HTTPS does not provide any form of authentication due to the extremely broken CA model. NSA could simply ask any CA to give them a cert for github for example. Not to mention that https would only authenticate that you are talking to the github server, it would say nothing concerning the authenticity of the code.
>they'd still have to convince you pull from their repo. This requires trust.
How about compromising your servers instead? Or maybe simply have NSA asking github to let them modify a commit (which would end up having the same SHA-1 and being signed by you).
>4) Even if you pulled it in, your git client would simply ignore their "poison" object, because it would say, "oh, no thanks, I already have that object". At worst, the code simply wouldn't work. No harm would be done.
https://stackoverflow.com/a/34599081
Didn't Git v2.0 break backwards compatibility? Couldn't they simply move to Sha-2 during that time?
Re: Linus' reply on Git and SHA-1 collision
#247Downloading the PDFs [1] and comparing their sizes takes less than a minute. They're the exact same size. Yet here we have Linus making one bet after another that size has to be different for this attack. Now to be fair, he also keeps repeating that he hasn't seen the attack yet . Which leads me to question why is this post interesting to HN? Is it to show how Linus aimlessly speculates and gets his guesses wrong? --…
> Downloading the PDFs [1] and comparing their sizes takes less than a minute. shattered-1.pdf and shattered-2.pdf have the same size and sha-1 hash, but git is still able to recognize that those are two different files and creates two different commit hashes for them. So clearly just having the same size and sha-1 hash is not enough to fool git.
Git calculates sha1(prefix+file), while the Google example was meant for sha1(file). However there is no difference in the attack. You could just as easily construct two files that have different sha1(file) but matching sha1(prefix+file).
Re: Linus' reply on Git and SHA-1 collision
#248Earlier quoted context omitted.
thats stretching it. if you could convince anybody to pull from you then why even bother to go to a great expense of creating a collision.
This reminds me of vulnerability reports that start with "if you have root access..."
Or, as Raymond Chen puts it (quoting Douglas Adams), "It rather involved being on the other side of this airtight hatchway."
Re: Linus' reply on Git and SHA-1 collision
#249Several years ago I worked on a security product that used git as a sort of tripwire-type database. Since SHA1 was considered inadequate for Real Security, we had to hack jgit to use SHA256. It took a stupid amount of work - the 160-bit hash size was scattered all over the codebase in countless magic numbers. But it worked. The product was cancelled. I always wondered if the patch would be of any use to anyone.
This is a typical outcome. You worry about some hypothetical threat, spend countless hours mitigating the threat instead of working on useful features, money goes down the drain, and then the project gets canceled. Security is just one of the features of a product. It's not more special that other features. You prioritize it like the rest of product features.
Re: Linus' reply on Git and SHA-1 collision
#250Earlier quoted context omitted.
1) Git doesn't rely on SHA-1 for security. It relies on HTTPS, and a web of trust. I would say cryptographic integrity definitely counts as "security". I agree this isn't currently a big deal, but it's probably time to start migrating to a better hash.
But .. that's what Linus is saying in his mail. Like, really exactly what you say in your last sentence..?
The quote for those who didn't read the email. Linus Torvalds says:
> Do we want to migrate to another hash? Yes.