NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
sha-512 efficiency
Not tried ZFS on NetBSD yet, but I was wondering about the efficiency
of the various hash functions. ZFS can use fletcher4, sha-256, sha-512,
etc. in order to verify its data integrity. Some of them may or may not
be implemented on different platforms, but the most secure hash
function seems to be sha-512.
The problem with sha-512 is that it is quite slow, even on 64-bit Intel
CPUs. Not exactly what you want when checksumming large numbers of
blocks of data on a file system.
I'm not a cryptographer, but from my limited knowledge I assume that
cryptographic hash function like sha-512 are designed around the
following principles:
1. It should be extremely difficult to reverse the hash value in order
to get the original data.
2. It should be extremely difficult to get collisions, where the same
hash value maps to different blocks of data.
So when looking at ZFS (or any other file system that checksums data) I
would say that for the purpose of checksumming (and not encrypting data
on disk) principle No 1 is completely unnecessary.
I think principle No 2 is the most important, as the less collisions we
get, the better we can detect data corruption/modification.
And so, it makes me wonder if sha-512 is too complex, when it doesn't
need to be. I think of hash functions as lottery ball machines, which
mix numbers in random order. If you run the machine for 60 seconds it
will mix all numbers pretty well, but I'm pretty sure you are not going
to get any more randomness if you run the machine for say 6 hours. After
a certain amount of work you reach the point of diminishing returns.
Doe anyone know if this point of diminishing returns has been validated
in practice for sha-512 vs other functions? Mathematicians can do
theoretical analysis, but are there practical tests which show that
after a set of mixing operations, the randomness remains static and does
not increase any more?
Home |
Main Index |
Thread Index |
Old Index