Re: [RFC PATCH] Add SHA1 support
On Tuesday, March 17, 2020 9:17:09 PM CET, Sebastian Andrzej Siewior wrote: 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. This was not the case in 2008 when rsync 3.0.0 came out defaulting to MD5. I still think you need a cryptographic hash, even though I am not sure of how strict the requirement is. MD4 was replaced by MD5 in rsync, despite MD4 being 2x faster. I would guess it was replaced because of its weaknesses. Dimitris -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [RFC PATCH] Add SHA1 support
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 -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [RFC PATCH] Add SHA1 support
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 -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [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 -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: [RFC PATCH] Add SHA1 support
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* ... Kind regards, Markus -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
