Well, let's get some terminolgy straight first, and that might help clear
things up
Encryption describes the act of applying a cipher to plain text, which
results in encrypted text (cipher text). You can then reverse the process to
get your original plain text.
A hash, on the other hand, has little to do with encryption directly
(meaning it's not an encryption cipher). A hash simply provides a calculated
value based on the input. Hashes have a number of properties:
1) The hash value is a given fixed size regardless of how much input you use
2) Using the same input will always result in the same hash value
3) It *should* be computationally infeasible to get the same hash value if
different input is used (this is not always guaranteed)
4) Hashes are one-way. You can't take a hash value and apply an algorithm to
retrieve the original input
Hashes are usually used as a message digest or message authentication code
to ensure content hasn't be tampered with (a hash before and after
transmission of data should provide the same results). However, for security
purposes as far as password storage goes, we run into a few snags.
First of all, since the same input always returns the same hash value, I can
take several hundred thousand words (and even some common funny spellings)
and create the hash value for all of them. I now have a dictionary. If i'm
able to get your hashed password list, I can compare them to my dictionary
and "lookup" the original text. This is one reason why strong passwords
(sequences of characters that are unlikely to be guessed in a dictionary
attack) are so important. But there are better ways to protect yourself.
There are indeed keyed hash algorithms, and the framework provides two of
them: HMACSHA1 and MACTripleDES. Because they require a key, a potential
attacker using a dictionary would have to create a dictionary for every
possible key value in a brute force dictionary attack. This ups the level of
security. The other thing you can do is salt is the input, as you've seen.
Finally, a big asset is to make sure you can prevent collisions (two input
values resulting in the same hash value). To do that, use the biggest hash
with the best algorithm. So far, I suspect that of all the non-keyed hashes
provided in the framework, SHA256 will be that algorithm. You don't have
"learn" how to use it, because all hash classes in the framework work the
same way. If you can use MD5, you can use SHA256. The only real difference
is that SHA256 will produce a longer hash value. Also note that, as you said
earlier, SHA and MD5 don't use keys.
-Rob
