Key stream instead of key schedule

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).

• CTR mode is used to turn a block cipher into a stream cipher. Block ciphers are pretty useless for encryption (since they can encrypt one block per key safely) so we use different modes of operation to actually encrypt things with them. There are also native stream ciphers, effectively keyed PRNGs, that don't have a block cipher internally. You're proposing internally keying a block cipher with a stream cipher, then using it in CTR mode to turn it back into a stream cipher. Why not just use the stream cipher directly? What advantages would your construction have? – SAI Peregrinus Jun 14 at 14:00
• The advantage is a higher level of block cipher security. Moreover, if we could build a block cipher improvement with this technology - which is faster and at the same time more secure than the original algorithm - why not use it? If AES with shortened rounds but keying with a stream cipher would be faster, why not do it? Perhaps there are algorithms that can be improved and accelerated this way. Having underlying key generator, independent of the cipher could be big improvement in terms of security, I think. – Tom Jun 14 at 14:23
• Leading questions: Would this improve security over a stream cipher? ChaCha20 is (arguably) more secure than AES-256, for the same key size. Using ChaCha20 in place of AES's key schedule would remove the weakness of the key schedule that makes AES weaker, but would it make the resulting cipher slower or faster, and would it be meaningfully more secure than ChaCha20? Why or why not (try to prove these things to yourself)? – SAI Peregrinus Jun 14 at 15:26
• To decide is it worth we have to cut few rounds of AES and replace them by key streaming. No I can't say will it be worth it. But I suspect we can get faster and more secure cipher this way. I asked a question to find out is it obviously bad idea in some way. Of course now I have no idea is it doable with any cipher. But the fact that we use "permanent" keys in cryptography so commonly seems to me incomprehensible from the point of view I have presented. – Tom Jun 15 at 0:00
• AES's key schedule is VERY fast. It's not a bottleneck for AES. Replacing it with ChaCha20 would slow things down, and add no extra security beyond what you get from the stream cipher alone. Even if you reduced the round count. Also we rarely (if ever) use permanent keys. Most keys (eg for TLS connections) are ephemeral, they get deleted as soon as the connection is closed. Disk encryption keys last longer, of course, but that's mostly because disks have a lot of data and re-encrypting it would be slow, not because the key scheduling is slow (it's not). – SAI Peregrinus Jun 16 at 1:48