Let's consider a block cipher in CTR mode. And let's consider a keyed PRNG or just a good PRNG with a seed as the key. The PRNG has to be very fast.
Is it a good idea to put away the key schedule and do "infinite" key scheduling by generating a keystream? Then every block in the cipher will be encrypted with a different key.
Of course, even a fast PRNG needs some time to generate a few 128 -bit keys for a cipher. But doesn't this greatly increase the security of such an algorithm? If the algorithm itself is a very fast primitive (say, as fast as Chacha20), it should have excellent security and good speed if associated with a "key schedule stream" like this.
However, I suspect that the speed of such a solution may be a significant obstacle. Okay, so let's make a change each time the algorithm is repeated (single encryption)--flipping only one bit of the key per round. If the algorithm requires one key per round and has ten rounds, we only need ten bits. The PRNG will generate such bits very quickly. Then the keys are changed after each encryption, not much (we change only one bit in every key), but it should be a huge obstacle for the attacker.
Maybe we could use something simple such as two rounds of AES but not add another two rounds to the cipher. So, let's use this to generate a keystream to mix with the keys in a new encryption.
My question is about the disadvantages of such a solution. As far as I know, it is not used - why? In other words, why do we use constants and the same keys in rounds (when encrypting vast numbers of messages ) when keys can be modified at a low cost after each encryption; for example, by adding one bit mod 2 (after another encryption, we add another bit on a higher position and so on, changing all 128-bit keys after 128 encryptions).