Can the HMAC function be used as a random number generator, and how well?

Question

Cryptography

I became interested in how the bitcoin-faucet-casino works - the site freebitco.in. I read about their fair play system. Well, the type of number that will fall out is generated based on two strings - server seed and client seed, and we are given the hash of the server seed. The procedure for obtaining a drop-down number is described there as follows:
1. Two strings are created:
STRING1 = "[NONCE]:[SERVER SEED]:[NONCE]"
STRING2 = "[NONCE]:[CLIENT SEED]:[NONCE]"
Example:
STRING1 = "438088:cg6s6edldjfe7r875cm6od916zvwp8nz8w8rx2jxx0u2utnn0wty7d9bn8zg5kul:438088"
STRING2 = "438088:Ydbkf5diyLE1FdsN:438088"
2.It then uses the HMAC algorithm with hash type SHA512 to hash STRING1 with STRING2 as the secret key, resulting in a hexadecimal string of 128 characters.
3. The first 8 characters of the string are taken and converted to decimal.
4. The resulting number is divided by 429496.7295 and rounded up to the nearest whole number.
5. The maximum possible number is 10000.
NONCE is a counter that is different for everyone and increases by 1 each time, so it can simply be stored in the database of the organizers and substituted into the key.
The question arises, is it possible that the organizers use pre-prepared strings for the server seed, which they specially selected so that no one has large winnings or as little as possible (they generated hashes for all possible key values)? Or is it impossible in principle and this function can be used in principle as a random number generator without checks? And it is interesting, if all the same, such lines of the server seed are found, then how often?
Addition: in the client seed, it turns out that you can enter a string of any length (I got 64 characters) with an alphabet of 62 characters, and the server seed for each profile is supposedly different, taking into account the fact that Satoshi can be received for free once an hour, this requires astronomical power for finding such server seeds.
So it is unlikely that there are such seeds for which there will be no maximum winnings (with such and such a number of options), the only question remains on the uniform distribution of numbers - is there such theoretical information about the HMAC function or do you need to write a program for the dropped server seeds and watch the distribution ? Well, from the option of deceiving users, only a hash collision remains, but this is already unattainable ...
In general, I will be glad to everyone who can help or share any reasoning on this issue.

Answer 1

HMAC is not a function, but a hash function usage scheme. Therefore, the answer to the question depends on what hash function the casino organizers use. If it is a modern, well-known hash function that has no known published attacks faster than brute force or known collisions, then it produces uniformly distributed outputs for any input, even if they differ minimally (say, by 1 bit). And these pseudo-random numbers are indistinguishable from truly random ones by any known means. Such functions are, for example, SHA-3 (Keccak) or SHA2^2 from Bitcoin. The Russian GOST "Stribog" is also invulnerable so far.
However, if you stick some obsolete hash function into the HMAC scheme, then there will be opportunities for fraud. For example, collisions are known for MD5, but they are extremely unlikely, therefore, most likely, there can be no fraud even with MD5. However, it is better to bypass it, because it is outdated.
So the main question is what hash function is used in this HMACe. If it is new (especially the state standard SHA-3 or "Stribog"), then fraud is impossible if there are no jambs or leaks in the program code.

Answer 2

If the main seed is unfolded in reverse order and by simple calculations the number that fell out is obtained, then it can be argued that the seed hash is generated in such a way that it can be safely calculated using more abstruse calculations with only seed hash-256, client seed and nonce.
It's all about the numbers, which most simply do not know.
You have the number because this is an example and we used one roll to understand the system.
On numerous hash generation algorithms, this number will look different, but on certain algorithms, this number is generated into the same hash.
It turns out, it would seem, take seed hash-256, client seed, nonce, and generate yourself in sha-512, and then take only 8 hexadecimal characters from the received string at the beginning, translate it into a decimal value and yes it will be exactly the same as with the main seed, but it wasn't there.
Completely different numbers, and numbers are everything.
The confusion is only due to the fact that the already received hash from the number is passed through a certain list of algorithms.
Thus, somewhere at the depth of the matrix Mariana Trench, the generated seed hash-256 itself was once some kind of symbols, or a number, or maybe two or even three.
The same with the client seed, and the nonce is visible to everyone in Africa.
It turns out that before subtracting and multiplying, or adding and dividing something, you need to get something from that very Mariana Trench.
But how to do it?
To begin with, having at least some information like seed hash-256 and client seed, you need to determine what algorithms this data went through before becoming itself.
Knowing this information, you can go in reverse order to a number that may give something :)
Then these numbers are compared and calculated.
True, most likely not only the number 429496.7295 will matter here, but also the percentage and coefficient, and possibly even the maximum value of the roll, but that's a completely different story...