SQLite Forum

Suggestion: Use strong hashes on the download page
Login

Suggestion: Use strong hashes on the download page

(1) By anonymous on 2020-07-26 14:52:03 [link] [source]

The download page provides SHA-1 hashes for the files that it offers. I'd like to suggest switching to a stronger hash that is not broken. For more information please refer to the Q&A on the linked website.

(2) By Ryan Smith (cuz) on 2020-07-26 16:14:08 [link] [source] in reply to 1

I'd like to suggest switching to a stronger hash that is not broken.

Calling SHA1 "broken" are we? Please demonstrate.

Quoted from the linked Site:

  • This:

Who is capable of mounting this attack? This attack required over 9,223,372,036,854,775,808 SHA1 computations. This took the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations.

  • and this:

How widespread is this? As far as we know our example collision is the first ever created.

  • and this:

Has this been abused in the wild? Not as far as we know.

110 CPU years... SQLite's release cycle alone will thwart any prospective attacker.

To leverage this attack against SQLite someone will have to spend considerably more resources than the average attacker possesses and even then, after having successfully crafted a SHA1 for the code, all of which are considerably larger than the PDF used in the demonstration (upon which the attack figures is based), then such an attacker also has to successfully hack the SQLite servers and post such code on there.

I'm all for changing to a different completely un-attacked hash algorithm, but the notion that the current implementation is in any way unsafe or broken is just silly. When people start calling security of any system "broken", "shattered" or "we're just inviting criminals now", my normal response to such claims is: Prove it. Break it.

I'll afford the OP an even easier challenge: Forget for a moment the need to break into SQLite's servers - but simply show me an amalgamation (freely downloadable) with added demonstrably malicious code and the same SHA1 hash as the on-line posted one. (I'll even accept it if you got help from those folks who fashioned the PDF's colliding hash). Upon that I will rescind my voice on the matter, eat my own hat, and completely join the band of protestors wanting an upgrade to that hashing algorithm soonest.

Until then, when requesting people to do work for no valid proven reason at all, kindly accompany any such request with a substantial monetary donation.

(3) By Warren Young (wyoung) on 2020-07-26 18:46:28 [link] [source] in reply to 2

Please demonstrate.

In addition to the SHAttered attack, we also have more recent the SHAmbles attack.

110 CPU years... SQLite's release cycle alone will thwart any prospective attacker.

You're making the assumption that an attacker can use only one CPU. There are several cloud services that will happily rent you 110 CPUs for a 1-year attack, 220 for a half-year attack, 440 for a quarter-year attack, etc.

Aside from that, you're using numbers from an old attack. The SHAmbles attack was made using US $45000 in processing time last year. Tell me there are no entities willing to spend that kind of money to provide vulnerable versions of SQLite to a large chunk of the Internet population.

after having successfully crafted a SHA1 for the code, all of which are considerably larger than the PDF used in the demonstration

I doubt the cost of the attack is dominated by the size of the object to be hashed, particularly for any sort of aggregating file format like Zip or Tar. I expect that an attacker should be able to produce the "base" file and then extend it until they get a crafted match.

Forget for a moment the need to break into SQLite's servers

...as you must, since if you can do that, then you don't need any of these attacks at all! You can just upload whatever you want and change the hash, since they're served from the same place.

That's the problem with this whole idea of hashed downloads. I don't understand why anyone has any confidence in them.

Now, if there were some sort of trusted third party who would download things, check them, hash them, and serve up their own hashes, that might be valuable, but I'd expect to pay enterprise IT service sort of prices to get it.

Upon that I will rescind my voice on the matter, eat my own hat, and completely join the band of protestors wanting an upgrade to that hashing algorithm soonest.

You're asking someone to spend another $45000 when someone's already done something equivalent.

(4) By Richard Damon (RichardDamon) on 2020-07-26 19:02:13 [link] [source] in reply to 3

Forget for a moment the need to break into SQLite's servers ...as you must, since if you can do that, then you don't need any of these attacks at all! You can just upload whatever you want and change the hash, since they're served from the same place.

That's the problem with this whole idea of hashed downloads. I don't understand why anyone has any confidence in them.

Now, if there were some sort of trusted third party who would download things, check them, hash them, and serve up their own hashes, that might be valuable, but I'd expect to pay enterprise IT service sort of prices to get it.

I would think this argument pretty much defeats the request. A stronger hash provides NO more security as, in effect the hash provide NO security beyond knowing that the file came from the official domain. Anyone that can put a false file on the server can change the hash to compare to. The only use of the hash is to check a download from a mirror.

(5) By Rowan Worth (sqweek) on 2020-07-27 02:18:44 [link] [source] in reply to 4

The only use of the hash is to check a download from a mirror.

Right, but if a weak hashing algorithm is in use then mirrors are free to publish whatever crafted code they like and go "hey look the file matches the official hash therefore you can trust it."

(6) By anonymous on 2020-07-30 20:51:54 [link] [source] in reply to 1

I'm the OP. It's lovely to see that the download page now uses SHA-3, thank you.

(7) By David Jones (vman59) on 2020-08-02 13:45:18 [source] in reply to 6

If verifying the hash with OpenSSL, specify sha3-256 as the digest algorithm.