From WAR10CK here:
If I actually do create a machine using RC4 or AES-CTR and have a TRNG continually feed it a constant steady stream of random bits. Provided that the stream of bits is purged after every message, will it meet the perfect secrecy requirement for a OTP?
First, do not ever use RC4.
Second, it depends on how you use that stream...
If you use AES-CTR as a stream cipher (see more here), you will specify a key $K$ (and a nonce $IV$). The CTR mode of AES will generate a stream of bits, whose length matches the messages. All that is required is to XOR it with the message.
In order to decipher. One will require the key $K$ (or nonce $IV$), regenerate the stream and XOR to retrieve the plaintext.
If a brute force attack were to happen, it would be on the nonce + key (its size is smaller than the message).
On the other hand, if:
you were to generate a really long stream of truly random bits in advance,
send it to your partner through a secure way and
use parts of that stream to encrypt messages for him only (without any reuse of the generated stream).
Then what you are doing is a Vernam Cipher, not a stream cipher (unless I am wrong). This was the way they exchanged message between USA and URSS (exchanges disks of random bits for single use). And yes it would be perfectly secure.
One of the requirement of the Perfect secrecy is the key space has to have the same size as message space. Hence the key and the message must have the same length. In the OTP or Vernam Cipher, this is the case. In a Stream cipher, given that the key is used to generate a stream, whose length is greater, it does not meet the Perfect Secrecy requirement (while still being reasonably secure).
The question in the comment of WAR10CK itself is erroneous (note that it is a comment below his answer, where he himself asks this question).
RC4 accepts a key and creates a key stream. AES-CTR accepts a key and a nonce and creates a key stream. If the final XOR is included you can also say they accept a plaintext and output a ciphertext (in addition to the parameters already mentioned). Neither AES-CTR nor RC4 accepts a "stream of random bits" as input.
So some kind of magic is going on within this scheme. Whatever the magic is, it is unlikely that it will manage to become an OTP when mixed with either stream cipher. By definition the key must still be larger than the message that is encrypted, so if it would be an OTP, it would not have any advantage over directly XORing the output of the TRNG
As Shanon proved in his famous paper, the important need a cipher to be a perfect cipher is: the length of the key be larger or at least the same as plaintext.
In the stream ciphers like other ciphers, the length of the key is very short and we can not build a key in practice be the same or larger of plaintext. In stream ciphers, a key will produce a keystream that this keystream may be long but it is not infinite and after some periods will be finished.
In other words, we can say the only perfect cipher is OTP (One Time Pad) and producing this pad that is random is not practical and if could produce, we can not transfer it through an unsecured channel (because if we could transfer this long key, we could transfer the own plaintext).
So stream cipher and other ciphers that are practical and we are using in the real world, are not perfect ciphers, They are computational ciphers,though.
