In a system which requires a user to have a password, as a quick workaround I wrote random junk as the bcrypt hash so that no one will be able to login to that user. However theoretically there probably is a password which matches this randomly selected hash value.

I was wondering if it could be possible in such a scenario to specially craft a hash value (possibly using a different supported algorithm other then bcrypt) for which it would be guaranteed that there is no preimage.

For bcrypt I suspect this wouldn't be possible, since if my math is correct the expected number of hashes with no 75 char password preimage is (1/e)^(2^416) also known as 0.

But perhaps for another common password hashing algorithm these values would not only be expected but there will also be a way to find such a value.

  • $\begingroup$ The expected number of hashes doesn't tell you anything about possible extremes. $\endgroup$
    – Elias
    Apr 25, 2017 at 14:45
  • $\begingroup$ if bcrypt is psrf then this is a balls into bins problem, and if the expected number of hash values with no preimage is so low it also provides an upper bound on the probability of any such existing. $\endgroup$
    – Meir Maor
    Apr 25, 2017 at 15:39
  • $\begingroup$ The distribution must be indistinguishable but not the same. Nothing precludes a PRF from having a value that it never outputs as long as there are sufficiently many values such that an attacker will never know. $\endgroup$
    – Elias
    Apr 25, 2017 at 15:55
  • $\begingroup$ If a function has more values with no preimage then it will also have more collisions. Making collision attack infentesimly faster(though the details ellude me at the moment). With second preimage it is trivial that if a function only produces 2^n-1 outputs a second preimage will take 2^n-1 expected invocations instead of 2^n. Though this is of no practical implications, more values with no preimage clearly cause issue with primary requirements. $\endgroup$
    – Meir Maor
    Apr 25, 2017 at 17:10
  • $\begingroup$ It's more of a software engineering answer than a crypto answer, but what's wrong with NULL? $\endgroup$
    – bmm6o
    Apr 26, 2017 at 0:56

1 Answer 1


This is mostly answered (in the negative) in Do well-known hash functions have any "impossible" output values?. Cryptographic hashes typically don't have enough mathematical structure to talk about things like the number of pre-images a particular value has. You can do much better analysis of some non-cryptographic hashes like CRC32, since they have so much mathematical structure. In general, uniformly covering the full domain is a design goal, so the property you are asking about would be seen as a weakness.

Of course, it's not hard to design a hash with the property you are looking for. Given any hash function $h(x)$ you can define

function H(x) {
    var count = 0, result = 0;
    do {
        result = h(x . count);
    while (result == 0);
    return result;

Essentially you are just re-hashing any time you would return the "reserved" value.

All that said, the typical way to solve this problem from an engineering standpoint is to use a value definitely outside the set of possible values, like NULL. This has the advantage that it survives changing your hash functions.


Your Answer

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

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