Google Announces First Practical SHA1 Collision

[JonathanM]

SHA-1 is 160 bits, while its successors SHA-2 and SHA-2 are larger (depending on variant, 224, 256, 384, 512 bits).
Naturally more bits has more room for differentiation so it is more secure.
But its nicer with small hashes that are not so large, because they are easier to pass around in a URL query parameter, HTTP header, email signature, or displayed on a webpage in a table or something.

Is it okay to truncate a SHA-2 or SHA-3 hash such as cutting away the last characters and only keeping the 40 bytes?
Is a truncated 40-byte SHA-2 or SHA-3 hash any more secure than a SHA-1 hash?

If you wan't an arbitrary length output of an hash function you may want to look at a XOF like SHAKE (algorithm from the SHA-3 family). (though SHAKE (SHAKE256) can't provide more than 256 bits of security)
Truncating a SHA-2 or SHA-3 hash should indeed provide more security than a SHA-1 hash of the same length.

[schmidtbag]

how serious are you?

If signatures are too weak, then nearly everybody could mess things up, also for security reasons you always include a big enough timer buffer regardless of the use case. If you can say "algorithm A" can be brute forced within minutes in 10 years, then this algorithm is already for every day usage today.

Also there is no reason not to use SHA256+ everywhere, why should anybody use SHA1 if there are better alternatives?

How serious am I? Considering your severe over-reaction, I'd say your seriousness is the one in question. Tell me - what does the average home or office PC user need SHA256 for? Most people don't even care about checksumming anything. If you're really so blind about why not to use SHA256, why stop there? Why is that your limit? Let's just go 512. Hell, why don't we just skip it all together and compare files byte by byte? Surely nothing can be more secure than that...
"Better" is relative. Not everyone has an i7. Not everyone has an SSD. Not everyone has high-speed fiber-optic internet. Not everyone has the latest release of an OS. Not everyone is paranoid about file integrity. Why do you think .zip files are still used when there are "better" alternatives? If the average person is downloading dozens of files from a website, you want the fastest, most compatible, and leanest way to check that the file integrity is solid. Unless you're transferring something like bank, government, or corporate data, SHA1 is "good enough" for most people. Get over it.

Seems to me you don't even understand the point of these algorithms. This isn't AES we're talking about here; this isn't about encryption, so what exactly do you expect to get out of brute-force hacking any checksum? You can't "decrypt" a checksum and get the complete file out of it. Case in point - there is more than one right answer for the outcome.

no they didn't. They did the right think by exposing what's wrong with SHA1. And please don't think that google is the _first_ one to find this issue. There might be others as well with the same knowledge, but they kept it secret from public. If you find issues within security relevant stuff you expose those. Always.

Again, seeing as you seem to take security way overboard, how am I (someone of the general public) supposed to know others have come to the same conclusion? If what you said is true, why did Google waste so much time and resources on this?

Your pleads are nothing more than arrogance.

[JonathanM]

I figure in the vast majority of cases (even for most servers), SHA1 is plenty good enough. Even MD5 is good enough for the average person. In the perspective of companies like Google, IBM, MS, Dropbox, etc, I can definitely see why SHA256 is a necessity.

If your use of SHA-1 is to just provide an integrity check of some local files/DVDs/etc, or if you use it in a hash table, then yes it should still suffice. (Security isn't an issue but collision resistance is important.)

If, for example, you need to sign a certificate, then I strongly disagree. (Things like preimage resistance and second preimage resistance must be good here.)
Using MD5 for anything security related is extremely irresponsible, it is really easy to generate two files with the same MD5 hash. It has a few awful properties.

[schmidtbag]

If your use of SHA-1 is to just provide an integrity check of some local files/DVDs/etc, or if you use it in a hash table, then yes it should still suffice. (Security isn't an issue but collision resistance is important.)

If, for example, you need to sign a certificate, then I strongly disagree. (Things like preimage resistance and second preimage resistance must be good here.)
Using MD5 for anything security related is extremely irresponsible, it is really easy to generate two files with the same MD5 hash. It has a few awful properties.

I completely 100% agree. If security is your concern, you want something like SHA256 (which is why I mentioned big companies that handle a lot of data, or transferring stuff like bank, government, or corporate info). But also if security is your #1 concern, the file should be encrypted and/or password protected too. But most people (outside of governments and data-secure businesses) use checksums for file integrity or checking if you have the right version.

Seems a lot of people here don't get that, though I should've been more clear in my original post.

[Toboe]

The second occurance should surely be SHA256?

From how i understand it: Nope. First occurance is their new attack while the second would be a "normal" brute force (hash random values until a collision is found)

[OneTimeShot]

I completely 100% agree. If security is your concern, you want something like SHA256 (which is why I mentioned big companies that handle a lot of data, or transferring stuff like bank, government, or corporate info).

I think that "malice" is the key word that you are looking for. If someone may be maliciously attacking you, then you want SHA256. For checksums to check you haven't accidentally got a corrupt file you could use CRC for all it matters...

[schmidtbag]

I think that "malice" is the key word that you are looking for. If someone may be maliciously attacking you, then you want SHA256. For checksums to check you haven't accidentally got a corrupt file you could use CRC for all it matters...

Agreed, that is a better word.

[AndyChow]

Still not really an issue. We typically use more than one type of checksum. Even if MD5 and SHA1 are falsifiable individually, they still aren't collideable together. So pass the SHA1, fails the MD5, doesn't help. Most times there are 3 different checksums done.

And in that context, MD5 is still very useful. If it fails MD5, discard and move on. If it passes, then SHA1, SHA256, SHA512, then you know your file hasn't been tampered. Assuming the signature hasn't been compromised, which is more likely than trying to compromise the file by buffering it with some pixie magic that makes it collide.

[karolherbst]

SHA1 is "good enough" for most people. Get over it.

It is today maybe, but not in the future. And then somebody suddenly finds a much better attacks and then it just takes 10 GPUs out of the sudden. And exactly because of things like this, you always consider attackable things as broken. Especially if you can attack those things in a cheap manner in 10 years.

SHA1 is now broken, I don't use broken encryption, period. RC4 shouldn't be used as well, because it's fundamentally broken. Would you say that even RC4 is "good enough" for average users?

No, it isn't cause it is broken. Anybody could temper with RC4 hashed files. Most could even do this with MD5 stuff and in a few years, the same goes for SHA1. But because changing something like this takes time, you have to start at some point. And a good moment would be now.

Seems to me you don't even understand the point of these algorithms. This isn't AES we're talking about here; this isn't about encryption, so what exactly do you expect to get out of brute-force hacking any checksum? You can't "decrypt" a checksum and get the complete file out of it. Case in point - there is more than one right answer for the outcome.

The point of hashes are to identify or check the integrity of files of course. Sometimes I have to send financially relevant documents over the internets and I have scanned files for this. Of course it has to be proven somehow that those files weren't modified in between.

And because e-governance is becoming a thing, this is getting more and more important by the day.

Again, seeing as you seem to take security way overboard, how am I (someone of the general public) supposed to know others have come to the same conclusion? If what you said is true, why did Google waste so much time and resources on this?

Your pleads are nothing more than arrogance.

Sorry, but this is pure bullshit. There might be "evil" actors which won't tell that they found issues within security algorithms. How can I or google or whoever know this? And because you can't be sure, you expose this if you don't belong to the "evil camp" (like secret services, which don't expose such security issues in all cases).

[TheBlackCat]

The second occurance should surely be SHA256?

No, this attack is not a brute-force attack. So the sentence you were quoting is comparing Google's faster attack against a brute-force attack. This is the typical comparison when measuring the speed of such attacks, since everything by definition is vulnerable to brute-force attacks.