Is it practical to build a symmetric encryption cipher that needs the changing of the "main" key for each plaintext?

I read about an encryption cipher that needs the changing of the "main" key for the encryption of each plaintext. Sometimes this change depends on the plaintext and is done automatically.

Question: Is it practical to build a symmetric encryption cipher that needs the changing of the "main" key for each plaintext?

[Edit] Some ciphers take some aspects of the plaintext and include it into the key, that is an example of being automated. Is not this okay?

Note: I am sorry, I think the question still has to be refined.

Is it practical to build a symmetric encryption cipher that needs to change the key for each process?

As is, this statement is a contradiction of the definition of a cipher and it's key. The key is defined to be an input to the cipher, thus the cipher itself can't change it. More importantly, attack models (ciphertext only, known plaintext, chosen plaintext, chosen ciphertext) assume key reuse, thus no key change for different messages. That important assumption matches actual field use, and arguably dates back to Kerckhoffs.

It follows the One Time Pad does not match the definition of a cipher. The OTP is at best an encryption method. If something in the input of a cipher must be changed from message to message (which is common), that's not the key, it's an Initialization Vector. If something not an input of a cipher changes as the message is processed, that's not the cipher's key, that's an internal state of the cipher (which can be the key of an internal cipher).

Thus we need to do one or more of the following to make sense out of the question:

1. Replace the word key by internal state initially setup to the cipher's key, that the cipher is now free to change. That's a fair match for what's asked, is practical, but not quite mainstream. For example, it makes sense to change the key of a block cipher after each block, in order to foil some DPA attacks.
2. Replace the word key by internal state initially setup as function of the cipher's key (and possibly other input of the cipher, like IV). Now that's practical, and mainstream (as pointed in this answer): the internal state can be a session key, used as key of an internal auxiliary cipher, derived from the overall cipher's key, and changed after some number of plaintext bytes of the overall cipher. However that's less a match for what's asked, for what's change is an internal key, never matching the key of the overall cipher.
3. Change cipher to method or device. That makes us free to change the cipher's key, and ignore the battle-tested, real issues that users will reuse the key initially fed to the method or device, no matter what prescription against that is made. To illustrate the danger of that reuse, see e.g. this the gizmo in anther answer. Even though it uses Quantum Key Distribution, it still needs an initial secret key (source) sent by traditional means like a trusted courier. If that secret is reused because the QKD link gets out of sync, the security claim of the gizmo falls apart.

Some time this change depends on the plaintext and is done automatically.

That's no unheard of, and is OK at least in thory. A block cipher in CBC or CFB mode, and some other ciphers, change their internal state according to plaintext and key. However the mixing of plaintext and key must be carefully analyzed, for it can open to some attack.

tl;dr– The common example of a symmetric-crypto-transform that uses a different key each time would be one-time pads (OTP), where the key is a yet-unused subset of the one-time-pad that's a shared secret between communicating parties. Ratcheting-schemes may mutate their keys each step, and other schemes might vary their keys too.

Symmetric-ciphers with changing keys.

A symmetric-key is a secret known to both sides. If that'd be changed each encryption, how would each side know the new secret?

Possibilities:

1. They already know the set of keys to be used. This is how the one-time pad (OTP) scheme works.

   • People usually don't think of one-time-pad schemes as a block-cipher since it's not limited to operating on blocks. Still, it's able to operate on blocks too.

2. They mutate prior secrets to generate new ones. For example, perhaps hash the prior-symmetric key. This would be ratcheting.

   • Often the idea is to get forward-secrecy, which is the property of a new key-compromise not compromising the secrecy of older messages.

3. They share information through a different channel.

4. They mutate the key based upon information obtained from a prior message.

Or some combination thereof.

Related concepts.

Related concepts include:

1. Initialization Values (IV).
   Initialization-values are values that change each message to help improve encryption. However, such values aren't assumed secret, so they're not generally considered part of a key.

2. Re-key-ing.
   Parties can do asymmetric-key exchanges to agree on new keys. They could potentially opt to do this before each new symmetric message if they'd care to.

Note: This may require an ordering-scheme.

In some contexts, basic symmetric-crypto implies unordered messages. This is, the decrypt-er should be able to decrypt ciphertexts even if they don't know what order those ciphertexts were generated in.

However, schemes that change keys generally need to address the issue of order since the keys are changing. Maybe they can assume a channel provides ordering; maybe they can tag messages; or maybe something else.

It often wouldn't be a difficult problem to address, though it'd be something to be aware of.

Yes.

I read about an encryption cipher that needs to change the key for each encryption process.

Not quite sure what a "process" is, but yes, automatic key change/rotation is increasingly common. As:-

Keys are (quantum) distributed between sites A and B at a rate of say 10 kbit/s. Those keys are then passed onto physical encryptor devices. These devices use conventional encryption (perhaps AES or the Light Encryption Algorithm) to transmit the bulk of the data at a much higher rate than using the quantum channel (40 Gbits/s).

The encryptor keys can then be changed every few seconds. A 256 bit key can be shared within 26 ms. So it's not quite a pre-process change, but rather periodic. It would not be out of the bounds of possibility to change the encryptor key per data burst/session as you suggest. Switches do after all offer quality of service (QoS) management. This might be an extension of that. And entirely practical.

So it's not the actual cipher that requires the constant key change, but the implementation that uses it. Close enough?

These particulars based on Clavis300 kit.

Yes, it is common practice. Indeed, this is for example how TLS works. For TLS, this process is explained on this page in the step "Client Encryption Keys Calculation".