Hash key expansion

Question

A hash H is given by H = SHA256(K + N), where K is an unknown 64 character hex key and N is a known nonce.

The nonce N is then mapped to a final result R between 1 and 10 using R = CEIL(B/25.6), where B is the first byte in the hash H.

A list L is populated with the first 100 results R using different values of N for each hash. Therefore, L now holds 10^100 possible combinations as each item is an integer between 1 and 10.

On the other hand, K holds only 64^16 different combinations.

As 10^100 > 64^16, it would be harder to brute force the list L state than it would be to brute force the unknown key K. If no collisions existed, L would also contain enough information to link back to a single key K. Therefore, L would essentially be an expanded (i.e. more complex) version of K.

Can we find the R value for N 101 by using L (i.e. the complex K) instead of K?

Answer 1

No, reversing the KDF should be about as hard as brute forcing it using the key. The key basically consists of 32 bytes (two hex chars making one byte) which means 256 bits. As we're not looking for collisions the hash function the full 256 bits of security should be available.

Basically your KDF is a reduced output version of KDF1/2, which are known KDF's, so you may simply lift on the security of those schemes.

---

I'm slightly worried about your mapping method though. It is very inefficient - so you need many runs of the KDF for no good reason. Worse, it is biased as division by 25,6 will have to be rounded up or down at some kind of level of precision.

To improve it directly you could interpret the whole output of the hash as unsigned value and then divide it by a bigger number to get in the range [0, 10), using a high level of precision. That would at least remove most of the bias. If you changed the range to, say [0, 1000) they you would still be less biased than the original and more efficient.