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 …

[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.

[Anonymous Coward]

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.

[DuncanLarge]

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?

[Anonymous Coward]

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)?

[DuncanLarge]

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.

[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.

[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?

[Lee D]

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.

[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..

[EnviableOne]

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

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

[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?

[Vincent Ballard]

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

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

[A random security guy]

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

Come again?

[DuncanLarge]

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.

[phuzz]

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.

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

[MiguelC]

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

Don't let Trump know about that!

[vtcodger]

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.

[GnuTzu]

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.

[Alister]

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.

[NoneSuch]

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.

[GnuTzu]

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.

[Carpet Deal 'em]

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

[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.