I get that /dev/random is a good source of entropy, and is what is usually used-- It's just as I'm reading up on GC, at least in Java, it seems accepted that the garbage collection daemon executes non-deterministically. If this it true, why don't we use the timing of the garbage collection as a source of entropy instead of the variable /dev/random?
"Unspecified" and "random" are two entirely different concepts.
The exact workings of a garbage collector are not specified and are up to the garbage collector (usually implemented by a VM of sorts, but not necessarily).
Therefore, you have no specified (i.e. deterministic) time at which garbage will be collected.
However any given implementation will follow some rules and there is a high chance that two subsequent runs of the same program will have very similar garbage collection patterns.
Therefore the actual entropy provided by a garbage collector would be very low (and finding out which parts you can actually use as entropy will be tricky).
As a comparison: A
HashMap in Java doesn't guarantee any order of retrieval for its members (basically because guaranteeing it would add an overhead that's not worth paying, most of the time). However for a given implementation and a given set of insertions/removals you can definitely calculate the resulting order. Just because there is no guarantee for any given order, doesn't mean that the order is random.
Firstly, we have to be careful not to fall into the trap of reasoning by manipulation of mere words. For instance, we could ask, since a NFA is a "non-deterministic finite automaton", why don't we use it to obtain random numbers? In that case, it would be because that's not what "non-deterministic" means in an NFA; in fact, when we simulate an NFA, on a given input, the behavior of the simulation is perfectly deterministic.
"Deterministic" is a loaded phrase. To a computer programmer or computer scientist, non-deterministic behavior just means "determining the exact behavior is complicated to think about", and depends on too many factors, including the program input.
However, that doesn't mean it's not deterministic to someone motivated to attack a cryptosystem. Sometimes environmental factors and inputs can be pinned down, and repeatable patterns emerge from "non-deterministic" behavior.