Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Sep 2004 12:17:10 +0300
From:      Giorgos Keramidas <keramida@freebsd.org>
To:        Colin Percival <cperciva@wadham.ox.ac.uk>
Cc:        freebsd-security@freebsd.org
Subject:   Re: compare-by-hash (was Re: sharing /etc/passwd)
Message-ID:  <20040927091710.GC914@orion.daedalusnetworks.priv>
In-Reply-To: <41575DFC.9020206@wadham.ox.ac.uk>
References:  <Pine.LNX.4.33.0111071900280.24824-100000@moroni.pp.asu.edu> <20011107211316.A7830@nomad.lets.net> <20040925140242.GB78219@gothmog.gr> <41575DFC.9020206@wadham.ox.ac.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2004-09-26 17:25, Colin Percival <cperciva@wadham.ox.ac.uk> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040927091710.GC914>