SoylentNews is people
SoylentNews
Attacks on the SHA-1 hashing algorithm just got a lot more dangerous last week with the discovery of the first-ever "chosen-prefix collision attack," a more practical version of the SHA-1 collision attack first carried out by Google two years ago.
What this means is that SHA-1 collision attacks can now be carried out with custom inputs, and they're not just accidental mishaps anymore, allowing attackers to target certain files to duplicate and forge.
The SHA-1 hashing function was theoretically broken in 2005; however, the first successful collision attack in the real world was carried out in 2017.
Two years ago, academics from Google and CWI produced two files that had the same SHA-1 hash, in the world's first ever SHA-1 collision attack -- known as "SHAttered."
Cryptographers predicted SHA-1 would be broken in a real-world scenario, but the SHAttered research came three years earlier than they expected, and also cost only $110,000 to execute using cloud-rented computing power, far less than what people thought it might cost.
But last week, a team of academics from France and Singapore has taken the SHAttered research one step further by demonstrating the first-ever SHA-1 "chosen-prefix" collision attack, in a new research paper titled "From Collisions to Chosen-Prefix Collisions - Application to Full SHA-1."
"Finding a practical collision attack breaks the hash function badly of course, but the actual damage that can be done with such a collision is somewhat limited as the attacker will have little to no control on the actual data that collides," Thomas Peyrin, one of the researchers told ZDNet via email over the weekend.
"A much more interesting attack is to find a so-called 'chosen-prefix collision,' where the attacker can freely choose the prefix for the two colliding messages. Such collisions change everything in terms of threat because you can now consider having collisions with meaningful data inside (like names or identities in a digital certificate, etc)."
(Score: 2) by driverless on Tuesday May 14 2019, @09:17AM (1 child)
You need to be able to read these papers with an ability to interpret what's really in there rather than taking the contents at face value. Chosen-prefix collisions are just an extension of standard collisions. In many cases where SHA-1 is used, e.g. in certs, this isn't possible, they have 64-bit (minimum) random serial numbers to deal with this. The paper also claims that you can "break TLS, IKE, and SSH", but this assumes either a near-real-time break of SHA-1 or a TLS implementation that's willing to wait several months between two parts of the TLS handshake, neither of which exist. So the impact is really mostly mitigated in common use cases, it's only if you're doing things like long-term signatures on data that you need to worry, and in that case you should have dropped SHA-1 long ago.
The reason why SHA-3 isn't used is that it has no currently-known advantages over SHA-2. It's also a lot slower than most other hash functions, including SHA-2 and also good alternatives like BLAKE2 if you really want a newer-than-SHA2 hash. So it has no real advantage over SHA-2 but is a whole lot slower, there's no incentive to use it.
(Score: 2) by bzipitidoo on Tuesday May 14 2019, @03:07PM
Ahh, the need for speed. Most people sing in the security choir, that security is more important than any other issue. Then they show they don't believe it by not practicing what they preach.
For example, if security is so important, why haven't chip makers moved faster to fix Spectre? They've nibbled at the edges, made it not as bad, but have not truly fixed it. They've whined that it will hurt the speed of their CPUs. However, manufacturers always complain that complying with regulations, fixing flaws, increasing safety, or whatever is overly burdensome, and then often it turns out not to have been as bad as they claimed. I would like Spectre fixed, but I have to concede that it takes a lot of clearly malicious code to exploit the flaw, and for unimportant uses and users, it may not be worth extraordinary efforts to solve. Most especially, I have not heard that anyone is willing to go all the way back to 25 year old CPUs that do not have speculative execution, and accept the massive performance hit, to be safe from Spectre.
If as you say SHA-3 has no advantage in security, then that's a double blow. Slower and no more secure.