[Replying to the most recent commit to BRANCH-README:] kot...@apache.org wrote on Thu, 30 Mar 2023 19:04 +00:00: > Author: kotkov > Date: Thu Mar 30 19:04:13 2023 > New Revision: 1908812 > > URL: http://svn.apache.org/viewvc?rev=1908812&view=rev > Log: > On the 'pristine-checksum-salt' branch: Update BRANCH-README. > > * BRANCH-README > (Dynamically salted SHA-1 checksums): Extend and update this section. > > Modified: > subversion/branches/pristine-checksum-salt/BRANCH-README > > Modified: subversion/branches/pristine-checksum-salt/BRANCH-README > URL: > http://svn.apache.org/viewvc/subversion/branches/pristine-checksum-salt/BRANCH-README?rev=1908812&r1=1908811&r2=1908812&view=diff > ============================================================================== > --- subversion/branches/pristine-checksum-salt/BRANCH-README (original) > +++ subversion/branches/pristine-checksum-salt/BRANCH-README Thu Mar 30 > 19:04:13 2023 > @@ -13,5 +13,26 @@ as currently implemented, will use the n > Dynamically salted SHA-1 checksums > ---------------------------------- > > -The implementation on the branch uses a dynamically salted SHA-1 checksum > kind. > -The dynamic salt is generated during the creation of a wc.db. > +The working copy currently relies on an assumption that files with identical > +checksum values have identical content. For SHA-1, there are publicly known > +checksum collisions [https://shattered.io] and the situation may become worse > +with the feasibility of chosen-prefix attacks [https://sha-mbles.github.io]. > + > +To solve the potential problems and to improve the current state around > checksum > +collisions, the implementation on the branch starts using a dynamically > salted > +SHA-1 checksum kind. > + > +The 32-byte random salt is generated during the creation of a wc.db. When > the > +file content is checksummed, the checksum value is calculated as if the salt > was > +prepended to the content. In other words, checksum = SHA1(content) becomes > +checksum = SHA1(salt + content). > + > +With the dynamic salt: > + > +- Publicly known SHA-1 collisions no longer result in collisions when > checksummed > + by the working copy. This is because the actually checksummed content now > + includes the random prefix salt. > + > +- Constructing a chosen-prefix SHA-1 collision no longer results in a > collision > + when checksummed by the working copy. This is because the constructed > collision > + cannot account for the random prefix salt, because it's unknown in advance.
For context, this is similar to https://mail-archives.apache.org/mod_mbox/subversion-dev/202301.mbox/%3cadacbb6f-e0cb-4e5b-8603-0eda19f93...@app.fastmail.com%3E but with the suffixing changed to prefixing. (Changing suffixing to prefixing makes sense, since SHAttered collisions have the property that appending an identical suffix to two colliding files generates two other colliding files.) Cheers, Daniel
