Perhaps it's time to move on to SHA-3 or some other hash?
Sure, but mainly because that is a good marketing thing and not because of any real world threat. It is much easier to cater to - nay, exploit! - people's fears than to roll the education rock uphill. :-) It takes zero effort for Manifold to simply publish SHA256 codes. No extra work involved, just add a string of hexadecimal numbers to the web site and then do a victory lap to bask in the glory of doing something really technical to address a problem that, as yet, in no practical way exists. Will it exist in the future? Of course, so no harm done doing a pre-fetch on the "cover oneself with glory" bit. :-) In fact, as soon as Google announced the attack, savvy marketing people everywhere immediately thought "hey... we can leverage this..." and called their engineers to send bigger SHA strings to the web team. Why pass up on something that can be positioned as a competitive advantage, right? I predict that over the next few days or weeks web masters all over the world will be busy publishing bigger SHA hashes. Google will be pleased but ordinary folks around the world will be perplexed and people coding applications that utilize such hashes in security will be thinking... "OK... here we go again, Chinese fire drill iteration i of N..." The toms hardware article touches on how many people are displeased with Google for, in effect, promoting a threat that serves to drive people into Google's way of doing things, supposedly (according to the critics) to benefit Google's commercial interests in controlling the technology used by web sites. They may have a point in that, but if Google is using fear to herd people Google's way at least give them credit for not making stuff up out of thin air. But a review of the technical nuances shows there is no need to panic. Technical criticisms of SHA1 often revolve around two poles, one totally bereft of common sense and the other one a more genuine criticism that only becomes stronger and more valid over time. The first pole is that SHA1 as an algorithm does not guarantee a lack of collisions, it just makes them unlikely. That's a criticism that has zero common sense to it, because you'd need a million billion life times of the universe in seconds as a numeric analogy to the large numbers associated with the unreality of such a collision. A second pole of SHA1 criticism is that as a cryptographic technology it is vulnerable to breaking given enough resources. That criticism I think has been less strenuously advanced because the cryptographic community considers what it takes to break cryptographic methods and the cost of deliberately breaking SHA1 has been astronomically high. But the cost has come down. That Google was the first to publicly demonstrate this is not surprising given they can throw server farms with a million machines at a task if they like. With faster computation speeds the technique no longer takes Google-sized server farms. You can even say it is not really a Google-limited thing any more given that people can build desktop machines with over 14,000 GPU cores in them, as discussed in the Parallel GPU web page for Radian. It is true that 74 teraFLOPS on the desktop is genuinely godlike power to apply. Manifold is absolutely in the vanguard of promoting the use of massively parallel GPGPU to get supercomputer power on the desktop for cheap, and that's not just marketing talk exploiting fears but genuine, real-deal engineering. GPGPU really is that revolutionary. Nobody at Manifold is going to argue that big computations will always remain out of reach for ordinary people. But even with the Google announcement and even with the great leap forward of GPGPU there still is no practical threat, as yet, to the use of SHA1 to assure installation files do not have viruses. There are two reasons why: 1. We don't know the technical details, but it seems Google hasn't broken SHA1 in the general form of generating an SHA1 collision between two files of the same size. They apparently will publish code that can generate an SHA1 collision between two files of different sizes. If you have file A of 82,385,390 bytes with a given SHA1 hash the Google attack will teach you how to generate a file B of different size that has the same SHA1 hash. Generating a file B that is the same size as file A but also has the same SHA1 hash is more difficult. So an easy way to reduce the impact of the Google attack is to simply publish both the file size and the SHA1 hash. If hackers hang their hat on the inattentiveness of users to file size and hash code they don't need to mess with SHA cracking at all. Which brings us to the next point... 2. Even with GPGPU advances it makes zero sense for hackers to invest the money and effort into such a machine for the express purpose of computing SHA1 collisions when there are so many ways that are a million times easier to inject Trojans and malware into the computers of gullible users. Hackers are professional criminals or talented amateurs but they are not ideologues who might take a difficult, impractical way instead of a much easier path. They don't waste their time on absurdly labor intensive maneuvers when there are strategies which are, literally, millions of times easier and more profitable. For hackers it is just nuts and totally lacking in common sense to advance a malware strategy of computing SHA1 collisions for installation file downloads that change every few weeks and to try to use such collisions to launch a Trojan into systems when just about any elementary phishing strategy will be, literally, about a million times more effective and profitable. In fact, phishing is so easy and effective that the biggest problem hackers have with it is the overload, the total flood, of gullible victims it produces for them. How is it that pimply faced teenagers in Romania accumulate botnets with hundreds of thousands of computers? Because phishing is that effective in a world of people who mindlessly click on stuff. Heck, there is even less need for mindless people anymore to click on stuff since the new frontier in hacking is using mindless devices inhabiting the Internet of things, ranging from web cameras to routers to refrigerators and effectively all of them, untold tens of millions of them, all still using the default login and password assigned when they were manufactured. For those reasons, there's no practical threat from using SHA1 now and that threat could be kept to zero by publishing the file sizes as well as the SHA1 hash. Manifold won't do that because it is simply easier and way more trendy to publish a bigger hash, such as SHA256, than to mess about with publishing file size as well as hash code. Using a bigger hash is easy, effortless and has competitive advantages. Perfect! The move to SHA256 or any other bigger hash will be less convenient for anyone who actually wants to check the hash, since the numbers are bigger. But hey, that's progress, and nothing to complain about given the significant threat to the universe Google has selflessly revealed. :-) By the way, if anybody wants to check, here are the SHA256 hashes for the current installation packages: manifold-9.0.159-x64.msi - SHA256: e79858ff 2a157f4b ac7a7b7d 7c9d48d8 b877847c 310b9cb5 94e3c3fa 2f5cdaa6 manifold-9.0.159.msi - SHA256: 1d6579c2 b72faa99 7f402cc5 1f9280de 730c4f4a 4cc5d259 bf747e79 b8d4e071 manifold-9.0.159-x64.zip - SHA256: d2eae415 aa7e0921 0d72d95c 2d9b7a98 e4829878 dca6cf5a 0e476916 20f25b48 manifold-8.0.29-x64.zip - SHA256: 4d6c1cf0 17692891 3dc131a9 5c867c8e c9b11c5b 95a55711 424cac88 5980932b manifold-8.0.29.zip - SHA256: 5a5c7103 152de848 49687af3 31318ac7 1c30810f e6725f81 5e154100 2d865642 Use the built-in certutil utility (built into Windows 10, anyway...) to compute a SHA256 checksum in Windows: In the command window: C:\>certutil -hashfile manifold-9.0.159.msi SHA256 SHA256 hash of file manifold-9.0.159.msi: 1d 65 79 c2 b7 2f aa 99 7f 40 2c c5 1f 92 80 de 73 0c 4f 4a 4c c5 d2 59 bf 74 7e 79 b8 d4 e0 71 CertUtil: -hashfile command completed successfully.
|