2
$\begingroup$

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.

$\endgroup$
4
  • 1
    $\begingroup$ The obvious example would be a one-time-pad (OTP). $\endgroup$
    – Nat
    Aug 10, 2021 at 23:45
  • $\begingroup$ @Nat But one-time pad is not so practical $\endgroup$
    – Crypt01
    Aug 11, 2021 at 3:50
  • 1
    $\begingroup$ Depends on what you're assessing practicality for -- not really for streaming YouTube, but for two friends who want to keep in-contact, pre-sharing a pad for text dialogs requires pretty little space and tends to be easy to do. $\endgroup$
    – Nat
    Aug 11, 2021 at 4:09
  • $\begingroup$ @Nat Thank you. $\endgroup$
    – Crypt01
    Aug 11, 2021 at 4:32

4 Answers 4

3
$\begingroup$

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.

$\endgroup$
8
  • $\begingroup$ Are there not session keys? $\endgroup$
    – Paul Uszak
    Aug 10, 2021 at 15:33
  • 1
    $\begingroup$ @Paul Uszak: session keys are not "the key" (of the cipher). They are an internal state. I'll clarify that. $\endgroup$
    – fgrieu
    Aug 10, 2021 at 15:53
  • $\begingroup$ @fgrieu Some ciphers takes some aspects of the plaintext and include it into the key, that is an example of being automated. Is not this okay? $\endgroup$
    – Crypt01
    Aug 10, 2021 at 16:47
  • $\begingroup$ @fgrieu does not this open the door to building encryption systems by having a prng and xor the result with the plaintext and change the key in each process, as most chaotic ciphers do? Actually, they use it in the main key, not the internal key. $\endgroup$
    – Crypt01
    Aug 10, 2021 at 19:42
  • 1
    $\begingroup$ @ThePrince: "Automated change of the main key for every new plaintext" can't be for a cipher, by modern definition of cipher and key, since in a cipher the same key must be reusable with different plaintexts. That's why OTP is not a cipher. There's nothing to prevent an encryption device or encryption method to change it's key automatically for each plaintext; yet if such method is used in a cipher, that method's key is an internal state of the cipher, initially set to the key of the cipher. And the cipher is broken if it can't safely be used for different plaintexts with the same key. $\endgroup$
    – fgrieu
    Aug 10, 2021 at 20:32
2
$\begingroup$

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.

$\endgroup$
3
  • $\begingroup$ But one-time pad is not so practical. $\endgroup$
    – Crypt01
    Aug 11, 2021 at 3:44
  • 1
    $\begingroup$ @ThePrince: OTP definitely has its uses; it has powerful security guarantees and requires very little computation to encrypt/decrypt. If you've got two endpoints that have a bit of storage space, OTP can be a useful tool. Of course, it's not right for everything, but usually we select crypto-methods on a case-by-case basis. $\endgroup$
    – Nat
    Aug 11, 2021 at 4:16
  • $\begingroup$ Thank you very much. $\endgroup$
    – Crypt01
    Aug 11, 2021 at 4:34
1
$\begingroup$

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

$\endgroup$
1
$\begingroup$

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:-

qkdn

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.

$\endgroup$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.