0

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.

Meir Maor
  • 11,835
  • 1
  • 23
  • 54
  • The expected number of hashes doesn't tell you anything about possible extremes. – Elias Apr 25 '17 at 14:45
  • 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. – Meir Maor Apr 25 '17 at 15:39
  • 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. – Elias Apr 25 '17 at 15:55
  • 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. – Meir Maor Apr 25 '17 at 17:10
  • It's more of a software engineering answer than a crypto answer, but what's wrong with NULL? – bmm6o Apr 26 '17 at 00:56
  • I didn't test what happens with malformed hashes. From a practical perspective the random is plenty secure. The crypto question is a curiosty rather then a practical need. I was simply providing the background whyvI thought of this question. – Meir Maor Apr 26 '17 at 03:14
  • @MeirMaor Yes, you could say it conflicts with the primary objectives but it doesn't conflict with the definition. And afaik there are no proofs for practical hash functions showing that they are PRFs. To clarify: I'm not saying what you are looking for exists. I'm just saying your reasoning why it cannot exist doesn't work. – Elias Apr 26 '17 at 08:22

1 Answers1

2

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);
        ++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.

bmm6o
  • 1,067
  • 6
  • 17