Ajedi32's answer is a great one. I wanted to emphasize one detail which may help answer your question better. The key to secure password generation is to ensure that your password is unpredictable. Not "random." The idea of random comes later. The goal is unpredictable. If you think about it, the most secure password in existence is not a random one, it's whatever the last password the attacker would guess is. Its the one they couldn't predict.
Now, in practice, there's a cat and mouse game going on here. If you try to come up with the most unpredictable password, they'll try to predict how you generate passwords. This is why passwords like qazxswedc appear random, but once they figure out what you were doing to generate the password, they'll break it easy.
This is where randomness finally comes in. For modern cryptography, we strive to use numbers that are not just unpredictable to the attacker, but unpredictable to anyone, including yourself! Random numbers are numbers that literally cannot be predicted in any way. You can only know what numbers got chosen if you were watching when the numbers were generated. Randomness means you can make mathematical statements about how hard it is to predict a password, because not even you, yourself, were in control of the generation.
For thousands of years, dice have been a "standard" source of random numbers. There are plenty of others (I Ching divination, for instance, traditionally used a bundle of yarrow sticks), but dice have persisted for a long time. If cast properly (no helicoptering!), they are sufficiently good random number sources because the bouncing of the die is highly chaotic and unpredictable. You would need telekenesis to affect the results (think Star Wars: The Phantom Menace).
If you are worried about loaded dice, as mentioned by some in the comments, you can actually do statistical analysis to determine how many bits of entropy per roll you can actually rely on. Password generation is less sensitive to loaded dice than casinos are (you can always make extra rolls, multiplying the number of possibilities. Because casinos dole out cash, they don't get to multiply each round, they have to add. This makes them more sensitive).
So now we can get closer to your question, because we understand what you are trying to accomplish. Simulating the dice actually doesn't work as well as you might think, because the simulation will do the same thing every time unless you have a source of randomness built into the sim, which kind of defeats the point.
The question is: what random source can you trust? This is where you have to understand your threat model. What can your attacker do? Can your attacker read your keystrokes? If so, you're in trouble because you're going to have to type the password in. So, practically speaking, we can assume that the attacker does not have enough control over your machine to be able to read the keystrokes.
You can keep working from there. My guess is that your threat model assumes that your computer is pristine, in which case you can rely on time-tested sources of entropy, like /dev/random
. In this case, the best answer is to draw from that source and use it directly (no dice simulation required).
If you are more concerned with security, you can look at other aspects. Some algorithms have trouble with side channel attacks that let an attacker peer into their state in some specialized circumstances, so you might harden your algorithm against those. You might decide that you don't trust the normal sources of entropy on a computer (such as time between keystrokes and network activity), so you might invest in a hardware source of randomness (often built around noise in a resistor network).
But no matter where you go with it, remember that the key is to be unpredictable, and the standard way to make sure your opponent can't predict you is to be so random that you can't predict yourself.