I have a 256bit fully random entropy source from dices, which is probably not cryptographically secure.
If you roll enough dice, the rolls are fair, and no adversary can monitor them, it is cryptographically secure. The reason is simple: an adversary who can't snoop on the dice rolls can't guess the results in any reasonable amount of time either.
You should concatenate (not add!) the results in the exact order you get them. Each roll of a fair six-sided die has $log_2(6) = 2.58$ bits of entropy, so you need 100 rolls from six-sided dice to get to the 256-bit mark.
The more complex case comes when the dice rolls aren't fair:
- The dice are unbalanced, so that one side is heavier than the others, and thus the side opposite to that one is disproportionately likely. (Casinos use special dice designed to be more balanced than ordinary dice.)
- The dice are rolled in a way that doesn't really randomize the results. (Shaking the dice vigorously in a dice cup is said to improve the fairness of rolls.)
In the case of an unbalanced dice, imagine for the sake of argument that a six is the most likely outcome, and the probability of rolling it is not 1/6 ($16.\overline{6}\%$), but rather 17/100 ($17\%$). Then each roll has a min-entropy of $-log_2(17/100) = 2.556$ bits, so 100 rolls give you $255.6$ bits of entropy—just short of 256 bits.
In such cases you might need more than 100 dice rolls to get to a full 256 bits of entropy. Or alternatively and much more practically, you could just convince yourself that the 100 dice rolls, even if somewhat unfair, are actually way more than enough to provide adequate security. You almost certainly don't need 256 bits of entropy anyway. Why not just settle for about 128 bits? Won't you get bored rolling 100 dice? Be practical!
I have read that it's customary to take the hash of the entropy source in order to generate a safe key.
What you need to do is encode the outcome of the rolls into a 256-bit string so that none of the possible 256-bit strings is significantly likelier than the others. Hashing a string with the results is a convenient way of achieving that.
Somebody suggested to me to take the SHA-256 of the entropy source, but wouldn't that cut the entropy in half,as the SHA-256 actually has only 128 bit entropy?
Hash functions don't have "entropy"—the result is determined by the input, so the result of the hash function can never be more unpredictable than the input. An attacker who has a technique for guessing the input to the hash can use the same technique to guess the output.
That 128-bit security number you allude to is the collision resistance—how much effort it takes an attacker to find two inputs of the attacker's choice that produce the same output. That is not relevant here because your scenario is different: you're choosing the input to the hash function, and you're showing neither the input nor the output to the attacker.
Intuitively, what the output size of the hash function does here is put an upper limit on the difficulty of guessing the result (and thus the entropy of your hashed output):
- If your dice roll input has fewer than 256 bits of entropy, the quickest path for the attacker is to try and guess your dice roll results and calculate the SHA-256 result for each guess. So in this case the output has exactly as much entropy as the dice rolls.
- If the dice rolls have more than 256 bits of entropy, the quickest path for the attacker is to try and test all the possible SHA-256 outputs, without bothering to consider which dice roll inputs produce which outputs. This means that in this case the output can't have more than 256 bits of entropy.
This also answers your questions of "What happens if I cram more entropy into the hash function, say 270 bits" and "What happens if the hash function's output is of more bits than the entropy source (hash 256 bits, but entropy source only 250 bits), what happens then to the security of the key?"
Shouldn't I use the SHA3 variant instead of SHA2 as it's newer and more recommended?
It is extremely unlikely to matter in practice.
