# Hash key expansion

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?

• L would have 10^100 possibilities if its elements were chosen independently at random, but they aren't; it actually has only 64^16 possibilities, though there is no easier way to enumerate them than to do all the hashes. – dave_thompson_085 Aug 24 '19 at 5:38
• This looks like a carbon copy of an assignment, in which case you should indicate your own thoughts on how to solve the question to get additional hints. Otherwise the question may be put on hold as off topic. – Maarten Bodewes Aug 24 '19 at 12:26
• I don't get "the nonce N is then mapped to a final result". The nonce N is an input parameter, right? That cannot be right. I'll put the question on hold until these issues are resolved. – Maarten Bodewes Aug 24 '19 at 12:29
• @dave_thompson_085 all the items in the list are numbers between 1 and 10 which depend on the first byte B of the hash H, not on the hash H itself. Why would L hold 64^16 possibilities? – enriquejr99 Aug 24 '19 at 13:06
• @MaartenBodewes it's not an assignment, I intentionally phrased the question this way to improve readibility. There is a map created to keep track of which nonce N created the result R. I believe this mapping could hold useful information to solve this problem as the expanded K (i.e. the list L) was created with these values of N, but it may not be necessary to create such mapping. – enriquejr99 Aug 24 '19 at 13:13

## 1 Answer

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.