On 07/11/2012 12:00 PM, casper....@oracle.com wrote: > > >> You do realize that the age of the universe is only on the order of >> around 10^18 seconds, do you? Even if you had a trillion CPUs each >> chugging along at 3.0 GHz for all this time, the number of processor >> cycles you will have executed cumulatively is only on the order 10^40, >> still 37 orders of magnitude lower than the chance for a random hash >> collision. >> > > Suppose you find a weakness in a specific hash algorithm; you use this > to create hash collisions and now imagined you store the hash collisions > in a zfs dataset with dedup enabled using the same hash algorithm.....
That is one possibility I considered when evaluating whether to implement the Edon-R hash algorithm. It's security margin is somewhat questionable, so then the next step is to determine whether this can be used in any way to implement a practical data-corruption attack. I guess is that it can't, but I'm open to debate on this issue, since I'm not a security expert myself. The reason why I don't think this can be used to implement a practical attack is that in order to generate a collision, you first have to know the disk block that you want to create a collision on (or at least the checksum), i.e. the original block is already in the pool. At that point, you could write a colliding block which would get de-dup'd, but that doesn't mean you've corrupted the original data, only that you referenced it. So, in a sense, you haven't corrupted the original block, only your own collision block (since that's the copy doesn't get written). Cheers, -- Saso _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
