From owner-freebsd-security@FreeBSD.ORG Mon Sep 27 09:17:14 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 60B1416A4CF for ; Mon, 27 Sep 2004 09:17:14 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91B2A43D49 for ; Mon, 27 Sep 2004 09:17:13 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (host5.bedc.ondsl.gr [62.103.39.229])i8R9HAtN026657; Mon, 27 Sep 2004 12:17:11 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i8R9HABa001751; Mon, 27 Sep 2004 12:17:10 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)i8R9HAZv001750; Mon, 27 Sep 2004 12:17:10 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 27 Sep 2004 12:17:10 +0300 From: Giorgos Keramidas To: Colin Percival Message-ID: <20040927091710.GC914@orion.daedalusnetworks.priv> References: <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41575DFC.9020206@wadham.ox.ac.uk> X-Mailman-Approved-At: Mon, 27 Sep 2004 12:31:04 +0000 cc: freebsd-security@freebsd.org Subject: Re: 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 09:17:14 -0000 On 2004-09-26 17:25, Colin Percival wrote: > 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. Err, no. Henson notes that since there's no absolutely guaranteed proof that there are *no* collisions with a given hashing algorithm, comparing by hash value might result in two data blocks treated as identical even though they really are not. Increasing the number of bits the hash key uses will decrease the possibility of a collision but never eliminate it entirely, AFAICT. What I pointed out was that when a non-zero possibility of two data blocks comparing as equal (even though they are no) exists, the method in question should not be used for password data or other sensitive bits of information. A larger hash key will never yield a possibility of zero, so it doesn't mean that you can sleep untroubled at night while the rsync server overwrites /etc/*pwd.db files periodically.