You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2024/01/12 11:57:09 UTC

Re: svn commit: r1908812 - /subversion/branches/pristine-checksum-salt/BRANCH-README

[Replying to the most recent commit to BRANCH-README:]

kotkov@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-0eda19f93b3c@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