From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 00:25:49 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FAFF16A4CE; Mon, 27 Sep 2004 00:25:49 +0000 (GMT) Received: from pd2mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0992C43D1D; Mon, 27 Sep 2004 00:25:49 +0000 (GMT) (envelope-from cperciva@wadham.ox.ac.uk) Received: from pd5mr6so.prod.shaw.ca (pd5mr6so-qfe3.prod.shaw.ca [10.0.141.182]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4O007ASBULTDB0@l-daemon>; Sun, 26 Sep 2004 18:25:33 -0600 (MDT) Received: from pn2ml1so.prod.shaw.ca ([10.0.121.145]) by pd5mr6so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0I4O008ELBUL4SK0@pd5mr6so.prod.shaw.ca>; Sun, 26 Sep 2004 18:25:33 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.233.42])2003)) with ESMTP id <0I4O001C1BUL2I@l-daemon>; Sun, 26 Sep 2004 18:25:33 -0600 (MDT) Date: Sun, 26 Sep 2004 17:25:32 -0700 From: Colin Percival In-reply-to: <20040925140242.GB78219@gothmog.gr> To: Giorgos Keramidas Message-id: <41575DFC.9020206@wadham.ox.ac.uk> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040922) X-Mailman-Approved-At: Mon, 27 Sep 2004 12:31:04 +0000 cc: freebsd-security@freebsd.org Subject: compare-by-hash (was Re: sharing /etc/passwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2004 00:25:49 -0000 Giorgos Keramidas wrote: > After reading a nice paper by Val Henson[1] I'm not so sure I'd trust > sensitive information like password data to rsync without making sure > that compare-by-hash is disabled if at all possible. If you're going to disable compare-by-hash, you might as well just use rcp; but there's no theoretical justification for disabling compare-by-hash. Henson's paper points out a number of cases where hashing causes problems, but none of these are issues with hashing itself; rather, the problems arise from using hashing with an insufficient number of bits. Obviously if you're searching for SHA1 collisions, you shouldn't index your data by SHA1 hash... you shouldn't use a 160 bit hash *any* time that you're doing O(2^80) work. The above notwithstanding, rsync's choice of hash function leaves something to be desired; MD4 is completely broken, and (while it is still adequate for random inputs) it is easy to construct files which rsync will incorrectly synchronize. (It's also trivial to construct files which consume ~100 times more cpu time on the server than normal -- unfortunately, this is an unavoidable consequence of using a fixed rolling hash function.) Colin Percival