On Thursday 24 May 2007 09:58:41 am Steven H. McCown wrote:
> For the really paranoid, NIST is recommending that federal agencies stop
> using SHA-1, since it's been cracked (along with MD5), and instead use the
> SHA-2 family of hash algorithms.
The recently-discovered weaknesses in MD-5 and SHA-1 don't really affect their
usage in this sort of application. The weaknesses in question are algorithms
that can be used to generate collisions -- to find two input values that hash
to the same output value. That poses a risk to uses that rely strongly on
the attacker's inability to create collisions, such as digital signatures or
other message authentication schemes, but both hashes are still perfectly
useful for blinding identifiers, and would be even if the current attacks
were improved to be full preimage attacks.
It's worth pointing out, however, that for the truly paranoid a simple MD-5 or
SHA-1 hash isn't a very secure mechanism for blinding small identifiers, like
the MRN (not that it really needs to be that secure, but...). The reason
it's not very good is simple: There aren't very many possible MRNs, so it's
possible to hash all of them and create a dictionary of MRN -> H(MRN)
mappings. Then translating a hash back into the corresponding MRN is simple.
The solution to this "problem" is to use a secure hash algorithm the attacker
does not know[*]. The easy way to do that is to use a keyed hash. Choose a
random key K, of sufficient length, and then store H(K||MRN), where '||'
means concatenation. Note that this is similar to but different from salted
hashes. Salts are unique per hashed ID and stored with the hash value, where
keys are global and kept secret.
All of this is massive overkill for protecting the MRN, of course. But it is
fun :-)
Shawn.
[*] Another solution is to use a slow hash algorithm. The problem with that
is that the meaning of "slow" changes over time, as computers get faster.
Slow hashes should definitely be combined with salt to make dictionary
attacks hard. Keyed hashes are a better solution if there's a secure place
to store the key.
_______________________________________________
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss
