Google Announces First Practical SHA1 Collision

[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)

[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.

[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]

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]

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.

[karolherbst]

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.

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?

EDIT:
I kind of just realized that Google probably caused more damage with this discovery than they hoped to prevent (especially if those PDFs get released). The average hacker has nowhere near the resources Google has to come to the same conclusion, so as far as hackers were concerned, discovering this wouldn't have been worth their time. Sure, some people would know that it is statistically possible to have 2 different files with the same checksum, but, I don't think anybody knew specifically how to do it. Now, there's definitive proof of it, and we know what file type is known to work.

Regardless, this is very interesting stuff.

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.

[oliw]

The average hacker has nowhere near the resources Google has

Strongly disagree. Average hackers have exactly the same resource as Google because you can rent Google's GPU servers for $0.70/hour. There's also AWS and organised criminals will have access to massive botnets that dwarf both.

Google's specs say it takes 40150 "GPU days" to brute these. A big enough cluster and you're looking at hours. $700k on GCE, but I'd be shocked if there wasn't cheaper.

[uid313]

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?

Edit: I found out the answers to my questions. http://crypto.stackexchange.com/ques...-as-using-sha1

[bug77]

No, we didn't have any specific reason to believe that. Other hash functions have had weaknesses demonstrated and that's why there has been efforts to remove them from use. That wasn't the case for SHA1. We just knew that from a complexity standpoint, it was likely to be next in line to get attacked. But, there was no clear time scale for that to happen. It wasn't expected to happen for a few more years at the soonest. That's why most of the security industry was pushing gack against Googles attempts to depricate it.

https://www.entrust.com/understanding-sha-1-vulnerabilities-ssl-longer-secure/

[jass0]

Though it's still not too easy to come by such an attack: Google's SHA1 "shattered" attack takes 110 GPUs one year of work to produce a collision while a SHA1 bruteforce attack on the other hand would take 12 million GPUs and a year worth of work.

The second occurance should surely be SHA256?