# Using bcrypt to always produce the same hash like SHA, MD

I want to take advantage of the slow property of bcrypt to hash an input but also want to get the same hash value for the same input every time just like SHA, MD, etc.

So in order to do that, instead of using a static salt, which is less secure I believe, I am thinking to use the input as the salt as well? The output will be the hash value minus the front salt bit (obviously the input itself).

Basically Given an input m, bcrypt(cost, m, m) -> ctext, no concatenation at the end.

So the question is does using the input as both the salt and password make the key derivation step less secure based on the property of bcrypt?

• Why won't a static salt produce the same hash? Aug 25, 2021 at 5:16
• Salts are per password. i.e. 1 salt per password. It's static for that instance of that password. It's not common across passwords. Aug 25, 2021 at 6:45
• If you generate a salt per password, you get different hash every time. No, for one password, you generate only 1 salt. i.e. when user1 creates pwd1, you use salt1 while creating the account. And then while checking his password, you use the same salt1, so you will get the same hash. Everytime you use the same pwd1 & salt1 combination, you will get the same hash ((if you are using the same number of rounds everytime, which you should). Aug 25, 2021 at 7:52
• bcrypt is a password hashing function. It's NOT a normal cryptographic hash function, and it's often unsafe to use it as one (possible DoS attacks). Aug 25, 2021 at 13:05
• Also salts are per (user,password) pair: as long as the user keeps the same password, they keep the same salt. If the password changes, the salt should change. If the user is different, they MUST have a different salt. Aug 25, 2021 at 13:07

As mentioned in the comments, bcrypt is a password hash, and has significant limitations compared with a general cryptographic hash function.

Using it as intended, for password input, but with the salt the same as the input, is as secure as using no salt at all. The purpose of the salt is to prevent multi-target attacks and prevent the use of rainbow tables. If the salt is the same as the input, this allows those attacks, since an attacker now knows what any salt will be for a given target password.

Using it as a general hash function runs into a completely different set of problems, the worst being collisions. bcrypt has a 72 byte input limit on the input text, if you hash large pieces of data it will have the same hash as its 72 byte prefix. bcrypt also repeats short inputs until it fills the 72 byte state array, so an 18 character password will have the same output as that password repeated 4 times. Implementations may pre-hash the input with something like SHA-512 before it gets to bcrypt, which prevents those issues. Though in that case, even though it is slow, its output is still only 192-bits in length, which substantially limits its collision resistance for use in things like digital signatures.

With all of those limitations, there are clearly better options if you want to slow down a hash function, the most obvious is to just repeatedly run the output of the hash function through again. This is also less complex than bcrypt, and can allow you to reuse already existing functions in both software and hardware. If you are concerned about getting stuck in a hash chain for some reason, you can always add a simple iteration counter word to the input. For some parameterized hash functions you can also increase the internal round count. Keccak for example can easily be extended to use more rounds, some implementations that generate round keys algorithmically may only require the change of a single line of code.