Are there any slow Javascript hashing algorithms like bcrypt?

Question

I am not talking about the server side of node.js.

I want to use a slow hashing algorithm for a key on the client side of my site. I found SHA-256 implementations that seem reliable . I also found this question that lead to OP creating his own library .

However, I am not sure if I should just do a few rounds of SHA hashing or trust some of this code, since I am not a security expert and it does not seem to have a large footprint of 36 people.

What is the best choice in this case? I (in principle) cannot change the methods when I choose something.

I want a slow hashing algorithm (not encryption), and I would prefer it to create a short string. For example, a slow 60 char bcrypt versus a fast 70 char SHA-256.

Answer 1

Currently, there are three key output functions that are widely regarded as being protected from brute force hacking attempts. Key output functions are slightly different from conventional hashing algorithms in that they are designed to be slow, even in modern computing based on the GPU.

I listed them in theoretical safety order:

• PBKDF2 is developed by SHA-based RSA and is an algorithm recommended by NIST. There is a couple implementation that you can use in the browser.

  Note for Node users: Node crypto module has built-in PBKDF2 function . Use this.

• Blowfish-based bcrypt is slightly more secure than PBKDF2. It has been relatively well tested and tested to be safe, but it does not have official approval from any standardization bodies if you consider it for you. Here's a generic JS implementation here .

  Note for Node users: use node.bcrypt , which does computationally expensive things in a separate thread.

• Finally, scrypt is the most theoretically safe (slowest) KDF. Unfortunately, the algorithm is very new, so it has not been tested through careful study and testing by the cryptographic community. However, on the way to becoming the IETF standard .

  Since the algorithm is so new, it is difficult to find implementations. I could find this half-baked one . Although the security benefits are very promising, I would not recommend scrypt until both algorithms and its implementations are protected.

How do these three actually compare? scrypt paper has a comparison:

In fact, even PBKDF2 makes it expensive for anyone but the government to crack a single 8-character password.

Answer 2

You can always ignore the last 10 characters of the fast SHA-256. Or xor the first 10 characters to be included.

SHA has a variable number of rounds. Two rounds of SHA must be reversible. I have a vague idea that 20 rounds are considered "safe." 30 rounds should be "very safe", and 50 rounds practically do not improve security.

SHA is designed to be safe - not hoping the cracker has a slow enough machine, but with mathematical proof. If and when the number of irreversible bits in each round increases and shifts to a 256-bit hash code, there will never be enough computer power to try all the possible sequences that generate this particular hash code. There is not even enough energy in the Universe to wrap a 256-bit counter.

If the line creating the hash is very small or written on a post on some monitor.