Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Monday May 13 2019, @11:30PM   Printer-friendly
from the SHA-2 dept.

https://www.zdnet.com/article/sha-1-collision-attacks-are-now-actually-practical-and-a-looming-danger/

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)."


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Tuesday May 14 2019, @04:06PM

    by Anonymous Coward on Tuesday May 14 2019, @04:06PM (#843452)

    Before, Linus thought that this kind of attack is hard to use against Git as there are additional constraints ... Does this new attack change anything, or not?..

    Collision attacks, including this one, basically only are a problem for digital signatures. Now, git does use digital signatures, for example there are signed tags used for authentication.

    So since SHA-1 collision attacks exist, the potential attack on a git repo is this: I can (possibly) construct two git commits with the same hash, with one being "good" and the other "evil". I get you to pull my "good" commit, so now your repository contains the colliding hash. If you then push a signed tag to the repository, at a later date I can publish another repo containing the "evil" commit with your valid signature on it.

    Anyway, chosen-prefix collision attacks make dealing with formatting of the things you're hashing easier, so this will probably make it easier to construct colliding git objects.

    In practice pulling off this sort of attack on a git repo is likely not worth the effort. Hardly anyone pushes signed tags and very few people verify signatures anyway. And there are much simpler attacks which are probably easier and more effective. For example, getting a maintainer to simply accept a bad patch (see: openssl), or take over maintanership of a popular but unmaintained package and publish malicious versions (see: event-stream), or simply compromise a mirror and replace source tarballs (see: unrealircd).