Combining a keystream with data
A common synchronous construction generates a pseudorandom stream from its secret key and specified inputs, then XORs it with plaintext. Decryption uses the same stream position, so key, initialization and position must agree.
Only the needed portion of a final output block may be used. An internal block generator does not necessarily require padding plaintext to that block size; packet boundaries and application calls are separate framing and interface matters.
References: [1]
ChaCha20 generates blocks from counters
The IETF ChaCha20 form in RFC 8439 uses a 256-bit key, 32-bit block counter and 96-bit nonce. With a fixed key and nonce, successive counters generate successive stream blocks, separating message initialization from block position.
A program can generate and combine blocks incrementally instead of storing the whole stream. Usage and counter bounds still prevent wrapped state from becoming apparently new output. These dimensions belong to this construction rather than every stream cipher.
References: [1]
Avoiding reuse does not replace authentication
Reusing one stream portion for different plaintexts exposes their XOR relation through the ciphertexts. RFC 8439 therefore stresses nonce uniqueness under a key; a new filename or repeat call with the same state is not an independent keystream.
Stream encryption alone need not authenticate data. The specified ChaCha20-Poly1305 combination provides AEAD, unlike standalone ChaCha20. Accepting a message requires correct tag and protocol checks rather than merely obtaining displayable decrypted bytes.