Linus Torvalds On Git's Use Of SHA-1: 'The Sky Isn't Falling' (zdnet.com) 203
Google's researchers specifically cited Git when they announced a new SHA-1 attack vector, according to ZDNet. "The researchers highlight that Linus Torvald's code version-control system Git 'strongly relies on SHA-1' for checking the integrity of file objects and commits. It is essentially possible to create two Git repositories with the same head commit hash and different contents, say, a benign source code and a backdoored one,' they note." Saturday morning, Linus responded:
First off - the sky isn't falling. There's a big difference between using a cryptographic hash for things like security signing, and using one for generating a "content identifier" for a content-addressable system like git. Secondly, the nature of this particular SHA1 attack means that it's actually pretty easy to mitigate against, and there's already been two sets of patches posted for that mitigation. And finally, there's actually a reasonably straightforward transition to some other hash that won't break the world - or even old git repositories...
The reason for using a cryptographic hash in a project like git is because it pretty much guarantees that there is no accidental clashes, and it's also a really really good error detection thing. Think of it like "parity on steroids": it's not able to correct for errors, but it's really really good at detecting corrupt data... if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice... It's not silently switching your data under from you... And finally, the "yes, git will eventually transition away from SHA1". There's a plan, it doesn't look all that nasty, and you don't even have to convert your repository. There's a lot of details to this, and it will take time, but because of the issues above, it's not like this is a critical "it has to happen now thing".
In addition, ZDNet reports, "Torvalds said on a mailing list yesterday that he's not concerned since 'Git doesn't actually just hash the data, it does prepend a type/length field to it', making it harder to attack than a PDF... Do we want to migrate to another hash? Yes. Is it game over for SHA-1 like people want to say? Probably not."
The reason for using a cryptographic hash in a project like git is because it pretty much guarantees that there is no accidental clashes, and it's also a really really good error detection thing. Think of it like "parity on steroids": it's not able to correct for errors, but it's really really good at detecting corrupt data... if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice... It's not silently switching your data under from you... And finally, the "yes, git will eventually transition away from SHA1". There's a plan, it doesn't look all that nasty, and you don't even have to convert your repository. There's a lot of details to this, and it will take time, but because of the issues above, it's not like this is a critical "it has to happen now thing".
In addition, ZDNet reports, "Torvalds said on a mailing list yesterday that he's not concerned since 'Git doesn't actually just hash the data, it does prepend a type/length field to it', making it harder to attack than a PDF... Do we want to migrate to another hash? Yes. Is it game over for SHA-1 like people want to say? Probably not."
git was written when SHA-1 attacks were published (Score:4, Informative)
BTW: At the company I work for, we already replaced SHA-2 with SHA-3 for security reasons. Better safe than sorry.
Re: (Score:3)
So yes, the sky is not falling, and git can be made secure, but it also wasn't really wise to use SHA-1 when git was implemented, first.
Why not? As the summary quotes Torvalds, this is simply used to guard against corruption. Using something stronger would have given people the wrong idea about what protections it offered. Sort of like how people who don't understand how HTTPS really works think "as long as I see the lock icon, I am OK and my transaction is safe". Even if it hadn't given people the wrong idea, it would have added computational overhead for no reason.
If your repository needs to be cryptographically verifiable,
Re:git was written when SHA-1 attacks were publish (Score:5, Insightful)
Regarding our use of SHA-3: We use crypographic hash-sums as keys to cached data items that are not permitted for everyone to request. Thus we need to make sure that the cache keys cannot be "guessed" (like from knowing a valid cache key for a similar data item).
Re: (Score:2)
If you think that SHA-3 somehow magically makes everything more secure for verifying data have not been modified in transit (e.g., installer gets corrupted while being downloaded) because you replaced all the SHA-2 hashes with SHA-3 hashes on the installer download page which is served over insecure HTTP, then I suspect you may not fully understand what threats you are trying to protect against.
The point is that if you're trying to use a hash instead of a checksum, it'll actually work as advertised. If you only care about random bit flips CRC32 will work very well and be much faster than MD5 or SHA-1. If you're doing major overkill you might not care that a hash doesn't function as a hash because you don't actually need a hash but that's no reason to use a bad hash. You should either use a good hash or use a lesser solution that doesn't pretend to make promises it can't hold.
Uniformity (Score:2)
If you only care about random bit flips CRC32 will work very well and be much faster than MD5 or SHA-1.
Well, not exactly.
- MD5 and SHA-1 have fast hardware implementation on some CPUs. CRC32 won't necessarily be a huge performance gain.
SHA-1 is used a bit more than a simple glorified checksum in GIT.
It is also used to give a handy number by which you designates commits, etc.
(i.e.: to compute a hash - e.g.: as would also be used in a hash look-up table).
That requires good output uniformity.
In other words you'd need a hashing function that "spreads" its output accross the whole output domain.
(to give an over-s
Re: (Score:2)
Linus really has no sense of security. He'll use whatever is expedient over what's wise. It's a shame really.
Re: (Score:2)
Linus really has no sense of security. He'll use whatever is expedient over what's wise. It's a shame really.
How about describing the attack vector?
Re: (Score:2)
Linus really has no sense of security. He'll use whatever is expedient over what's wise. It's a shame really.
How about describing the attack vector?
The attack vector is straight out of OP's fuzzy behind.
Re: (Score:2)
Linus really has no sense of security. He'll use whatever is expedient over what's wise. It's a shame really.
How about describing the attack vector?
The attack vector is straight out of OP's fuzzy behind.
It's like its possible, for the most unlikely possible way you'd ever want to infect a computer. I'm more worried about getting hit by a meteor. Which is to say, not at all.
Re: (Score:2)
Linus really has no sense of security. He'll use whatever is expedient over what's wise. It's a shame really.
How about describing the attack vector?
Well, the "practical" attack, described here [techcrunch.com] required:
This attack required over 9,223,372,036,854,775,808 SHA1 computations. This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations.
So, Step 1: Get a super-computer ... or rent a fuck-tonne of capacity at Amazon EC2 ...
Re: (Score:2)
Even that wouldn't suffice, as your "corrupted copy" probably wouldn't compile.
Re: (Score:2)
This would be much harder that the PDF example by Google (which is quite impressive though). You'd need to generate a zlib compressed commit with a specific hash which references the correct parent commit's own hash, has consistent naming and dates and yields somehow valid code.
This was said before, but again: the point of having SHA1 hashes in git is not security but to ensure reasonable uniqueness of objects (commit, trees, blobs or tags). SHA1 is (was?) a rather strong crypto hash so you do get some of i
Re: (Score:2)
and yields somehow valid code.
Comments. You have infinite tries to get it right.
Re: (Score:2)
Not really. You can't just put random binary content on a comment.
Re: (Score:2)
Yes you can. At least the compilers i know let you get away with it (you obviously have to strip possible comment terminators from the data but that goes without saying). As an example, I've just appended 1M worth of data from /dev/urandom (after sed(1)ing "*/" away) at the end of a hello world program. Compiled fine.
But the "random binary data" is a straw man anyway, because why would you even have to use random binary data? It's not like you don't have infinite tries with random printable ASCII.
Re: (Score:2)
and yields somehow valid code.
Comments. You have infinite tries to get it right.
But not infinite time, unless you're immortal - in which case you should have better things to do.
Re: (Score:2)
But as of SHA1 being "broken", this is now considered possible in reasonable time. Currently it requires substantial computing power. Soon, it won't. Or might not anyway.
Re: (Score:2)
"Modified" a comment? I think you're not following.
Re: (Score:2)
This attack required over 9,223,372,036,854,775,808 SHA1 computations. This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations.
So, Step 1: Get a super-computer ... or rent a fuck-tonne of capacity at Amazon EC2 ...
Yeah, and don't forget that the (millions) of different hashed programs with the malevolent code will also need to replace the good copy. And compil And install
Oy, such a lot of effort. And yup, there is a non-zero chance of this happening to me. Don't think I'll worry much though.
Re: (Score:2)
Care to substantiate that incredible claim?
Re: (Score:2)
BTW: At the company I work for, we already replaced SHA-2 with SHA-3 for security reasons. Better safe than sorry.
This is a misunderstanding of the purpose of SHA-3. It was not designed to be a "successor" to SHA-2, but an alternative. There is no evidence that SHA-2 is insecure, or even that SHA-3 is more secure than SHA-2. It was simply picked because, at its core, the design is fundamentally different from SHA-2 so it is unlikely that both will be broken at the same time. There is no reason to move from SHA-2 to SHA-3 at this point.
Re: (Score:2)
Indeed. But seeing that would require some actual understand of the issue at hand, instead of a simple-minded "newer must be better".
Re: (Score:2)
Re: git was written when SHA-1 attacks were publis (Score:2, Funny)
Or SHA-not-2b
Re:git was written when SHA-1 attacks were publish (Score:5, Funny)
BTW: At the company I work for, we already replaced SHA-2 with SHA-3 for security reasons. Better safe than sorry.
In my country, we kicked out the Shas and migrated to Ayatollahs, who have a unique uniqueness guarantee!
Re: (Score:2)
As a hash function, SHA-1 was perfectly adequate for how Git works.
All Git uses SHA-1 for internally is to hash the contents of a file to turn it into a unique number. SHA-1 is a nice fast algorithm to do that, and 160 bits offers plenty of space to uniquely identify stuff. It's so good that all the other thing
Re: git was written when SHA-1 attacks were publi (Score:2, Funny)
Ours goes to SHA-11.
Re: (Score:2)
Re: git was written when SHA-1 attacks were publi (Score:2)
Re: git was written when SHA-1 attacks were publis (Score:5, Funny)
Your comment might have been funny if at least their was some algorithm called "SHA-7", but there isn't.
At least Mozilla isn't in charge of updating this, otherwise we'd get SHA-1.0.1, 1.0.2, 1.0.3, 1.1.0 ... bumped every six weeks.
Not a huge issue for git... (Score:2)
By the time you could do something like trash it with crafted content, you could screw things over in less difficult ways...
On the other hand, gpg still uses SHA1 for key fingerprints per the standard, which seems like that would be a much bigger risk. You can use other more secure hashes for digests, but fingerprint ids are SHA1, which was deemed inadequate for key fingerprints in X509...
Re: (Score:2)
Using SHA1 for fingerprints is not an issue at this time. All somebody could do is create two PGP keys with the same fingerprint. As keys do not really contain any critical information, unlike X.509 certificates, this matters little. So the reason SHA1 is "still" used there is that the people doing it actually understand what they are doing.
Re: (Score:2)
Iif someone else makes a key with the same fingerprint as my key, couldn't they sign things and be trusted by people who have trusted my key, since keys are trusted by fingeprint?
Re: (Score:2)
They cannot do that. This is a two-sides hash-collision, i.e. the attacker needs to create both things that then collide when hashed. Creating a second key with the same hash as yours is still infeasible today, unless you cooperate with the attacker.
Yeah... (Score:3, Insightful)
Like how Heartbleed was immediately noticed and didn't sit there for two years.
This is one of those things Open Source proponents keep saying that isn't actually true, because people aren't really auditing the code.
Re: (Score:2)
Re: (Score:2, Informative)
It won't compile. You will notice.
People without a clue commenting on crypto (Score:5, Insightful)
That really annoys me no end. There is some gradual improvement in a specific attack, expected by everybody that has a clue and not seen as anything dramatic by the same people. And immediately a horde of people with no understanding of crypto swoop in an declare the sky to be falling and all uses of this thing are now invalid. This is really just utterly pathetic.
Example: I have to constantly defend the use of SHA1 for password hashing. (Sure, something like pbkdf2 or Argon2 should come later if the password may be low-entropy and gets stored. That is not always the case.) The thing is that password hashing has the purpose of preventing the hash being turned into a password again. Collision attacks have no impact on that at all. For a collision attack you would need to know the password and then you could find a second one with the same hash (or rather with the two-sided, much easier, variant you can find two passwords that map to the same hash). Now, these nil-whits completely overlook that the situation when using hashes in signatures always is that you already have what gets signed, which is completely different to the password situation. Still they claim "SHA1 is broken!". No it is not. It is broken for some specific _different_ application.
Why so many non-experts think they can voice a qualified opinion about a very hard mathematical topic is beyond me.
What Linus says here is exactly right and it is a statement by an expert. All those criticizing him are basically people that can put on a band-aid telling a brain-surgeon how to do his work. They just do not get it at all.
Re: (Score:2)
There's nothing wrong with that use of SHA1, but I can't think of a threat model in which it actually accomplishes anything useful, not because SHA1 is defective, but because passwords are. If an attacker gets the hash, he can almost certainly recover the password. Further, your implied threat model seems to assume that an attacker may be inside the system (which is a good assumption), where he can grab the in-flight hashes. But if that's the case, what prevents the attacker from replaying the hashes? At th
Re: (Score:2)
> If an attacker gets the hash, he can almost certainly recover the password.
How, other than brute force?
Why do you exclude brute force? Brute forcing typical user passwords given a cryptographic hash of them, even salted, and regardless of the hash function used, is very easy. Brute force is exactly the attack I was talking about.
It's best to assume that possession of a hash of a low-entropy secret is equivalent to possession of the low-entropy secret itself.
Re: (Score:2)
That very much sums it up.
Re: (Score:2)
Thanks for proving my point about utterly clueless people here. You are one of them.
A high-entropy password hashed with SHA1 is perfectly secure. You could even hash it with MD5 and still be secure. A low-entropy hashed with SHA1 is not less secure than hashed with, say, SHA-512.
type/length field (Score:2)
Torvalds said on a mailing list yesterday that he's not concerned since 'Git doesn't actually just hash the data, it does prepend a type/length field to it', making it harder to attack than a PDF
I didn't get that one. PDF has a preamble too, right? Which the researchers were able to reproduce just fine in both "shattered" PDFs.
Re:Using SHA-1 in this day and age is just lazy (Score:5, Insightful)
Pretty sure I take his opinion over yours. All he did was help create the software that the majority of the entire internet runs on.
Re: (Score:2)
Re:Using SHA-1 in this day and age is just lazy (Score:5, Insightful)
"Appeal to authority" is not a logical fallacy when the authority is actually an expert in the field. You'd have to be a moron not to value the opinion of a highly accomplished programmer over an AC troll on slashdot.
Re: (Score:2)
"Appeal to authority" is a logical fallacy. But pointing to a logical fallacy and using that as the sole reason to say that an argument is wrong is itself a fallacy: the "fallacy fallacy".
My own opinion here is that Linus is right. It's close to midnight, so I don't feel like backing that up with anything
Re: (Score:2)
Appeal to authority may be a logical fallacy but it's not applicable in this case since the logical fallacy relies on the authority not actually being an expert in the field under discussion.
Trust me I'm a English major*
*An appeal to authority because:
a) I'm not an English major
b) If I was right now I'm just thegarbz and you have no ability to check my credentials on being an expert on the topic.
Re: (Score:2)
My own opinion here is that Linus is right. It's close to midnight, so I don't feel like backing that up with anything
What LT says about adding type and length is correct. The collision attack on SHA-1 won't work as a result. Transition to a better hash is appropriate.
Re: Using SHA-1 in this day and age is just lazy (Score:5, Informative)
Appeal to authority makes a weak argument, but does not invalidate it. You have yet to provide even a weak argument to the contrary.
Re: Using SHA-1 in this day and age is just lazy (Score:2)
You stated above that appeal to authority is a logical fallacy. A logical fallacy is a classification of reasoning typically structured as an argument.
I don't see what is so hard to understand.
Re: Using SHA-1 in this day and age is just lazy (Score:2)
Re: (Score:2)
Wow. I would appeal to authority to correct you but I will instead simply provide you with a link [wikipedia.org]where you can read for yourself why you have this COMPLETELY BACKWARDS.
And in case you don't feel the need to click the link:
Appeal to authority is a logical fallacy when the person is NOT an expert in the field.
Re: (Score:2)
Citation?
Re: (Score:2)
I never knew he created FreeBSD. ( the real workhorse of the internet )
You mean the dark horse, don't you? I heard there are a few FreeBSD web servers [w3techs.com] still running. Nothing against FreeBSD, mind you, some of Linux's core devs were raised on daemon milk.
Re: (Score:3)
Yeah but Aristotle was a fucking idiot.
We stand on the shoulders of giants. Those giants are standing on Aristotle's foot.
Re: (Score:2, Insightful)
Pretty sure I take his opinion over yours. All he did was help create the software that the majority of the entire internet runs on.
Creating an OS doesn't make one a cryptography expert.
You ignorant little shitbag, you still don't have a fucking clue; this is not a cryptography issue, that's why Git doesn't need to fix it.
Once again we have another ignorant little piss-ant who thinks their ignorance is just as good as education.
Re: (Score:2)
IIUC, in this particular context, it's not really a security issue.
Re:Using SHA-1 in this day and age is just lazy (Score:5, Insightful)
He wrote a a small portion of a now popular kernel
He also wrote Git, which is topic being discussed.
You are a fool to take his word on little more than faith on anything resembling a security issue.
1. This is not a security issue.
2. Linus explained his reasoning very clearly, so nothing is being taken on "faith".
Re: (Score:2)
1. This is not a security issue.
Says Linus. As the saying goes, anyone can design a security system(*) that they themselves cannot break, but that doesn't mean others cannot. Linus is no exception to that rule.
All the mitigating factors he mentions are good points, and he's right that the sky isn't falling. But still, using SHA-1 in 2005 was a lazy choice, and it would have been nice to have seen a move to SHA-2 sometime in the following decade.
(*) I know people are saying that the SHA-1 checksum is not a security device, but that's a bit
Re: (Score:2)
Re:Using SHA-1 in this day and age is just lazy (Score:5, Insightful)
Time for Torvalds to drop the attitude and fix this
As far as I can tell, this is a non-cryptographic use of hashing. I've used MD5 in plenty of places just to get a fast (hardware-accelerated) unique ID for a chunk of data, or as a checksum. No security purpose at all.
Re: (Score:3)
As far as I can tell, this is a non-cryptographic use of hashing.
It's Non-Cryptographic until you start using GIT for alternative use cases which it was not designed for.
Code your developers write and store in Git should be trusted data, in the sense you are not trying to attack the system.
And code you accept from third parties should be reviewed by humans first to check that it is non-malicious.
Since the SHA-1 collision attack can be detected; It seems like it would be also a simple patch to Git to
Re: (Score:2)
Well, it is not the software's use non-cryptographic code for cryptographic applications.
Anyway, git's been planning on a new commit hash for a while.
Re: (Score:3)
"...the software's fault if you use..."
Anyway, want strong security? Use signed commits.
Re: (Score:2)
Signed using SHA1?
Re: (Score:2)
Signed with whichever hash GnuPG supports. That includes the entire SHA family up to SHA-3.
Also, when a commit is signed it becomes bundled with it, which means its associated SHA-1 hash will change.
Re: (Score:2)
Well, it is not the software's use non-cryptographic code for cryptographic applications.
I'm referring to use cases specifically like SparkleShare, By the way. Git-based Dropbox-like file synchronization tool.
It's arguably a major Bug in Git if the Git software keeps track of an object Solely by Hash, and lazily assumes that the Hash
uniquely identifies a specific version of the file, And that assumption turns out to be false, and data corruption or tampering can be caused as a result.
HOWEVER.......
Re: Using SHA-1 in this day and age is just lazy (Score:2)
Re: (Score:2)
It's arguably a major Bug in Git if the Git software keeps track of an object Solely by Hash, and lazily assumes that the Hash
uniquely identifies a specific version of the file, And that assumption turns out to be false, and data corruption or tampering can be caused as a result.
I disagree, this is not a bug. It is perfectly reasonable to use a crypto hash to uniquely identify objects within a SCMs, given that one of their properties is that they provide uniformly distributed IDs over a very large space. Statistically the chance of running into a SHA1 collision under normal git usage is so low as to be practically zero - you have a (much, much) better chance of experiencing repo corruption due to cosmic rays hitting your HDD or memory.
Anyway, git's failure mode is not horrible eith
Re: (Score:2)
Statistically the chance of running into a SHA1 collision under ....
Just because a choice of technology seemed a "reasonable" choice does not mean exposure of a failure case is not a bug.
The "HASHing" algorithms and Database formats used inside the program are internal technical design choices of the software and does not Affect what Correct behavior of the software is.
If a program has only a statistical chance of working correctly when you expect it to [less than 100%] in the worst-case real-world scen
Re: (Score:2)
Check the link on my parent post again.
Re: (Score:2)
It's arguably a major Bug in Git if the Git software keeps track of an object Solely by Hash, and lazily assumes that the Hash uniquely identifies a specific version of the file,
A hash of 128 bits or more is a more reliable unique ID than anything custom you could code up. Safe vs malicious attackers is different, and as others have pointed out, sign your commits. But as just a way to get a reliably unique ID for a document (or set thereof)? It's a very solid approach.
Re: (Score:3)
You live in a scary world of imaginary threats, my friend.
Re: (Score:2)
As far as I can tell, this is a non-cryptographic use of hashing.
Git uses sha1 hashes to identify everything.
A (possiblly signed) tag references a commit by hash
A commit references a tree by hash
A tree references a list of files and subtrees by hash
If a commit you fetch references hashes you already have the files for in your local git tree they will not be re-fetched, the existing ones will simply be used.
The whole point of git is to be distributed, so it should be safe to fetch commits from untrusted sources, inspect them and throw them away without worrying that they
Re: (Score:2)
Much more unique than checksums.
Re: (Score:2)
You think hashes are unique. You're insane.
A 128-bit hash (from a common library or hardware implementation) is more likely to be unique than any code you write in the attempt to create a unique ID. Why? Because the risk of an accidental 128-bit hash collision within a pool of, say 1 billion items, is lower than the risk of a bug in your code.
If you doubt it, ask yourself this: what's the occurrence of bugs, per million lines of code, in high quality software? I bet there's a better than 1:1 million chance of a bug in any code you write to genera
Re: (Score:2)
You're not helping your point any. Hashes (like MD5, which is 128 bits) are plenty unique.
Re: (Score:2)
Re: (Score:3)
u dont
I stopped reading there, sorry.
Re: (Score:2)
No. He's absolutely right - there's no reason to panic and rush, specially when they've already been working on switching to a new hash.
Re:Using SHA-1 in this day and age is just lazy (Score:5, Insightful)
His arguments as to why it isn't serious are reasonable. If you want your arguments to be considered, you need to make some.
Re: (Score:2)
It's spelled "spelt".
Re: (Score:2)
Why not? The hash in git is not there to provide security.
True, and this is the main point. The principle reason Sha-1 was chosen by the creator of the Monotone project that begat Git is, its designed-in ability to hash non-uniform input into uniformly distributed hashes. Or maybe the main point should actually be, Linus did not choose Sha-1, Graydon Hoare [github.com] did, and Linus simply copied that along with Monotone's basic algorithms. See, Linus isn't a mathematician and doesn't claim to be, but he is a master of knowing what to copy.
Re: (Score:2)
Linus is a mastermind manipulator who destroyed the GNU Project ...
The GNU Project is far from destroyed. On the contrary it has already written a prominent page in history that can never be erased, and continues to carry out its good[1] works.
[1] With the exception of Autotools, which is spawn of the devil
Re: (Score:2)
Re: (Score:2)
That argument does not count for most people, because most people have no clue what a hash actually does and what it can be used for. Most of these morons have no clue that crypto-hashes can well be used for non-crypto things.
Re: (Score:2)
Why would Astrosmurf care about SHA-1?
Astrosmurf cares about any post about Linus and otherwise probably has trouble tieing his (her/its) shoes, let alone Knowing anything about higher math or security.
re: bad doge (Score:2, Funny)
Such troll.
Very flamebait.
Wow.
Re: (Score:2, Funny)
Linus Torvalds = Fucktard.
Aww, did Linus tell you do go fuck yourself because you crap code you tried to get into the kernel?
Re: (Score:3)
When you incorrectly state that a quote with only one claim is a non sequitur, the rest of your comment is probably wrong too.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
That is bullshit. CRC is slow and has a collision-probability high enough to be a concern. CRC is not a good idea in repositories that can be very large. Incidentally, the claim that using a crypto-hash for a hash indicates that a "secure" has is needed is completely bogus. Crypto-hashes now have speeds and set-up times that make them well suitable as replacements for normal hashes in situations where you not mainly hash very short things. A lot of semi-competent people seem to have missed that little fact
Re: (Score:2)
If all you cared about was a "content identifier", you'd use CRC.
Only if you're actually looking for content collision issues in your SCMs. CRCs not only normally have much smaller output spaces than crypto hashes, they're also horribly non-uniform, which greatly increases the chance of collisions.
Re: (Score:2)
Don't confuse possible and feasible. It's not proven that the discrete log problem has no linear-time solution. But there is no known linear time solution, so we rely on this problem remaining unsolved in order to trust our encryption.
It's a little harder to say in one sentence why creating simultaneous hashing solutions is not feasible, but (at least at the moment) it is considered to be an unsolved mathematical problem. Or, at least, so claimed the post which announced the sha1 collision experiment (h
Re: (Score:2)
It is possible, yes, but it is also extremely unlikely to happen. Which is the entire point here.
Re: (Score:2)
No, CRC would make a terribly bad content identifier.
Of course, it would. Precisely for the reasons I outlined.
First of all, a usual 32-bit CRC is too short: by birthday paradox
I didn't say anything about 32 bits. You can make it any power of 2. It's effectively just a remainder of dividing by an irreducible polynomial in an extension field of F_2. I wasn't suggesting using it.
I was saying that Linus was being flippant by ignoring a problem with a trivial solution and he doubled down by claiming that the only functionality he was looking for was something which needs less than cryptographic-level randomness. But what
Re: (Score:2)
So a cryptographically accurate description of the situation together with a risk analysis and announcement of a longer-term plan is "to hell with security"?
There seems to be something wrong with your brain.
Re: (Score:2)
That is apparently an idea many, many people cannot understand, obvious though it is.
My guess is that these people can only think in association-classes: For them, SHA1 equals security and any successful attack on SHA1 (no matter what its nature is) hence must break security in all applications of SHA1 (even if not used for security there or the attack is irrelevant for the scenario it is used in).
Of course, such a simplistic model of thinking is utterly pathetic and disconnected from reality, but it seems