SHAttered — SHA-1 is broken in

A team from Google and CWI Amsterdam just announced it: they produced the first SHA-1 hash collision. The attack required over 9,223,372,036,854,775,808 SHA-1 computations, the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations. While this may seem overwhelming, this is a practical attack if you are, lets say, a state-sponsored attacker. Or if you control a large enough botnet. Or if you are just able to spend some serious money on cloud computing. It’s doable. Make no mistake, this is not a brute-force attack, that would take around 12,000,000 single-GPU years to complete.

SHA-1 is a 160bit standard cryptographic hash function that is used for digital signatures and file integrity verification in a wide range of applications, such as digital certificates, PGP/GPG signatures, software updates, backup systems and so forth. It was, a long time ago, proposed as a safe alternative to MD5, known to be faulty since 1996. In 2004 it was shown that MD5 is not collision-resistant and not suitable for applications like SSL certificates or digital signatures. In 2008, a team of researchers demonstrated how to break SSL based on MD5, using 200 Playstations 3.

Early since 2005 theoretical attacks against SHA-1 were known. In 2015 an attack on full SHA-1 was demonstrated (baptized the SHAppening). While this did not directly translate into a collision on the full SHA-1 hash function due to some technical aspects, it undermined the security claims for SHA-1. With this new attack, dubbed SHAttered, the team demonstrated a practical attack on the SHA-1 algorithm, producing two different PDF files with the same checksum.

The full working code will be released in three months, following Google’s vulnerability disclosure policy, and it will allow anyone to create a pair of PDFs that hash to the same SHA-1 sum given two distinct images and some, not yet specified, pre-conditions.

For now, recommendations are to start using SHA-256 or SHA-3 on your software. Chrome browser already warns if a website has SHA-1 certificate, Firefox and the rest of the browsers will surely follow. Meanwhile, as always, tougher times are ahead for legacy systems and IoT like devices.

96 thoughts on “SHAttered — SHA-1 is broken in

  1. before people panic, remember there is a huge difference between being able to:

    create a collision between two documents that you create, both of which contain huge amounts of arbitrary binary data


    creating a collision between an existing document that someone else created, and a new document (let alone a new document that can’t contain huge amounts of arbitrary binary data)

    1. There is not actually such a huge difference between the two in the case of SHA-1, since SHA-1 is a Merkle function. The same thing happened with MD5 (also a Merkle function) and within a matter of years people had written all sorts of software to create MD5 collisions in meaningful files such as TLS certificates and executable binaries.

      1. yes, it was a matter of years before people were able to go from this ‘create two pdfs that differ’ to practical attacks. That will be the same thing here, so it’s not time to panic, sha1 signatures going to become utterly worthless in 90 days when Google releases the code for this.

        It’s another step in the process of sha1 needing to be obsoleted, but it’s ‘just’ another step in the process.

        1. It takes the internet 20 years to switch cryptosystems. If we have five years until SHA-1 is totally broken, then we’re 15 years behind. You think that having five years of lead time is reassuring. I think it’s terrifying.

          1. It took a lot less than that to replace md5 with sha1, what makes you think it will take 20 years to replace sha1 with sha256?

            It’s not like people haven’t known that this is coming, and sha1 has already been replaced in many areas (you haven’t been able to get a new cert with sha1 for a while now for example), so it’s not that we have not been thinking about the issue and starting the transition.

          2. yawn, and anyone managing a system turns off a bunch of obsolete, insecure protocols, this is just one of several dozen.

            There are lots (over a hundred IIRC) protocols that can be used by TLS, when a new one is added, you can’t turn off the old one or you break compatibility during the transition, so the code is there for all the old protocols.

            But the list of what ones are safe to use changes year to year, and you change the list of what you accept.

            Yes, people who just install stuff and leave it at the default settings aren’t secure, but they never have been. Even if the defaults were changed to be secure today, in a year or so they would be wrong.

            My day job is computer security, so this is directly in my area of expertise.

            the fear mongers are almost always overstating the risks/impacts. This is a significant step forward, but it’s far from the end of the world, and people should not panic, just take note and make sure they have switched off of sha1 (if they can), and if they are running something that still depends on it, re-prioritize their efforts to move away from it.

          3. This is not about general purpose computers. This is about embedded hardware that is very expensive to replace. You’re not seeing the big picture here. We should have started this process in 2005. Not now.

          4. you don’t have to replace the IoT hardware, you just need to update it’s software.

            and if you aren’t doing that (and unfortunately, that’s the common case for IoT), then you have a ton of other vulnerabilities such that a hash collision probably isn’t in your top 100 threats.

            in fact, most IoT things don’t do any encryption, so they are not affected by any sha1 vulnerability.

      2. And by “people had written all sorts of software”, you mean one team got one TLS certificate. They also had to exploit other shortcomings in the CA’s process too, like sequential sequence numbers and they were directly signing user supplied text. There’s been much larger failures in the CA system than that. So, yes, there is a huge difference in the requirement that the attacker has control over both documents.

        1. Many teams got many certificates. The flame collision was completely independent of the Lenstra collision, and those are only the ones we know about. And people also demonstrated attacks having nothing to do with certificates.

          1. The claim “X is secure” or “X is insecure” is meaningless. That is just sloppy terminology Secure for what use and against what attack?

            If I go to the openssl website, they offer OpenSSL 1.1.0e for download, and give the SHA-1 hash as 8bbbaf36feffadd3cb9110912a8192e665ebca4b. Assuming I check this, you cannot give me a phony OpenSSL package without generating a second pre-image.

            Many TLS ciphersuites use HMAC-SHA1 for record authentication. But that is OK. Because HMAC is not broken by collisions.

            Security protocols such as TLS and IKE sign part of the transcript to prove ownership of a certificate. This use is not affected by collisions either.

            In fact, there are few uses of hash functions that are broken by collisions. The web PKI would be vulnerable, but they switched years ago. Email signatures (PGP or S/Mime) are vulnerable to repudiation attacks. There are a few more. Exaggeration and hyperbole are not in order.

          2. I don’t suppose you’ve ever lived a day in a cryptographer’s shoes? Because the level of detail that you’re delving into in an attempt to defend SHA-1 is just going to go way over the head of any customer or client.

            If the whole world were run by cryptographers then I would grant your argument. We cryptographers can easily keep track of which hash functions are safe for “what use and against what attack” (your words).

            The minute you hit the real world with your advice, it all falls apart. No customer is ever going to remember that ten years ago you once told them that SHA-1 was safe for X use against Y attack but unsafe against A use for B attack.

            What’s going to happen is that they’ll initially set up SHA-1 for X use against Y attack, and they’ll keep using SHA-1 even if their usage model evolves to A use against B attack, for which SHA-1 is totally inappropriate. They’ll keep using SHA-1 forever, unless you strongly insist otherwise. It’s human nature.

            There is no possible responsible messaging at the present time that involves telling someone SHA-1 is OK. This is not hyperbole. It wasn’t even hyperbole back in 2005. We saw this coming from a mile away. This is nothing more than a cold cost/benefit calculation. SHA256 just isn’t that expensive anymore.

          3. What you don’t seem to understand is that nobody is saying that SHA1 is perfectly safe, all we are saying is that the claims that this means the end of the world and that all git repositories can no longer be trusted is panicked overstatement of the facts.

            everyone has been in agreement for years that you should not use sha1 in new designs. This is ‘just’ an incremental (and expected) step along the path of sha1 becoming less useful.

            security is not binary, it’s a continuum. The people in the security field that try to claim it’s a binary are doing everyone a disservice.

            Along similar lines, a hash being ‘good’ or ‘bad’ is not a binary thing either, it’s also a continuum.

          4. Unfortunately, not everyone is in agreement that we should not use SHA-1 in new designs. Linus deliberately used SHA-1 in git, even after being advised that this was unwise. We knew full well back in 2005 that SHA-1 was on the weak end of the continuum. That doesn’t mean git is useless. It just means that this entire scenario was completely avoidable at no cost had git done the right thing at the outset. Now it’s going to cost a lot to switch away.

          5. Please get your timeline straight

            Linus created git using SHA1 in April 2005, in August 2005 there were theoretical weaknesses identified.

            In 2007, NIST started a contest/evaluation to select the replacement for SHA1

            So that puts a validated, recommended replacement for SHA1 at ~2010

            it’s really silly to argue that 5 years prior to that, Linus should have known what the result would be and picked that algorithm instead.

            In 2006, Linus wrote the e-mail I linked to that showed that even if sha1 was trivially breakable, it wasn’t a fatal break in git (and he posted a new message on the topic this week). This isn’t saying that SHA1 has no problems, or that git shouldn’t take steps to replace sha1 with something else, just that attacking git repositories through sha1 collisions runs up against a lot of other defenses, so it’s not the end or the world.

            The git community has been talking about this off and on for many years, there have been many proposals put forward, along with identifying the problems with all of them.

            This week, they have added tests that will identify collisions faster, and the discussion on what is needed to migrate to a new hash has been revived.

            NOBODY is saying that there is no need to migrate to a new hash, but even now it’s not a trivial answer to say what the right thing to migrate to would be.

            All that anybody is saying is that it’s not time to panic, this release does not make all git repositories trivially corruptible without detection or any of the other horror scenarios that the press has been passing along.

          6. > Linus created git using SHA1 in April 2005, in August 2005 there were theoretical weaknesses identified.

            Theoretical weaknesses in SHA-1 were published in **February 2005**. Proof:

            > In 2007, NIST started a contest/evaluation to select the replacement for SHA1

            SHA256 was available long before 2005.

            > In 2006, Linus wrote the e-mail I linked to that showed that even if sha1 was trivially breakable, it wasn’t a fatal break in git (and he posted a new message on the topic this week).

            He’s wrong, for the reasons I gave already in another comment thread.

    2. I wouldn’t necessarily say that a 400kB file contains huge amounts of binary data…

      While I agree that the impact of this in practice may be somewhat limited (at this point in time), this is definitely not something you’d want to have happen to a cryptosystem in active use, especially if there are safer alternatives.

      1. where did you find info that the files are only 400KB? I haven’t found a link to the files themselves.

        Yes, people should be working to move away from the use of sha1, I was just saying that it’s not time to panic

          1. “ANY hash function based on the Merkle design is TOTALLY AND COMPLETELY BROKEN once the first collision is found”

            It is broken for one specific use – hash for a long term digital signature. The fact is that we have yet to see a pre-image attack on MD5, and we have no better pre-image attack on SHA-1 than the brute force.

            And SHA-256 is also a Merkle design

          2. > It is broken for one specific use – hash for a long term digital signature.

            There is more than one specific application that requires collision resistance. Wikipedia alone lists three: (and there are others).

            > The fact is that we have yet to see a pre-image attack on MD5, and we have no better pre-image attack on SHA-1 than the brute force.

            True, but irrelevant. A hash function should not be used once a collision is found. If it must be used, which I stlil can’t recommend, but if you MUST, then the correct approach is a WHITELIST-based application filter. For example, HMAC-MD5 is still safe. HMAC-SHA1 is still safe. These specific applications have been proven secure even without collision resistance. But one should never use a blacklist-based filter, such as what you proposed. If you think “everything but digital signatures is safe” then you’ll get into big trouble.

            > And SHA-256 is also a Merkle design

            Correct, but the difference is that SHA256 has no known collision.

          3. “ANY hash function based on the Merkle design is TOTALLY AND COMPLETELY BROKEN once the first collision is found”

            It is broken for one specific purpose – long-term digital signatures, mostly just PKI.

            After all these years there has still not been a practical pre-image attack on MD5. And we’re not even making progress on that front against SHA-1. Also, SHA-256 is a Merkle design as well.

    3. Who cares, anyone with a modicum of sense should have started moving away from SHA1 and MD5 years ago.

      Just ditch them and move on, I honestly don’t see why people are holding on to such broken relics.

      1. There’s this little thing called interoperability where you need to talk to other people, so this means that you can’t just instantly ditch something that other people use, you have to first implement the replacement (in a way that will continue to interoperate with the old version), and then sometimes later you can replace it.

        This can be a non-trivial effort in some cases

      2. Many people “hold on to broken relics” because they don’t know or don’t care, or because they way overestimate the value of preserving backward compatibility. Perhaps 10 years ago they paid their nephew to build them a website, and that’s what they still have. If they get a notice from their certificate authority that says “MD5 is broken, switch to SHA-256.” they either ignore it, or they read the part that includes some disclaimer like: “Some older browsers won’t work with SHA-256, click here to continue to maintain support for MD5 [_] (not recommended)”

      1. It depends. If you use pgp signed commits (which are not too widespread atm) then yes, security depends on sha1 being secure. Usually git is fine though as long as collisions don’t happen during normal use.

        1. read the e-mail from Linus on the topic (linked to slightly below), it is an analysis of what it would take for an attacker to cause problems with git operating under the assumption that creating a new file that collided with an existing file was a trivial thing to do.

    1. Linus doesn’t know crypto. His entire post assumes that SHA-1 collisions will consist of meaningless junk data. That’s just not true, and the reason it’s not true is because SHA-1 is not a random function. SHA-1 is a Merkle function, which has a lot of exploitable large-scale structure.

      Look, I don’t know operating systems. I would never presume to lecture Linus on operating systems. Likewise, Linus doesn’t know crypto. He shouldn’t go around lecturing others on this topic. He’s completely wrong.

          1. he explanation assumed that generating a sha1 collision with an existing document (a pre-image attack, not what was shown by Google) was a trivial thing, and showed why that did not matter to git.

            People have been offended by this and claimed that he is wrong since he wrote it, but they’ve never been able to show anything he was wrong about, they only do the same thing you did and claim he doesn’t know what he’s talking about.

        1. Why haven’t any of the ‘crypto experts’ refuted his explanation? Might have something to do with his personality :P
          Andy Tanenbaum disagreed with Linus once. They’re still fighting as we type.

      1. Here’s a run down of how git works.

        You add a bunch of files, they are hashed, hashes are compared to old hashes if different you upload the new files.

        Now lets say I pull your git repo.

        I edit a file to have different contents but the same hash.

        I push and git _ignores_ all my new files.

        The collisions will make your git repo lose track of changes (fuck your local up) but importantly you can not get git to upload these changes to a remote.

      1. they actually demonstrated a collision between two PDFs with almost identical content (the color of the background of an image is changed)

        They say that creating these two documents took the equivalent of 6500 cpu-years or 110 gpu-years vs the brute-force version that would have taken 12,000,000 gpu-years for a plain birthday attack

    1. There are multiple stages in breaking a hash

      the first stage is creating two completely arbitrary binary blobs that collide (this happened for sha1 in 2005)

      the second stage is creating two files that are in a valid format (but allow hiding arbitrary binary data in them) that collide (this is what Google is reporting)

      being able to create a file that has an arbitrary hash (needed to create a collision with a document someone else created) is a FAR harder task

      being able to create a file that has an arbitrary hash and is a functional document is a step beyond that (and the increase in complexity depends on how much arbitrary binary data is allowed in that file format)

      .pdf is a format that is frequently multi-MB and allows arbitrary binary data to be put in it and ignored when rendering the document. This makes it a favorite format for moving from stage1 to stage2.

      I’m not sure that even MD5 (long considered broken) has progressed to the point where it’s possible to create small files that match an arbitrary hash

          1. I am determined to correct the facts when you assert something that is plainly incorrect.

            Under your false timeline, a collision was found in 2005 and it took 12 years after that to find a meaningful collision. THAT IS COMPLETELY WRONG. No collision was found in 2005. What was found in 2005 was the algorithm that could be used to find a collision. It did not take them 12 years to go from the first collision to the first meaningful collision. It took 0 days.

            Read the first line of this hackaday article, for Christ’s sake. It says right in the first sentence:

            “A team from Google and CWI Amsterdam just announced it: **they produced the first SHA-1 hash collision.**”

            No hash collision was found in 2005. This one is the first.

  2. The danger of this depends on what you are using SHA-1 for. If you are using it to identify duplicate files for some sort of housekeeping, you are fine. If you are using it to verify that a file hasn’t been altered for some sort of legal proceeding, you might have a problem. If you are using it to authenticate orders in some sort of global espionage agency, you have a real problem.

    1. keep in mind, this is only step 2, where the attacker gets to create both versions of the document in question. That vastly decreases the number of places where it’s a problem.

      When they get to the point where they can create a new file that has the same hash as a file they didn’t create, then there is far more of a problem

      As far as your legal concerns go, these collisions require that there is a huge amount of hidden data in both files, so it would be pretty easy to show that something fishy is going on and call the file creators credibility into question.

      1. “As far as your legal concerns go, these collisions require that there is a huge amount of hidden data in both files, so it would be pretty easy to show that something fishy is going on and call the file creators credibility into question.”

        I’m trying to grasp how one can consider it acceptable to have plaintiff and prosecutor bicker in court if some files when inspected in binary do or don’t look “as if there is a huge amount of hidden data” and to what extent they do or don’t “look fishy”… aye, that surely is the way cryptographically secured forensic data is supposed to be used in court.

        on the other hand, I can imagine a couple of lawyers and judges welcoming the regained power of declaring data “huge, hidden and fishy” and develop fine tastes -certainly not based on ad hoc whims or conflicts of interest- to the point of becoming self-declared connoisseurs in data-pristine-ness…

        1. Forgive me if I’ve got the wrong end of the stick, here….

          But imagine the case of a file that’s been signed with a cryptographic key. The file itself is still an ordinary plain file, just with a signature attached. Say it’s an .html file. You can look at the .html file, and see some HTML at the beginning, halfway through there’s a [/html] tag (not gonna try do angle-brackets here). Then after that there’s kilobytes or megabytes of random stuff at the bottom, just to make the hash add up right.

          Anyone will be able to see that. HTML is an easy example, if not that, then say JPG, same thing, or MP3 or whatever. It’s easy to tell apart the useful part of a file, from special hash-altering padding.

          So in the case of a court case arguing over the veracity of a signed document, a specially-padded file would show up pretty obviously.

          1. It would be easy to tell if it were an HTML file. Not so easy if it’s a signed binary firmware. And by the time you start listing different categories of safe and unsafe input, you might as well just discard the entire hash function and use a better hash function instead.

  3. Douglas Hofstadter anticipated this struggle in his seminal book, Gödel, Escher, Bach: An Eternal Golden Braid in the so-called Record Player dialogs. He also showed that the fight will go on forever because security cannot win as a consequence of Gödel’s incompleteness theorems. While what we are seeing here with this is not in and of itself an existential threat, the fact is nothing can keep us safe from one in this domain.

  4. SHAppening is a meme derived from the “fappening”, where a lot celebrity nudes was unleashed on the internet. Why this “Xppening” meme is still being practiced? I don’t know. All I know that this post will make it through moderations(i hope…)

    1. SHAppening is not derived from fappening — it is actually derived from happening which means: “an event or occurrence.”

      In this case SHAppening means: “an event that occurred involving SHA-1”

  5. @davidelang:”you don’t have to replace the IoT hardware, you just need to update it’s software”
    “in fact, most IoT things don’t do any encryption, so they are not affected by any sha1 vulnerability.”
    @DJ: “There is stuff out there that predates the term “IoT”. Also, hash functions are not encryption.”

    Of course, hashing algorithms should not be used for encryption they should only be used to generate checksums and to verify authenticity of the data (with the purpose being to ensure that data was not altered in transit and is exactly what a server certificate is designed to do).

    Furthermore, just because Iot devices don’t use encryption doesn’t mean they aren’t vulnerable — because they are very much vulnerable to a lot more than just a hashing algorithm vulnerability. People see all the data in plain text and if there is any sensitive/secret information (such as account logins or other data) it is now in the public-domain and they can easily modify the data to do something since they can understand the context of the information.

    Also, it’s not an easy feat to update iot software — mostly because the manufacture of the device will create it, send it to market, and immediately abandon it (which means there is no new/updated software to install).

    Because of that, it requires after-market reverse engineering to create new software/firmware.

    To make Iot truly secure and to keep the device up to date– the manufactures must support it through the lifetime of the device (which they have not been doing).

    1. as I said, for IoT devices, a sha1 vulnerability is not a big deal, either the software can be updated, or there are much bigger problems than a sha1 collision.

      it’s not just reverse-engineering the software, it’s figuring out how to load the replacement software onto the device.

      IoT vendors spend far more effort trying to prevent others from replacing their firmware than they do making it secure (or providing a legitimate way to update it)

      1. If the iot vendors are actively thwarting attempts to replace the firmware and are obfuscating it as well, then it means reverse-engineering is necessary to figure out how to load new firmware (how to get around the restrictions imposed by the vendor).

        This is a good example of how replacing the hardware is far easier that replacing the software for the average consumer.

      2. I also doubt that the average consumers (who make up the bulk of iot users) will have the necessary expertise or skills to load unofficial replacement software onto the device.

        It’s also cheaper for a company to roll-out an entirely new device than it is for them to update an older one.

  6. From a practical point of view both MD5 and SHA1 are still valid hash codes. These collisions have found, after a lot of computation, only 2 files with the same hash. This is not the same as given a certain file create a second one with the same hash. Further more to be a valid attack vector the newly created file should do something meaningful like a modified source code or modified firmware doing something useful, not just some randomly changed bits.

    This news is probably important for matematicians and crypto people, you won’t see any hash function exploit anytime soon.

    1. Once you get two files with the same hash, generating any number of further collisions costs almost nothing, since MD5 and SHA1 are Merkle (iterated) hash functions.

      The two files that were published are “meaningful” files with the same hash. They are valid PDF documents. The paper describes how to take any two PDF documents A and B and combine them in two different ways to get two documents X and Y with the same hash, where X displays A and Y displays B. This operation does not require a lot of computation. The ONLY thing that requires a lot of computation is the initial collision.

        1. You’re describing a preimage attack. The current attack is a collision attack. It is absolutely not true that security against preimage attacks is sufficient. Enormous amounts of mischief can be achieved using only a collision attack. No serious cryptographer would ever agree with the statement that SHA-1 is still secure just because there’s no preimage attack.

          1. I’m not claiming it’s a secure hash, but from a practical point of view there is nothing to worry about. Typical use for a hash is to digitally sign the hash of a piece of code or firmware or the source code for a project. Since no one can produce a malicious version of said firmware which has the same hash the chain o trust is still preserved.

          2. Digital signatures of source code repositories cannot be trusted if the attacker is allowed to contribute to the repository, as is the case for many open-source programs. The attacker might find two pieces of source code where the first piece is benign (and passes code review) and the second piece is malign, with the same hash. They submit the first piece, it passes, it gets signed, and now all of a sudden that signature is a valid signature for the second, malicilous piece of code. No preimage attack is needed, only collision. Moreover if the “source code” contained binary firmware blobs, which is common, then it would be easy to hide a hash collision inside.

            Once you start saying that a hash function is still good for scenarios A, B, and C, but no good for scenarios X, Y, and Z, the battle is already lost. No user should need to keep track of which usages are “safe” and which ones are unsafe. As code gets modified it is all too easy to transition from a safe usage to an unsafe usage without anyone noticing. There is no good solution except to avoid SHA-1 entirely.

  7. Ironically and md5sum shows a difference in the two pdf’s. Maybe multiple checksums could be used as secondary comparison.

    Would it be possible to have both md5 and sha-1 sums match for these files.

  8. In 5 to 10 years all of our current common use encryption will be broken by using quantum computers anyway (and not just collisions).

    I didn’t read too much off site but Google shares one of the largest quantum computers with the NSA. You know, a partnership between an organisation that has the greatest desire for peoples personal information and an organisation that has the most personal information on the public. Nothing to see here! Move along!

    1. That D-WAVE computer is far from being able to run Shor’s algorithm though (I believe), and there is no way to see form that quantum annealing computer to one that can (I believe so far).

      So while it’s probably a quantum computer, it’s not the quantum computer most of us want.

      1. It’s early days for quantum computers yet.

        Your approach seems to be the approach that you would expect for traditional computing. While future quantum computers will be capable of traditional computing, there will great advantage with tasks like cryptology to use an approach that is specific to quantum computers.

  9. IoT may be a thing but it’s not *everything* that communicates to remote devices.

    IoT has become such a buzz word that it is now often incorrectly used.

    Most of what people are calling IoT is actually M2M technology.

    The security considerations are different for these two different technologies.

  10. From:

    With a picture of the cheap GPU cluster named Kraken:

    We recommend that SHA-1 based signatures should be marked as unsafe much sooner than prescribed by current international policy. Even though freestart collisions do not directly lead to actual collisions for SHA-1, in our case, the experimental data we obtained in the process enable significantly more accurate projections on the real-world cost of actual collisions for SHA-1, compared to previous projections. Concretely, we estimate the SHA-1 collision cost today (i.e., Fall 2015) between 75K$ and 120K$ renting Amazon EC2 cloud computing over a few months. By contrast, security expert Bruce Schneier previously projected (based on calculations from Jesse Walker) the SHA-1 collision cost to be ~173K$ by 2018. Note that he deems this to be within the resources of a criminal syndicate. Large corporations and governments may possess even greater resources and may not require Amazon EC2. Microsoft, Google and Mozilla have all announced that their respective browsers will stop accepting SHA-1 based SSL certificates by 2017 (and that SHA-1-based certificates should not be issued after 2015). In conclusion, our estimates imply SHA-1 collisions to be now (Fall 2015) within the resources of criminal syndicates, two years earlier than previously expected and one year before SHA-1 will be marked as unsafe in modern Internet browsers. This motivates our recommendations for industry standard SHA-1 to be retracted as soon as possible. With our new cost projections in mind, we strongly and urgently recommend against a recent proposal to extend the issuance of SHA-1 certificates with a year in the CAB/forum (discussion closes October 9 2015, vote closes October 16).

    1. if it’s not exposed to the outside world, it doesn’t matter if the hash is insecure.

      google also uses git (they employ the git maintainer)

      the perforce they use is so heavily customized to hardly be recognizable

      I worked there for a while.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s