Score:0

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

tr flag

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?

et flag
Why won't a static salt produce the same hash?
tr flag
@user93353 not saying it won't, its just less secure if you loss it, you may need to renew every single hash in your system
et flag
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.
tr flag
@user93353 may be I am not clear or you miss the point of this question. If you generate a salt per password, you get different hash every time. If you have a static salt for a particular password, meaning you have a `f(m)->s` for a given message, which is the same as my question, just that my `f(m)->m` is an identical function.
et flag
`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).
tr flag
@user93353 you still miss the point of the question. There is no mention of checking password here. The scenario is you have a value you want to hash (using this bcrypt variant), you hash it, get the hash value, happy days. Next day, you have the same value you want to hash, you hash it, and you expect the same hash value is obtained.
SAI Peregrinus avatar
si flag
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).
SAI Peregrinus avatar
si flag
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.
Score:1
cn flag

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.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.