1
$\begingroup$

Setting aside questions of if BCrypt should even be used in this way, I was just wondering which one would be more secure hypothetically.

If you want to know why I don't just use random salts as per BCrypts default, it's because there is no way of telling which hash digest is the one that should be checked against in my specific use case. Hence, I have to hash the entered string and check if the result is present in a database table. If the salt is randomized there's no way to determine if the digest is present in the table short of checking each one.

If it makes any difference, the data being hashed is not passwords, they are randomly generated hexadecimal strings of 32 characters.

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ Welcome to crypto.stackexchange - "What is more secure" depends on what you are actually trying to accomplish and what the threats are. If you can include that information into your question you'll get a better reception and more/better answers. $\endgroup$
    – Ella Rose
    Mar 16, 2019 at 2:26
  • $\begingroup$ If you can prevent unauthorized enumeration of database entries and use cryptographically random IDs, you can even get away with not hashing at all. That's just one of the design strategies, $\endgroup$
    – DannyNiu
    Mar 16, 2019 at 6:22

1 Answer 1

Reset to default
2
$\begingroup$

bcrypt is a password hashing method. That means that it expects a password as input parameter. It has been designed so that it is hard to perform an offline test of guessed passwords by having an explicit work factor.

It accepts (or requires) a salt so that:

  1. repeated passwords do not show up;
  2. that it is impossible to build a (rainbow) table.

Now your entry is not a password. It is a secret value consisting of 16 bytes or 128 bits. That it is encoded as 32 hexadecimal digits doesn't make any difference, assuming that each hexadecimal digit is equally likely.

Correctly guessing a fully random 128 bit secret is similar to guessing a 128 bit AES key. This is not likely to happen soon. For this reason you do indeed not need bcrypt for the additional work factor

Similarly, if it is indeed fully random, then you do not need a salt either. The salt makes the result probabilistic, so that you don't get the same value back. However, this seems at odds with your requirements to lookup the hash.

If you don't want to expose your secret then you could use a key based key derivation function (KBKDF) rather than a password based key derivation function (PBKDF). Such a function transforms a secret into another secret of given size. If you don't use a salt then the result will be deterministic and you can check for the value in a table. HMAC-expand is one of the later algorithms that you could use.

For your use case you could also use a more generic Pseudo Random Function (PRF) directly. HMAC is a good example of a PRF that can be used for derivation as well. If push can to shove you could also use a SHA-256 I suppose, as a poor man's KDF / PRF. Theoretically hash functions may not adhere to strict requirements for key derivation, but in practice a symmetrical-crypto-based hash function such as SHA-2 will probably fit your need.

Whichever scheme you use, it makes sense to make sure that your scheme doesn't perform the same operation on the original secret as the KDF/PRF/Hash. If you want to make sure that it doesn't: use a KBKDF with a specific label and/or static random value.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.