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
> 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).
zfs-discuss mailing list