On Oct 28, 2015, at 6:37 PM, Eduard <[email protected]> wrote: > > I wish to discuss the issues surrounding the use of SHA1 in Fossil
Have you read the prior discussions on this? http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg18053.html http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg05970.html http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg21423.html > First I propose that the use of SHA1 in Fossil is a serious problem. The known attacks on SHA-1 are still computationally expensive, and will remain so for years. Not impossible, but still very difficult. We have time to move, if we need to. But also, and much more importantly, most of the attacks on SHA-1 only apply to standalone blob cases such as binary package validation, X.509 certificate signing, etc. In Fossil, most of the SHA-1 checksummed artifacts are chained in some way, so that you can only modify the leaves of branches. That makes tampering with the tree without detection quite difficult. Anyone paying attention to the timeline will probably notice an attack. Understand, I’ve been on your side prior to this, worried about SHA-1 purely because Bruce Schneier and Google tell me that SHA-1 should give me stomach upset. But I also have D. Richard Hipp telling me that due to the way SHA-1 is used in Fossil, he isn’t worried about it. That’s a powerful antacid. :) > If the attacker can intercept > communications between the server and a developer …then you did not run Fossil over TLS, like you should if MITM is a legitimate risk in your situation. :) > If the attacker is in control of the server …then he can serve you any content he likes, no matter how good your hash algorithm is. The correct solution here is something like TLS with certificate pinning, GPG signing, etc. > The third solution is to change the Fossil specification to redefine the > artifact ID to be the concatenation of the SHA1 and BetterHash A fourth solution is to use Modular Crypt Format to declare the hash for each artifact, and for future Fossil versions to tolerate SHA-1 only in existing artifacts, accepting new ones using only known-good algorithms: https://pythonhosted.org/passlib/modular_crypt_format.html This could be done without breaking the DB, simply because a 20-byte hash must be SHA-1, since even a 160-bit BetterHash will have the MCF wrapper on it, making it more than 20 bytes. The SQLite card format parser would have to be made more flexible, to make it understand that if it sees a leading dollar sign, the following hash can be variable-width. I think the biggest problem with this is that older Fossil clients wouldn’t be able to sync with the repo after the server is upgraded. That’s a well-known problem with a raft of well-understood solutions, so we don’t need to detail that here. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
