Academic Integrity: tutoring, explanations, and feedback — we don’t complete graded work or submit on a student’s behalf.

I usually choose bcrypt when hashing as I can set the work factor to slow down t

ID: 650174 • Letter: I

Question

I usually choose bcrypt when hashing as I can set the work factor to slow down the calculations of the hash. However, I have to keep a copy of the hash in order to verify it (since it includes the salt) when the same input comes around again.

Are their any A) common and B) slow hashing algorithms that do not require a salt? In other words, I don't need to preserve the output state in order to calculate the exact same hash again?

I am not looking for a more secure/unbreakable hash - just one that takes a long, long time to work out.

At this point it seems that multiple rounds of SHA-256 is my current best option.

Explanation / Answer

You can use any common slow hash construction that takes a salt with a constant salt. This includes scrypt, bcrypt and PBKDF2.

You obviously lose the benefit of the salt. Since the purpose of a salt is preventing multi-target attacks, now an attacker can attack all hashes at the same time. I'd use at least a salt that's unique for your application, so an attacker can't attack your application at the same time as others.

Personally I'd go with scrypt, since it strengthens the most for a given derivation time limit, but you can use bcrypt or PBKDF2 if you prefer older/more popular constructions.

Hire Me For All Your Tutoring Needs
Integrity-first tutoring: clear explanations, guidance, and feedback.
Drop an Email at
drjack9650@gmail.com
Chat Now And Get Quote