Why is the output of a True Random Number Generator (TRNG) insecure after it has been compressed?
I think you're misinterpreting the source. The source says the TRNGs &quot;rely&quot; on compression (a cryptographic hash would be the compression function, or possibly some simpler function to increase throughput).
The random data isn't insecure after compression, it's insecure before compression.
Why?
When you roll dice there's an equal probability of it being any one of the possible values, but let's say the dice aren't quite perfect - in nature you'll find things are almost always more like weighted dice than perfect RNGs.
If the output is biased it means it's less likely to produce certain outputs, breaking the security of an RNG - for a CSPRNG to be secure it must produce every output with equal probability, and a TRNG isn't exempt from that rule.
The solution is to take more random bytes than you plan to use, then use a compression function to merge them. It could be as simple as XORing every pair of bytes, or as thought-out as a cryptographic hash, but you need something to even out the probabilities.
That said, using a compression function like what's used to shrink your ZIP files would be an easy way to mess with the probabilities in a way you don't want, so that should be avoided, but that's not what they were referring to.