> Please demonstrate. In addition to the SHAttered attack, we also have more recent [the SHAmbles][1] 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. [1]: https://sha-mbles.github.io/