In my new secret document encryption utility, the key for symmetric encryption = the hash of a random salt and a user provided password.
It is necessary to have a slow hash function in order to prevent brute force on less than optimal passwords. MD5 and SHA1 have proved immensely speedy, so that is obviously not enough. I also do not have high hopes for SHA256.
One options is to repeat the hashing operation an absurd number of times. Due to the vast repetition necessary (100k minimum), I was somewhat concerned about attackers who would know a way of skipping ahead with shortcuts, perhaps using the rho table, or some other means.
Is this 100,000 rehash approach sound, or should I use some other algorithm to create a key from a password and salt?
Obviously I can also require a more complex password, but I think a good goal would be to support the 6 letter, non dictionary variation, even if I do require a whole second of rehashing to perform the unlock. This is an acheivable goal, and I feel it is better to allow shorter passwords if a) that is what the user wants and b) it does not impact security in a significant way.
1. An estimate on how long the hash would take for a <2 Ghz processor is 1 millisecond for every 1-2 thousand repetitions (depending on the algorithm). For 6 letter, non dictionary passwords that need to hold up for 1 year, we would need the key generation to take at least 100 milliseconds.