Karl Fogel wrote on Fri, Jan 20, 2023 at 11:18:56 -0600:
> On 20 Jan 2023, Nathan Hartman wrote:
> > Taking a step back, this discussion started because pristine-free WCs
> > are IIUC more dependent on comparing hashes than pristineful WCs, and
> > therefore a hash collision could have more impact in a pristine-free
> > WC. "Guarantees" were mentioned, but I think it's important to state
> > that there's only a guarantee of probability, since as mentioned above
> > all hashes will have collisions.
>
> Sure, in a literal mathematical sense, but not in a sense that matters for
> our purposes here.
>
> In the absence of an intentionally caused collision, a good hash function
> has *far* less chance of accidental collision than, say, the chance that
> your CPU will malfunction due to a stray cosmic ray, or the chance of us
> getting hit by a planet-destroying meteorite tomorrow.
>
> For our purposes, "guarantee" is accurate. No guarantee we make can be
> stonger than the inverse probability of a CPU/memory malfunction anyway.
>
The probability of an accidental collision in a "good" N-bit hash
function is on the order of 1/√2ⁿ, which for sufficiently large N is
considered an acceptable risk. That's invariant over time, however,
intentionally causing collisions becomes easier over time.
> > We already can't store files with identical SHA1 hashes, but AFAIK the
> > only meaningful impact we've ever heard is that security researchers
> > cannot track files they generate with deliberate collisions. The same
> > would be true with any hash type, for collisions within that hash
> > type.
>
> Yes. A hash is considered "broken" the moment security researches can
> generate a collision.
>
To be clear, is this what you're saying? —
.
Premise: There is a collision attack against SHA-1.
Conclusion: Subversion should stop using SHA-1.
This conclusion does not follow from this premise. For instance, FSFS
checks for collisions, so it can actually use "File length in bytes" as
a checksum and everything would work; the only thing that would change
is that it would not be possible to commit a file that's the same
expanded_size as any other node-rev (including directories).
And, anyway, the burden is not on me to disprove your claim, but on
you to prove it.
> FWIW, in one of my previous posts, I described a real-life scenario in which
> the ability to generate a chosen-plaintext collision in an SVN working copy
> would have security implications.
Yes, and as I have already asked: What other counters to that attack,
besides migrating away from SHA-1, have you considered? Have you
considered the downsides of migrating away from SHA-1?
Also, /if/ we changed checksums, would that address the attack? Put
differently, why is a similar attack impossible if we change the
checksum algorithm? Why is use of SHA-1 a /sine qua non/ of your
scenario?
For example, if we used another checksum algorithm, the attacker from
your scenario might opt to edit the base checksums in .svn/wc.db and
rename the .svn/pristine/ files accordingly. That's much easier to pull
off, and will be easy to adapt if we change the algorithm again, but on
the other hand, requires write access to the .svn directory and is
easier to discover.
Daniel
> Best regards,
> -Karl
