Best way, how to convert 32-byte Keccak hashes to positive numbers up to maximum? I have 32-byte Keccak hashes and I have some maximum number, for example 500, how to uniformly convert those hashes to pseudo-random positive numbers up to that maximum? 
I mean I have for example 100 quite random hashes and I want to distribute them so the result would be something like 80 numbers hit once, 19 twice and 1 hit three times (I guess something like that), somehow uniform distribution. 
The maximum can be over 32-bits, so I need to use 64-bit integers. 

Some approaches come to my mind: 
a) always take first 8 bytes, convert them to 64-bit integer and use modulo 500 on them, 
b) sum 1st 8 bytes, 2nd 8 bytes, 3rd 8 bytes and 4th 8 bytes to 64-bit integer and use modulo 500, 
c) something better?

I know that modulo is not the best for uniform distribution, because it slightly prefers numbers at the beginning of the range, but I think I google how to overcome that by myself and I think it's not even a big deal. 

The other thing I am not sure about is whether all the bits in Keccak hashes are quite uniformly distributed, but I guess they should be. I hope that some bit doesn't favor 0s or 1s so some numbers don't get an advantage during my conversion.
Your "32-byte Keccak hash" doesn't look like a canonical, binary Keccak output, but rather appears to be encoded with some Base64 variant—to me it appears to be the MIME version.  Your comments on the matter confuse me whether that is the case or not; you should check your language or library's documentation.

If it's Base64 then it appears to be encoding a 18 bytes of raw binary output, which is 144 bits.  This is a unusual output size.  I would double check how your software is generating that output, and verify that all of that Base64 string really reflects a 144-bit Keccak output, and that there aren't some constant bytes being prefixed or suffixed to it.  Again, your description and comments are not helpful in this regard.



Taking the modulo is fine in practice if you do it over a large enough input set. 
 Appendix B of NIST SP 800-185 contains a recommendation that uses modulo to convert the output of an extendable output or variable length hash function into a near-uniform natural number $0 ≤ n &lt; R$ for arbitrary $R$.  The trick is that they make sure to do it over a hash output that is at least 128 bits longer than the number of bits needed to encode values in the output range:


Compute $k = \lceil\log_2(R)\rceil + 128$, where $\lceil\log_2(R)\rceil$ is the number of whole bits needed to encode $R$ distinct values.  For $R = 500$, this is $k = 9 + 128 = 137$.
Hash your input to an output $Z$ with length of at least $k$ bits.  Since your outputs are at least 144 bits, they meet this requirement. 
Convert $Z$ to some "bigint" data type (arbitrary precision integers, check library support in your language; e.g., in Java it's BigInteger).  The bits_to_integer algorithm they detail in the document just parses $Z$ as a binary numeral with least significant bits first, although that later detail is not critical (e.g., Java BigInteger parses them in the opposite order, and that's just fine).
Take $N = \mathit{bits\_to\_integer}(Z) \mod R$ as your result.


The trick that allows them to use modulo is that they're willing to accept a biased distribution if they can guarantee the bias is astronomically small.  That's why they insist on taking a hash output 128 bits longer than the number of bits needed to encode $R$.  Suppose we used $R = 500$ but $k = 9$ (instead of the recommended $k = 137$).  The problem here is that since $2^k = 2^9 = 512$, when you take the modulo, 488 of the values have a probability of $1/512$ but 12 of them have a probability of $2/512$—they're twice as likely as the others.

Now suppose we take $k = 10$ instead, so $2^k = 1,024$.  Now when you take modulo 500, there are 476 values in the range have a probability of $2/1,024$ but 24 of them have probability of $3/1,024$—they're only 50% more likely than the rest.  For $k = 11$, $2^k = 2,048$ so you get 452 values with probability $4/2,048$ and 48 with $5/2,048$ (only 25% more likely), and so on.  By the time you get to $k = 137$ the bias is negligible; footnote 12 of the appendix gives:

$$
|\mathrm{Prob}(N=t) - 1/R| ≤ 2^{-w}
$$

...where $w ≥ \lceil\log_2(R)\rceil + 128$.