On Wed, Sep 16, 2015 at 1:05 AM, Warren Young <[email protected]> wrote:
> On Sep 14, 2015, at 11:53 PM, Stephan Beal <[email protected]> wrote: > > > > it is not possible to change the hash without a near-complete overhaul > of fossil (and its docs) > > I’ve already addressed the documentation/UI issue repeatedly above: The > fact that Fossil uses SHA-1 should be a hidden implementation detail, > unimportant to anyone but those working on the lowest-level parts of Fossil. > There are lots of assumptions in many places about which hashes are being used, and their properties (e.g. length and being made up solely of lowercase hex). > (Plus those working on compatible software such as libfossil and FUEL.) > And i can say from my work on libfossil that this is so ;). > > Supporting two hash variants in one fossil binary would likely prove to > be problematic (and would require a major overhaul). > > Why can’t an artifact’s or checkin’s hash be tagged in MCF fashion, so > that when Fossil checks the hashes, it knows which algorithm to use at each > step? > It "could" be done, but it would essentially require duplicate code paths for much of the existing code and would not be directly compatible with existing repos (which would have to keep using sha1). > Many other systems support multiple encryption and digest algorithms, and > many of those can switch mid-stream to a different algorithm. This is > known tech. > Sure, it's conceivable, but it's more trouble than it's worth. There's no use case for fossil where such a move would simplify its usage in any way. > then the prior discussion was all about accidental collision. I’m talking > instead about motivated, well-trained, intelligent, well-funded attackers > purposely attempting to engineer a collision. Not the same thing at all. > Wake me up when that happens. It hasn't happened yet and there is little reason to suspect that it ever will. > The Chinese attack from 2005 reduces the attack complexity to about 2^69 > operations. The Stevens attack from 2011 reduces the attack complexity > even further, to between 2^60.3 and 2^65.3 operations. Add to that the > improvement from Moore’s Law and you’re talking about 5 to 7 orders of > magnitude improvement. > Again - a hypothetical problem. (A) nobody has anything to gain by maliciously injecting content into a fossil repo and (B) i would have to see it happen to believe it. > Obviously the world’s HTTPS traffic is a far bigger target than > public-facing Fossil repos, so Fossil’s urgency to get off SHA-1 should be > lower. That said, attacks only get better, and Moore’s Law still has steam > in it, at least for embarrassingly-parallel applications like hashing.\ Show me one such successful attack on fossil and i'll be _all ears_. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
