An example to demonstrate the point with two Feistel networks:

Cipher A: \begin{align} roundkey = hash(key || counter)\\ roundkey = hash(key || roundkey)\\ left = left\oplus hash(roundkey || right)\\ ... swap\ and\ continue \end{align}

Cipher B: \begin{align} roundkey = hash(key || counter || right)\\ roundkey = hash(key || roundkey)\\ left = left\oplus hash(roundkey || right)\\ ...swap\ and\ continue \end{align}

In the above, Cipher A would produce identical round keys during every encryption/decryption, while the round keys in Cipher B would be different for each set of plaintext/ciphertext pairs.

Do key schedules which incorporate plaintext data to generate randomized round keys offer any particular benefits or complaints compared to key schedules which produce the same round key regardless of the data being operated upon?

I understand that incorporating plaintext data might potentially allow an adversary to influence the key schedule, but the extent of which that is a problem probably depends on the specifics of the algorithm in question. I'm more interested about the general case, if there's anything that can be said about it. I'm also interested in whether or not it could complicate statistical side channel attacks like differential power analysis.

Are there many examples of randomized data dependent key schedules? Or better, papers outlining attacks against them? My search mostly turned up "data dependent rotations".

  • $\begingroup$ In a sense, both of your examples use the same key schedule -- in both ciphers the entire key can be characterized as an input into every round. i.e. The round function is a function of the whole key, the right side of the data, and a round counter. Cipher B is just a slightly more complicated round function, that involves the right side input twice instead of once. $\endgroup$
    – J.D.
    May 12, 2016 at 1:43
  • $\begingroup$ @J.D. I agree with what you're saying, but wasn't really hoping to limit discussion based on the oversimplified example. Do you maybe have a better example that I/we might edit into the question to clarify the distinction? If it's clear enough what is being asked in the remainder of the body of the question, then the example could be removed entirely. $\endgroup$
    – Ella Rose
    May 12, 2016 at 2:03
  • $\begingroup$ It appears to me that a "data-dependent key schedule" for a Feistel network could still be summarized as $left := left \oplus F( right, key, roundindex )$, for some function F. If so, what is the fundamental difference between a "data-dependent key schedule" and a "data-independent one" (apart from the practical aspect that, with a data-independent one, an implementation may be able to do more of the key scheduling beforehand)? $\endgroup$
    – poncho
    May 12, 2016 at 3:26
  • $\begingroup$ @poncho Besides the fact that during each encryption run on different inputs the internal keys would be different, there is no difference. With a cipher like B the only key in common between E(M1) and E(M2) would be the initial master key. I would highlight the inability to do key scheduling beforehand as a complaint against the idea. Note I'm not suggesting this is necessarily a good idea, it's just a question I have as to how that one difference may or may not influence any attacks or the efficiency of the cipher. $\endgroup$
    – Ella Rose
    May 12, 2016 at 3:44
  • 1
    $\begingroup$ this question is very similar, though it addresses stream ciphers specifically. $\endgroup$
    – Ella Rose
    May 15, 2016 at 20:05

1 Answer 1


Data-independent key schedules allow the round subkeys to be computed once in advance. They can be reused for each subsequent block you encrypt. This potentially allows significant performance speedups.

Data-dependent key schedules don't have that property.

Otherwise, there is no fundamental difference.

Normally, the key schedule is defined or understood to be the part of the cipher that depends only on the key and can be computed in advance (doesn't depend on the data). So, "data-dependent key schedule" is somehow a contradiction in terms.


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.