> On Feb 7, 2017, at 7:39 AM, [email protected] wrote:
>
> Nice to see a sha1 extension included with SQLite now.
… Just in time for SHA-1 to be declared officially broken: there’s now an
effective mechanism to generate collisions (it only takes 100 GPU-years), and
at least two colliding files are in the wild and have already wreaked havoc on
SVN repositories they’ve been checked into:
https://shattered.io
https://arstechnica.com/security/2017/02/watershed-sha1-collision-just-broke-the-webkit-repository-others-may-follow/
It may be too late for 3.17, but it would be a good idea to add SHA-256 and/or
SHA-3 ASAP.
Also, there is a ‘hardened’ implementation of SHA-1, a drop-in replacement that
detects and rejects input data that shows the hallmarks of the collision
attack. It would be great to use this for SQLite’s SHA1 function:
https://github.com/cr-marcstevens/sha1collisiondetection
(I don’t want to reopen the argument about whether it’s reasonable to treat any
digest as a unique identifier! The fact is that, like it or not, cryptographic
digests are very commonly used for this purpose, and most (but not all)
security professionals think it’s reasonable to, as long as the algorithm is
strong enough. SHA-1 is now definitely too weak, so it would be good for SQLite
to offer an alternative that’s still safe(r).)
—Jens
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
