As Robert's comment points out, you wouldn't be able to decrypt it! Functionally, the purpose of a stream cipher is to stretch a small bit of random data (the key) to an arbitrary length (the key stream) without the losing randomness (becoming predictable). In other words, a stream cipher is a cryptographically secure pseudo-random number generator that takes the key as a seed, and produces arbitrarily many bits, each seemingly totally random, from it.
This fundamental operation is performed for both encryption and decryption. As such, the key stream must be repeatable, given the same inputs (key and any nonce/IV). A TRNG is never repeatable, so the decrypting party would never be able to re-generate the key stream and thus could never decrypt the data.
You may be confusing stream ciphers with one-time pads. In a one-time pad, you generate the entire "key stream" (the pad) before hand, and distribute it securely to the recipient. For that, a TRNG is ideal; you just copy the data it produces so that each side has one copy, and make sure nobody else can ever see it, and never use any given pad for more than one message. However, that means if you want to transmit a 4GB file, you need to have first distributed a 4GB pad to the recipient. If you then want to transmit another 4GB file, or even the same one to another recipient, that's another 4GB of pre-generated pad used up. Meanwhile, with a stream cipher, you only need each pair of parties to share a small bit of secret data (128 bits - 16 bytes - is common), and you send another 16 bytes or so of additional per-message data (called an Initialization Vector or Number used Once) that doesn't even have to be secret.
Another practical problem with one-time pads is that there's effectively no way to securely send the pad on demand. With a short symmetric key (such as a stream or block cipher), if you know the recipient's public key, you can either generate a brand new key (potentially from a TRNG) and then encrypt it to that public key, or generate brand new ephemeral Diffie-Hellman parameters (also potentially via TRNG), and use them to exchange a key. Asymmetric cryptography, including key exchanges, is computationally expensive, but you only need to do it one time, for a tiny chunk of data (the symmetric key), for any communication; you can then send multiple messages of arbitrary length using that key. However, there's no way you could send an entire one-time pad in a reasonable timeframe this way (and even if you could, you shouldn't; you lose all the benefits of one-time pads vs. asymmetric ciphers if you do this, so you would just encrypt the data directly). Using asymmetric crypt to exchange a symmetric key, and then using a symmetric (stream or block) cipher with that key, you could encrypt and decrypt gigabytes of data in less time than it would take asymmetric crypto to handle a single megabyte.
EDIT: Given your comment, it sounds like you don't understand stream ciphers, or at least not the distinction between a stream cipher's key and key stream (often written keystream).
The key is:
- Totally random.
- A TRNG is a good source for keys, though you can use a CSPRNG too and in practice that's common as TRNGs aren't always available).
- Generating the key from a password, through a key derivation function, can be done but the key will be much weaker than its length.
- Short.
- 128-256 bits - 16-32 bytes - is typical.
- Unless the cipher has any "weak keys" that are unsafe to use, the length of the key is typically the entropy ("strength") of the key (though see the disclaimer above about derived keys).
- Necessary for encryption and decryption.
- If the same party is doing both operation, the key - or materials to derive it - must be stored somewhere.
- If the key is used to secure communication between two or more parties, then the key needs to be shared (in a way that doesn't expose it to outsiders) before the communication can take place.
- Used as an input to the cipher function (along with the IV/Nonce) to generate the key stream.
- Does not directly interact with the data.
- Can't be derived from the key stream (that is, the key -> key stream function is one-way only).
The key stream (or keystream) is:
- Pseudorandom.
- It looks random, shouldn't be possible in practice to predict any given bit, even after looking at any number of other bits.
- However, it is actually deterministically derived from the key and IV by the cipher algorithm, which is in effect just a seedable CSPRNG.
- Arbitrary length.
- The key stream used to encrypt or decrypt any given message is exactly the length of that message.
- The operation of a stream cipher function is essentially to "stretch" the key to an arbitrary-length key stream.
- Directly used for encryption and decryption.
- Typically, the key stream is XORed with the plaintext to generate ciphertext (encryption).
- The ciphertext is XORed with the same key stream to re-generate the plaintext (decryption).
- Thus it must be possible to re-generate the key stream if you ever want to decrypt the data!
- Typically not stored anywhere.
- Remember, it might be of any size.
- Instead, the cipher function generates as much of it as is needed on demand, using the key and IV as inputs.
- Unique for each message. Even when the key is static, you want a different key stream for each message (otherwise somebody who knows one message's plaintext and ciphertext could decrypt another message). That's what the IV is for.
Functionally, a stream cipher looks like this:
PRF = Cipher(K, IV)
N = Length(M)
S = GetBits(PRF, N)
Encrypt / Decrypt: M XOR S
where:
- PRF is the pseudorandom function for a given message, generated by initializing a stream cipher algorithm such as CHACHA20 or RC4 (obsolete and broken, do not use).
- K is the key, as described above, passed to the cipher algorithm to instantiate PRF.
- IV is the Initialization Vector or Nonce; unique for each message but not required to be secret, allows encrypting multiple messages securely with the same key, passed to the cipher algorithm to instantiate PRF.
- M is the message (in plaintext or ciphertext, for encrypt or decrypt respectively).
- N is the length of the message M in bits, not counting extra data such as IV or authentication tag.
- S is the key stream, as described above, generated by requesting N bits from the PRF. For large N, S is typically generated sequentially (it is a stream) in chunks smaller than N, but the sequence generated is fixed for any given initialized PRF.
- XOR is the bitwise eXclusive OR function.
- Both encryption and decryption are performed by XORing S with the plaintext (encrypt) or ciphertext (decrypt) version of M.
Hope that helps! If you need more info, there's lots of explanations of stream ciphers online; do some searches and, if you're still confused, open a new question (possibly on crypto.SE, if it's about how a class of ciphers work rather than about how to securely use them)
