Are there any practical differences between running a PRNG on a subset of bits from an RNG compared to running the RNG? Given an RNG and a PRNG.

We define RNG(k) to mean that the RNG produces k random bits.

We define PRNG(k, seed) to mean that the PRNG uses seed to produce k pseudo-random bits.

Case 1: - Generate n random bits using just the RNG.

bits = RNG(n)

Case 2: - Generate n random bits using the PRNG, and using the RNG as a seed

seed = RNG(n/2)

bits = PRNG(n, seed)

My question is whether there is any practical or even theoretical difference to these in terms of security? 


From an outsider, I am assuming that both would seem to be completely random bits.
How does the amount of random data fed to the PRNG from the RNG affect the randomness? My intuition is that if the PRNG is fed less than 256 bits of random data, then the result from the PRNG can be calculated by brute force.
In 99% of cryptography there is no practical difference between your cases as long as $ |seed| = \frac{n}{2} \ge 128$.  Computational indistinguishability means that the streams from both cases will appear properly random. Our current knowledge is insufficient to invert a good well seeded CSPRNG (your PRNG). Information theory suggests that inversion can't be ruled out, but we can't do it as yet. Perhaps tomorrow or the day after. See P=NP and Kolmogorov/algorithmic complexity. 

The missing 1%.  For the truly dedicated who use one time pads (OTPs), there is a huge difference between the cases.  Information theory dictates that case 1 can create a OTP.  Case 2 specifically requires $ |bits| &lt; \frac{n}{2} $.  Otherwise the output is theoretically invertible. In this case though, the above theorem implies that the output from PRNG need only to not introduce bias.  It need not be cryptographically secure, nor even a dedicated PRNG. A simple random matrix will do.  But it begs the question of why bother if you already have a functional TRNG running at a similar rate?

Consequently, your RNG is more random than your  PRNG from a certain perspective.  It's the same differentiator that separates /dev/random from /dev/urandom in blocking *nixes.