rsync - Mar 2020 - [RFC PATCH] Add SHA1 support

On 2020-02-20 20:06:39 [+0100], Markus Ueberall wrote:
> On 2020-02-09 23:19, Sebastian Andrzej Siewior wrote:
> > [...]
> > My primar motivation to use SHA1 for checksumming (by default) instead
> > of MD5 is not the additional security bits but performance. On a
decent
> > x86 box the SHA1 performance is almost the same as MD5's but with
> > acceleration it outperforms MD5.
> > 
> > The other alternative would be to go for xxHash64 [0] which has the
> > superior performance but provides a non-cryptographic hash so I though
> > SHA1 would be better here.
> > [...]
> 
> With respect to *both* speed and security, wouldn't BLAKE3 be a better,
> modern alternative if we're looking at checksumming?
> It's "[r]eleased into the public domain with CC0 1.0.
Alternatively, it is
> licensed under the Apache License 2.0".  And the performance (see the
chart
> at https://github.com/BLAKE3-team/BLAKE3) is *impressive* ...
I'm still not sure if rsync requires a cryptographic hash _or_ if a
strong hash like xxHash64 would be just fine for the job.
> Kind regards, Markus
Sebastian

On Thursday, February 20, 2020 10:34:53 PM CET, Sebastian Andrzej Siewior 
via rsync wrote:
>
> I'm still not sure if rsync requires a cryptographic hash _or_ if a
> strong hash like xxHash64 would be just fine for the job.
I'm fairly sure the hash should *not* be easy to spoof, so I'd say a 
cryptographic hash is needed.

As an example, if a file is replaced by a file of the same size and same 
hash,
rsync (if -c is in use) will consider the file is the same, and avoid 
copying it.


Dimitris

On 2020-03-17 00:03:03 [+0100], Dimitrios Apostolou via rsync
wrote:
> On Thursday, February 20, 2020 10:34:53 PM CET, Sebastian Andrzej Siewior
> via rsync wrote:
> > 
> > I'm still not sure if rsync requires a cryptographic hash _or_ if
a
> > strong hash like xxHash64 would be just fine for the job.
> 
> I'm fairly sure the hash should *not* be easy to spoof, so I'd say
a
> cryptographic hash is needed.
> 
> As an example, if a file is replaced by a file of the same size and same
> hash,
> rsync (if -c is in use) will consider the file is the same, and avoid
> copying it.
correct. The same goes for currently used md5 which has known collision
attacks. So if you intend to spoo it, you can manufacture the same hash
for two different files for both algorithms. The question is how likely
it is that this happens by chance. According to [0] xxhash64 scores a
solid 10. It is better than crc32 which has been used a lot as a
checksum for files.

[0] https://github.com/Cyan4973/xxHash
> Dimitris
Sebastian