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: 0) by Anonymous Coward on Tuesday May 14 2019, @07:51PM (1 child)
What about MD4+MD5?
One of the details left out in lots of these 'OMG IT'S BROKEN, UPGRADE!!!' scenarios is not just the practicality of attacks against a single checksum type, but attacks that work against multiple checksums plus a file length. If you have 2 checksums and a file length less than x(whatever the checksum(s) maximum value(s) with statistically unlikely collisions), you should in many cases be as secure as a 'stronger' checksum mechanism with less cycles used to arrive at that protection. If you can interleave the checksumming algorithms so they are both checksumming the same data at the same time you can increase performance even more. Given the ever increasing lengths of sha256/512/blake2/etc as well as the cpu time some of these hashing methods require, it is worth considering pairs based on file size, as well as a 'future hash' for each to help ensure authenticity well into the next decade or beyond, so that even if a website is hacked and some checksums can be faked, the integrity can be assured thanks to the intersection of checksums.
(Score: 0) by Anonymous Coward on Wednesday May 15 2019, @09:03AM
This is something I've been wondering myself. Would be interesting to hear the opinion of somebody qualified.