back to article Hash snag: Security shamans shame SHA-1 standard, confirm crucial collisions citing circa $45k chip cost

SHA-1 stands for Secure Hash Algorithm but version 1, developed in 1995, isn't secure at all. It has been vulnerable in theory since 2004 though it took until 2017 for researchers at CWI Amsterdam and Google to demonstrate a practical if somewhat costly collision attack. Last year, crypto-boffins Gaëtan Leurent, from Inria in …

  1. Bitsminer

    Other Problems

    Git doesn't use SHA-1 for a defence against attackers, it uses it as a database key for each file.

    If an attacker can rewrite files in your git repo, even if going to the trouble of duplicating a hash, you definitely have Other Problems.

    1. TechnicalBen Silver badge

      Re: Other Problems

      Yeah, old/insecure things like this can be used for things that don't need security (so as you mention, a plain old hashing for indexing system). However, I guess the risk is people use it as "good enough" and don't bother checking it's security if it's still available and not forced in upgrade/change.

    2. DuncanLarge Silver badge

      Re: Other Problems

      > Git doesn't use SHA-1 for a defence against attackers, it uses it as a database key for each file.

      This is incorrect. Git uses the SHA-1 hash to confirm the integrity of each commit blob which also serves as an identifier for that blob. Thus if a commit is modified, you know because it gets a unique hash. Thus GIT does use SHA-1 to defend against an attacker as it is the way you know a file has been tampered with. If it worked properly a miscreant modifying a file WOULD NOT be able to have that modified file masquerade as a previous, valid commit.

      So if you stay with SHA-1 in GIT you basically let those who do manage to get in via your "other problems" to go around as the invisible man modifying the target code with nothing but the kluge collision detection code that currently is used. Well why not also find a way to turn that code off as part of the attack? Then what do you have as your defense?

      Once someone is in your GIT repository and have disabled your collision detect kluge and they can generate the collision they want to insert their version of a commit, the only defense you have left is the fact they must distribute that to all other repositories.

      That's your only defense, a bit of difficult to do stuff. Which if they have got this far, getting inside, generating a collision, other stuff, then whats one one item to tackle?

      Personally I would like them getting in the front door to be tough, then walking down the corridor to be scary and bloody with attack dogs running at them, way way before they manage to get to the door they need to enter to insert their collision only to find its made of plywood because someone thought the dogs would be enough. I want that door made of good solid english oak with Arnie standing in font of it, then beyond that door is a fire pit 50 metres deep...

      There is no reason to continue using SHA-1. I use SHA-256 for file hashes and have done so for years. I also took a look at if there was a speed difference when computing a hash. I found none that was significant, although it was just my desktop and my personal files, not thousands of files being modified every day but with current server and even desktops with 64 cores there really shouldn't be a problem.

      But a plywood door would be cheaper, as long as its hard to distribute the change to all other repositories. Till it becomes easy. Then who will answer for the plywood door?

      1. TechnicalBen Silver badge

        Re: Other Problems

        Wait... really? Is that attempt at seeing changes to files for convenience, or for security?

        As the OP mentioned, if someone has write access, is the sha-1 for confirmation of miscreants attacking, or just to track *known good changes*?

        Is there a different layer for security (IP access/logins/etc)?

        1. DuncanLarge Silver badge

          Re: Other Problems

          Its for both.

          Thats the point of having this mechanism.

          If it isnt, then there is a design flaw that needs addressing.

          1. Crypto Monad

            Re: Other Problems

            Two points:

            1. git allows signed commits and tags to record the authenticity of a commit. This relies on the SHA-1 for integrity. If you can't trust the SHA-1, you can't trust the signature.

            2. with git, you necessarily don't need direct write access to someone's system to mess their data - only the system which they pull from. This could be some cloud service or some self-hosted server.

  2. Anonymous Coward
    Anonymous Coward

    Is there a database somewhere keeping track of these 'deprecations' ?

    "miscreant-in-the-middle"

    But if all men are miscreants, why change at all?

    1. Lee D Silver badge

      Re: Is there a database somewhere keeping track of these 'deprecations' ?

      I keep saying that we need a website, with a queryable API, that returns things like:

      MD5: Insecure.

      WEP: Insecure.

      SHA-1: Vulnerable.

      SHA-256: Viable.

      And that everyone can query. Then you can have things like deprecation warnings for any software that is using them and cares to check as soon as vulnerabilities come to light.

      1. An nonymous Cowerd

        Re: Is there a database somewhere keeping track of these 'deprecations' ?

        There are of course slightly differing interpretations of secure/insecure (elliptic curves etc) and much subtlety, even just pre-QC.

        I think a main international standard list is transmitted by ESI ALGO from the Electronic Signatures and Infrastructures (ESI) group at the European Telecommunication Standards Institute (ETSI)

        perhaps their documents are publicly available somewhere?

        I seem to have found 2019 here

        https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?wki_id=56765

        excellent work by Ernst & the team (of which I was a brief member)

        "ETSI TS 119 312 V1.3.1 (2019-02)" and it is very readable, but more nuanced than an API

        a sort of flowchart "keylen" chart exists here, that might be scriptable https://www.keylength.com/en/1/ (also available in french)

        but none of these factor in the most important vuln which is simply the available budget of your 'opponent', as some groups are allegedly approaching infinite budget, then plan accordingly..

      2. EnviableOne Silver badge

        Re: Is there a database somewhere keeping track of these 'deprecations' ?

        you forgot TKIP and WPA2 and WPA3 all insecure, no fix yet

      3. Crypto Monad

        Re: Is there a database somewhere keeping track of these 'deprecations' ?

        > I keep saying that we need a website, with a queryable API, that returns things like:

        >

        > MD5: Insecure.

        And the authenticity of the response from the website will be verified how, exactly?

    2. Vincent Ballard

      Re: Is there a database somewhere keeping track of these 'deprecations' ?

      https://valerieaurora.org/hash.html?

  3. A random security guy

    Linus Torvalds dismissed concerns about attacks on Git SHA-1 hashes

    Come again?

    1. DuncanLarge Silver badge

      Re: Linus Torvalds dismissed concerns about attacks on Git SHA-1 hashes

      He did a very, very long time ago when men were real men and wrote their own device driver.

      It was in 2005, basically the GPU prehistoric ages.

      1. phuzz Silver badge
        Stop

        Re: Linus Torvalds dismissed concerns about attacks on Git SHA-1 hashes

        It was in 2017, as linked in TFA.

        I'll link it again here for you because you missed it the first time.

    2. Bill Gray

      Re: Linus Torvalds dismissed concerns about attacks on Git SHA-1 hashes

      I am reasonably certain that Linus' point was that for this particular purpose, the hash needed to be fast and reasonably "random" in its output. It didn't need to be cryptographically secure.

      I think some of my fellow commentards are thinking of hashing solely in terms of security (which is the use that gets most of the attention). Hashing gets use beyond that. Some hash functions (such as that used in the Linux ext3 system) are almost trivially insecure; they are for use in hash tables for indexing data. Personally, I've had cause to use a ludicrously insecure hash function in my astronomy software. I needed maximum hashing speed (the function was a performance bottleneck) and a good enough output to avoid collisions. Security was not an issue.

      (I should note, though, that I'm taking Linus' word that the hash function for Git falls into this category. If so, I could easily see him saying : we've got the SHA-1 code sitting around; it works; we don't care if collisions can be engineered; let's use it.)

  4. MiguelC Silver badge
    Trollface

    "Microsoft's (...) implemented collusion detection"

    Don't let Trump know about that!

    1. vtcodger Silver badge

      collusion detection

      "collusion detection" sounds extremely useful. OTOH, I wouldn't be surprised if research in that field wasn't kind of dangerous. There could well be powerful interests who would prefer that collusion remain undetected.

  5. GnuTzu Silver badge

    Statistics

    I can confirm that there are plenty of sites on the Internet that have there TLS settings set such that they can't do better then SHA-1. That is you won't be able to connect without allowing it.

    So, what's going to motivate them to get of their butts and update their configurations? Do browsers need to start nagging users even more? (Anyone know of a browser plugin to alert for weak TLS configurations?)

    Qualys is a good place to test and study this. I just wish there were better ways to get lame sites to step up and manage their security better.

    1. Alister Silver badge

      Re: Statistics

      I can confirm that there are plenty of sites on the Internet that have their TLS settings set such that they can't do better then SHA-1. That is you won't be able to connect without allowing it.

      I don't see your problem. If fewer and fewer people are able to connect with current browsers, eventually they'll either have no visitors, or they'll realise there's a problem and fix it.

  6. NoneSuch Silver badge
    Linux

    The Cycle Continues...

    Government issues new crypto standard, says it's safe to use.

    Years later, scientists and boffins break that crypto.

    Government issues new crypto standard, says it's safe to use... ad nauseaum.

    1. GnuTzu Silver badge

      Re: The Cycle Continues...

      Well, Moore's law unavoidably plays into the story. The question I have is: when will adding bits to the SHA family finally be insufficient?

      Oh, and I suppose you'd be wanting to know if the World should be standardizing on something invented by one particular population-monitoring government agency. The response to any paranoia in this area should be the invention of algorithms not controlled by some particular government agency or corporation. Let's see which crypto geniuses are willing to step up.

      1. Carpet Deal 'em Bronze badge

        Re: The Cycle Continues...

        SHA-2 and SHA-3 are already different algorithms; the extra bits help, but they're not the main source of security. There are also other algorithms out there in active use(eg, WHIRLPOOL and BLAKE2).

  7. nagyeger

    File length and Multiple hashes??

    Back when MD5 was first getting broken, it was reported that MD5 + file-length was much more secure (for a given value of 'much more'). But most implementations of hashes are still not bothering to record file size. It seems like a no-brainer to spend a few extra bytes to include the file size in any checksum output. I mean, in terms of data integrity, if the checksum file / metadata says it ought to be 32GB and it's actually 10kB, then I don't care what the SHA1 of the thing is, it's not the original file, stop wasting my CPU cycles.

    I'd also think, not being a crypto-maths geek, that unless there are some underlying mathematical similarities I'm not aware of, identical file size plus SHA1 plus MD5 is going to make deliberate collisions much much harder.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2020