Date: Tue, 28 Sep 2004 12:14:05 +0300 From: Giorgos Keramidas <keramida@linux.gr> To: Jason Stone <freebsd-security@dfmm.org> Cc: freebsd-security@freebsd.org Subject: Re: compare-by-hash (was Re: sharing /etc/passwd) Message-ID: <20040928091405.GB1800@orion.daedalusnetworks.priv> In-Reply-To: <20040927095906.I79820@walter> 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> <20040927091710.GC914@orion.daedalusnetworks.priv> <20040927095906.I79820@walter>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2004-09-27 10:27, Jason Stone <freebsd-security@dfmm.org> wrote: > > Henson notes that since there's no absolutely guaranteed proof that > > there are *no* collisions with a given hashing algorithm, > > true - quite the opposite, in fact - with a finite hash length and an > infinite number of inputs, you are guaranteed an infinite number of > collisions in any hashing algorithm - you're just going to have to spend > longer than the lifetime of the universe to find them.... There is one difference between ``looking for collisions'' and being bitten by undetected collisions though. If the probability of a collision just happening with random user data is 1/(2^128) we can't be sure that it will necessarily take the transfer of an average number of 2^127 blocks before a collision happens. You might get one at the very first pair of blocks and then no collisions ever after until the Sun burns out. Using two different hashes for the same set of input data, which David G. Andersen proposed, seems like a nice idea though. - Giorgos
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040928091405.GB1800>