full-disclosure - Re: Case ID 51560370 - Notice of Claimed Infringement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4256A3A0.8000307@sdf.lonestar.org>
Date: Fri Apr  8 16:30:57 2005
From: bkfsec at sdf.lonestar.org (bkfsec)
Subject: Re: Case ID 51560370 - Notice of
	Claimed	Infringement

Thierry Zoller wrote:

>RP> Otherwise, it is _possible_ to have a chunk with the same fingerprint and
>RP> make it appear that you have said chunk of their iso.
>That's *AFAIK* not possible, if this would be true the edonckey/emule
>protocol would have a big design flaw and poeple couldn't even trade
>millions of files every day, some (most?) downloads would be corrutped
>as they could  have potentialy downloaded a wrong chunk which in fact
>is from another file.
>
>  
>
Of course it's possible.  All hashes, by their very nature, have 
collisions.  The only way to have a truly unique identifier is to use 
the actual content of the file (or chunk) itself.  The minute you 
distill the content down to a hash, you're guaranteeing that collisions 
will occur.

They are, however, somewhat rare.  That's why the system works as 
relatively well as it does.

Regarding corrupt files via P2P protocols... no file transfered via P2P 
has _ever_ tranferred bad data and wound up corrupt, right?  :)  
/friendly sarcasm.

             -Barry