Hacker News Reader

SHA is OK, if you have a long random key. I forget the numbers, but a decent random key (100 chars?) becomes impossible to crack before the heat death of the universe. The exponential growth of the password space eventually defeats the weakness of SHA.

The reason you need bcrypt is that user supplied passwords are crap, and can be cracked very quickly.

View on HN

Yes, I agree that the length of the key and the real randomness are the most important points and that when those are fulfilled the recipe has sense. Neither explicit length minimality nor real randomness of the key were mentioned but the SHA advice was explicit to the 256 bits.

EDIT: To make it clearer: "Long" is not explicit. 256 bits is. The difference between real randomness and for example output of RND in your favourite language is also nowhere to be seen. Moreover the use of the "key" is dubious as it's not an encryption key at all.

From the comment you initially replied to:

"Only use the users password to obtain a long random key" (emphasis mine).

So it was part of the initial recipe.

Someone can do the math but I expect a 64 character long random string is more than sufficient.

Reply on news.ycombinator.com