SoylentNews is people
SoylentNews
SecurityWeek has an interesting article today about the first real world SHA-1 collision attack.
Researchers at Google and Centrum Wiskunde & Informatica (CWI) in the Netherlands have managed to conduct the first real world collision attack against SHA-1, creating two documents with different content but identical hashes.
SHA-1 was introduced in 1995 and the first attacks against the cryptographic hash function were announced a decade later. Attacks improved over the years and, in 2015, researchers disclosed a method that lowered the cost of an SHA-1 collision to $75,000-$120,000 using Amazon's EC2 cloud over a period of a few months.
Despite steps taken by companies such as Google, Facebook, Microsoft and Mozilla to move away from SHA-1, the hash function is still widely used.
Google and CWI, which is the national research institute for mathematics and computer science in the Netherlands, have now managed to find a collision, demonstrating that these attacks have become increasingly practical. Their technique has been dubbed "SHA-1 shattered" or "SHAttered."
"We were able to find this collision by combining many special cryptanalytic techniques in complex ways and improving upon previous work. In total the computational effort spent is equivalent to 2 63.1 SHA-1 compressions and took approximately 6 500 CPU years and 100 GPU years," experts said in their paper.
While the task still required a large number of computations – nine quintillion (9,223,372,036,854,775,808) to be precise – the SHAttered attack is 100,000 times faster than a brute-force attack.
Google and CWI have announced the first publicly known SHA-1 collision at: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html The collision is based on a prefix attack and requires 5 orders of magnitude less work to find a collision, when compared to brute force. More information and the actual files are available here: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html and a detection tool here: https://github.com/cr-marcstevens/sha1collisiondetection
(Score: 4, Informative) by jmorris on Friday February 24 2017, @05:44AM
So if you put a supercomputing cluster to work on it you can get a collision in a month. And since they used a .pdf for their example we can assume it like the similar break on MD5 earlier where it was required to be able to hide a large blob in the file.
So this isn't a imminent exploit about to sweep the Internet but it is time to finish cleaning up any holdouts and get entirely off of SHA1 in the next year. So don't trample anyone but do move toward the exit in an orderly manner.
(Score: 5, Interesting) by ledow on Friday February 24 2017, @08:21AM
Yep. But that's always the first stage.
From here on in, SHA-1 can only go downhill.
I still posit - and they hint at this - that we shouldn't be storing ANY single hash.
Hash everything with all of them.
The chances of finding two sets of data with not only a matching SHA-1 but also matching a MD5 (even!) grew infinitesimally small very quickly. Sure, you can make a file with an MD5 collision. And one with a SHA-1 collision. But the difficulty of making one with BOTH without it being identical data to the original, and the chances of that data working to your advantage (i.e. a chosen malicious set of data that hashes the same as the original data in BOTH hash algorithms) is unbelievably huge for little extra work.
And it provides backwards and forwards compatibility (sure, your old software can only check the MD5 but if the other hashing algorithms on the filesystem/network packet are checking that producing the file producing that MD5 is fine, then it's just as good and gives you much more transition time) for free.
And the way hashing algorithms work, you tend to feed each of the data bytes sequentially into the algorithm - it's an O(n) process. As such, you can do it simultaneously on 20 different hash-types at exactly the same time and keep it O(n), get extra security (even if it's not THAT much) and automatically have every hash available for not that much extra time (extra CPU-time, yes, but you can do the hashes in parallel quite easily) and no extra reads at all.
If I were designing any kind of important system that required to check hashes, I'd be hashing and storing with as many algorithms as possible. It also means that your code is ready when a rehash is required. You can implement "Yet Another Hashing Algorithm", add it to the list, let it slowly re-hash every time it has to modify whatever data it's storing (while also rehashing the MD5 and SHA-1 etc. anyway), and then at some point in the future force a "We must use the YAHA hash for anything security related" while still keeping - and still hashing - all the other algorithms in parallel.
I honestly don't get why this isn't a part of every filesystem / database in the world.
(Score: 1) by Skittles on Saturday February 25 2017, @04:18PM
> I still posit - and they hint at this - that we shouldn't be storing ANY single hash.
> Hash everything with all of them.
The overhead involved would be substantial for most applications.
> The chances of finding two sets of data with not only a matching SHA-1 but also matching a MD5 (even!) grew infinitesimally small very quickly. Sure, you can make a file with an MD5 collision. And one with a SHA-1 collision.
FWIW it's likely much easier at this point to generate a collision against both SHA1 and MD5 than it would be to generate a single collision with SHA2.
(Score: 2) by Wootery on Monday February 27 2017, @01:40PM
The overhead involved would be substantial for most applications.
In which applications is performance dominated by cryptographic hashing? No-one would notice the performance hit if Git moved to a 'hybrid hash' function, for instance. Nor for email signing.
(Score: 2) by darkfeline on Friday February 24 2017, @06:26PM
SHA-1 has been theoretically broken for years now. If you haven't been moving toward the exit for at least a year, you are far far behind. As I understand it, part of the motivation behind this demonstration is the "encourage" the stragglers to get their asses moving.
>So if you put a supercomputing cluster to work on it you can get a collision in a month.
Go was considered out of reach for AI less than a year ago. Things move fast in computing, and it only gets faster as time progresses.
$100k and a few months is a absolute STEAL if it means the possibility of inserting a backdoor into, say, OpenSSH, even if for a few months before it's noticed. Hell, up the price tag to $10 million to account for the limitations of the current collision attack, and it's still a bargain.
Join the SDF Public Access UNIX System today!