On Mar 9, 2017, at 1:03 PM, Richard Hipp <[email protected]> wrote: > > If a new artifact Y' which has the > same SHA1 hash as Y comes along, it will be discarded, since an > artifact with that same hash is already in the repository.
That can be gotten around with a MITM attack, as I’ve already brought up several times on the list. Many Fossil instances won’t have TLS protection against MITM attacks, and those that do have it may be weakened by some well-intentioned TLS-busting middlebox or antimalware package. > (2) If you apply the Y->X delta to Y' instead of to Y, you are not > going to get an object that has the same hash as X, especially if X > has a sha3 hash. (I'm not sure if Fossil actually checks that right > now, but it is certainly easy enough to add - all the information is > readily at hand.) That sounds like a better solution to the risk than my solution, which could balloon the repository by as much as one full checkout size. > (3) Just to make the problem a little harder for the attacker, the > delta itself has its own 32-bit checksum use to verify the integrity > of the answer. I thought we’d already disposed of such arguments as worth consideration. If the attacker is already spending $BIGNUM on the SHA-1 attack, the cost of knocking over the CRC32 and MD5 is going to be on the order of the project’s catering bill. > (4) At some point, the sync protocol will be rigged up to not accept > any now SHA1 artifacts, except when cloning legacy repositories, and > then the artifacts must have timestamps prior to some cut-off date > (yet to be decided). I support that. Good plan. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
