search for: cyan4973

...nd 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

...0] claims on a Core i5-3340M @2.7GHz that: |Version Speed on 64-bit Speed on 32-bit |XXH64 13.8 GB/s 1.9 GB/s so using xxhash64 for that work would also boost !x86 platforms. However your patch has the benefit that no changes are required on the remote side. I like that. [0] https://github.com/Cyan4973/xxHash#benchmarks Sebastian

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

I don't disagree that MD5 could (or even should) be replaced so it is no longer the bottleneck in several real-world cases (including mine). However this patch is not for MD5 performance, rather for the rolling checksum rsync uses to match blocks on existing files on both ends to reduce transfer size. On Mon, May 18, 2020 at 5:44 PM Filipe Maia via rsync <rsync at lists.samba.org>

...SHA1 from the built-in code: |time ./rsync -c /dev/shm/out --checksum-choice=sha1 |-rw-r--r-- 1,073,741,824 2020/02/08 16:34:42 out | |real 0m1,561s |user 0m1,465s |sys 0m0,096s [1] https://opensource.stackexchange.com/questions/2233/gpl-v3-with-openssl-exception [0] https://github.com/Cyan4973/xxHash Signed-off-by: Sebastian Andrzej Siewior <sebastian at breakpoint.cc> --- Makefile.in | 4 +- checksum.c | 144 +++++++++++++---- configure.ac | 5 + lib/md32_common.h | 258 +++++++++++++++++++++++++++++ lib/md5.c | 15 +- lib/mdigest.h | 77 +++++...