I'm thinking about ways to encrypt an endless stream of data (e.g. a video or audio feed) in a way, where a compromise of the current internal state of the encryption (e.g. a RAM dump) does not comprimse data encrypted earlier without knowing the seeding parameters (Key, IV). A stream cipher would be preferrable to a block cipher, because this way one could guarantee that there are no incomplete blocks of data waiting for encryption.
Generating a pseudo-random one-time-pad-like key stream and saving this encrypted asymetrically might solve the problem, but does not seem to be very efficient; more practically one might pre-generate key blocks using a stream cipher, and only encrypting the IVs. I'd expect that there might be a known solution using symmetric ciphers (e.g. AES) too, but I can't seem to find one.
Common cipher modes do not seem to be suitable, since all of them use a constant key for the AES encryption, which allows to revert all encryption already done.
I reckon that this cannot work well with a constant key -- only discarding the IV from memory would not prevent reconstructing it; replacing a counter mode counter with a non-revertable hash chain would be susceptible to partial-known-plaintext-attacks (e.g. predictable video headers) and using an PRNG instead of a counter would only relocate this problem to finding a suitable PRNG that is not susceptible to a leaked internal state (e.g. by still having its seed in RAM).
Some similar ideas have been documented by https://bitslog.com/2013/02/22/block-ciphers-modes-with-forward-secrecy-for-cryptocatotr/ for the OTR protocol.
Is there a trivial reason why the common block cipher modes appear to only vary the plain text input of the block cipher, but never the key?
Is there maybe a well-known block cipher mode providing such a stream cipher that I failed to identify as such?