On Wed, 10 Sep 2003, Lorrin Nelson wrote: > > Yeah, I'm not sure this logic is getting anywhere. Lets say I want to > block a particular y bit file (y < 160) with CHK x. If you start trying > to find a file with CHK x by looking at all possible files, then of > course you'll find the file in just 2^y tries, since you'll have > stumbled across the actual file! But that's no use to use, since you > need a _different_ file than the one you're trying to block. So you've > gotta keep looking, and that'll probably take 2^159 tries as was said > earlier. > > I just made all this up so maybe I'm wrong, but it makes sense to me. :-)
Ok, here's the deal. What we're looking for is the set of files that matches the first X bits of a hash, leaving 160-X bits 'random'. To _REALLY_ target a particular CHK, let's go with 32 fixed bits. There are 2^128 keys out there, out of 2^160. To find _ONE_ key that's near enough you need to search (2^160/2^128) or 2^32 hashes. Interesting. That's basically zero work, especially if you decide to "only" match 20 bits. Now the question becomes: If I insert 2^10 near-collisions on a CHK, what happens to the network? --Dan
pgp00000.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
