On Sep 15, 2015, at 7:01 PM, Scott Robison <[email protected]> wrote: > > I think calling it a non sequitur is not completely fair
Stephan stated that Fossil isn’t doing cryptography, therefore SHA-1 doesn’t have to be replaced. Cryptography and message authentication are not the same thing. It’s like pointing out that the bald tires on the car do not need to be replaced because we don’t require that the car be able to climb trees. > It wasn't intended to provide cryptographic security I’m probably just being pedantic, but now you’re doing it, too. “Cryptographic security” implies encryption, which is not being done here. The proper phrasing is “cyptographically-strong message digest algorithm.” The reference to cryptography is only an indicator that the use of a given MD algorithm can be used with some given cryptosystem without compromising its integrity. > It is more likely to detect accidental corruption than deliberate corruption. I thought that’s what the MD5 bits were for. My sense from reading the file format wiki page is that the SHA-1 bits ensure that blob B, which is intended to appear in the timeline between blobs A and C, was almost certainly inserted into the database at time T_b, where T_a <= T_b <= T_c. That is, it is primarily a guarantor of checkin ordering. That’s why I’ve been framing the risk as one of potential insertion of a timeline item way in the past. That may be a bogus risk for other reasons, though, since you’d also have to work out how to change all the deltas. It’s also occurred to me since my previous post that all the work needed to generate a bogus SHA-1 hash for an HTTPS cert only has to be done once, at which point you now have a reusable cert good for months or years. The work needed to attack a single timeline entry in Fossil is a one-shot deal: to attack two different nodes in the timeline, you need to do 2x the work. > simply gaining commit access to the master repository as mentioned the other > day would not be adequate; the maliciously modified artifact would be > rejected by fossil I’m no expert in Fossil’s inner workings, and I have no interest in trying to attack it. I’m just aware that Bruce Schneier and Google’s crypto geeks know things I do not, and I use that awareness to guide my own design decisions. The last hash-based system I designed used SHA-256. :) > I find it far more likely that someone would fork the repo and contaminate it > that way, rebuilding it from scratch, and finding ways to induce parties to > use *that* version of the library instead of the blessed repo. Clearly so. Always attack the weakest link first, if possible. > * ethernet uses a 32 bit CRC; how much internet traffic goes through > ethernet? Can't really change that because of backward compatibility. > * rsync uses MD5 & a 32 bit rolling checksum / CRC (Adler-32 if I remember > correctly). Can't really change that because of backward compatibility. That’s why TLS exists. TLS doesn’t solve any weaknesses with Fossil’s use of SHA-1, though. It just prevents you from MITM-ing an existing TCP connection. Once you’ve got a TCP connection to the Fossil server, well, *then* what? That’s the purpose of this sub-thread. > Given the widespread use of SHA-1 in DVCS systems, and the use of GPG > signatures to authenticate commits, I think it would be reasonable to enhance > the cryptographic security in a future version of fossil. Indeed, perhaps Fossil should just wait and see what Git does, if anything. Github is a much bigger target for this sort of thing, if there is a “thing” here at all. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
