On 16 September 2015 at 05:16, Scott Robison <sc...@casaderobison.com> wrote: > On Tue, Sep 15, 2015 at 7:46 PM, Warren Young <w...@etr-usa.com> wrote: >> >> On Sep 15, 2015, at 7:01 PM, Scott Robison <sc...@casaderobison.com> >> 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. > > > As I understand "cryptography" to be defined it means "the practice and > study of techniques for secure communication in the presence of third > parties". If that is correct, message authentication is most assuredly a use > of "cryptography to securely identify authenticity". If I'm using a term > incorrectly, my apologies. > >> >> > 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. > > > The SHA-1 bits ensure (virtually guarantee) that blob B has a unique > identity so that two contributors don't allocate ID 42 at the same time > creating a collision in commit IDs. Artifacts are unordered and can > originally come into a repository from any source in any order. It is > primarily a guarantor of checkin identity, and the individual cards in the > manifest control timeline order, date, time, author, etc. > >> >> 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. > > > Given that the commit ID is a hash of the manifest, and most of the cards in > the manifest are F cards, in theory all you have to do is find a useful > collision with the SHA-1 hash of any file artifact. If you could modify one > file without changing its SHA-1 hash, everything else in the database would > still match its hash. Of course, if it is too far back in the history > (probably even a single merge behind tip) it may never be noticed because > the project has moved on. And the difficulty still exists of getting it into > the master repository. > >> >> > 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 have a lot of respect for Schneier. I would not consider using SHA-1 in a > security sensitive environment today. This use is less about security and > more about non-cryptographic hashing, where an (at one time) cryptographic > strength hash happened to be satisfactory for the needs at hand. > >> >> > 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. > > > But GPG could solve any weaknesses with Fossil's use of SHA-1, though. It > won't prevent a determined party from deconstructing a repo, making whatever > changes are desired, and rebuilding a believable facsimile that unwary > parties might trust. The rebuilt repo could even have fraudulent GPG > signatures attached just to make it feel more legit to people who don't > really check such things.
It has been pointed out that when using GPG to sign checking only the manifests are signed and what links the manifests to the rest of the content like actual file blobs or previous checkins are the weak SHA-1 hashes. So while it is possible to use PGP with fossil it gives only a false sense of security until fossil itself uses crypto grade hash to link its internal articact structure. Using a stronger or configurable hash for the internal linking of artifacts would result in ability to verify the authenticity of a copy of a signed repo even from unknown source so long as the signatures are valid. As actual signed repos are rare this is not really strong use case. On the other hand, they may be rare because there is no real point. Thanks Michal _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
