9
The key schedule is a crucial component of a block cipher – and probably the least well under- 10
stood. A weakness in it can break down completely designs which are otherwise quite clever: 11
It can give rise to classes of weak keys (Section2.5 on page 107), i.e. keys for which the cipher is 12
easy to break, or make the cipher amenable to attacks specifically targeting relations between 13
keys (Section2.6 on page 108), MITM attacks and their variants (Section 2.4 on page 97), and 14
perhaps also zero correlation cryptanalysis (Subsubsection2.2.8.2 on page 95). At the same 15
time, there are strong ciphers with very simple key schedules. 16
In fact, Rijmen and Daemen already stated in the AES design book [DR02b, P. 77] that: “There
17
is no consensus on the criteria that a key schedule must satisfy.” 18
1.7.1 The Role of the Key Schedule
19
A key schedule can be used in various ways in a block cipher: 20
1. In a product cipher it can simply specify the subkeys that are mixed to the state at each round. 21
Classic examples are given by the DES (Section3.2 on page 129) and most SPNs, including 22
AES (Section3.20 on page 182). 23
2. It may be used to initialise some fixed elements of a cryptographic transform, such as sub- 24
stitution tables. This is done, for instance, in Blowfish (Section3.9 on page 157) and Twofish 25
(Section3.13 on page 164), as well as in the block ciphers C [BF06a] and KFC [BF06b], de- 26
signed by Thomas Baignères and Matthieu Finiasz and briefly described in Subsection1.10.3 27
on page 64. 28
3. Its output can be used to dynamically select functions from fixed families to be used in 29
certain places of the cipher. These families of functions can be S-boxes from a list, or variable 30
rotations. This was the approach used in some early ciphers such as Lucifer (Section3.1 on 31
page 128), the DES, CAST (Section3.7 on page 148), as well as in variants of C and KFC with 32
precomputed families of S-boxes. 33
The perhaps most extreme example is given by FROG (Subsection3.19.3 on page 180), that 34
essentially expands the key into a program describing the data obfuscation path. 35
At least in the first of these three cases, the key scheduleseems to have a subordinate role to 36
the data obfuscation path: if the latter presents weaknesses, the former cannot repair it. This 37
is what ultimately breaks DES with any key schedule,even with independent round keys[BS93]. 38
Also, the principle of confusion states that the key bits must be combined with the plaintext bits 39
in as complex way as possible. In an iterative block cipher with round key mixing between the 1
rounds, the use of diffusion and confusion to destroy any linear relation between plaintext and 2
ciphertext already partially contributes to the desired mixing of the key bits with the plaintext, 3
which intuitively should be “as good” as the non-linearity between plaintext and ciphertext. 4
But, it is not clear how complex the key schedule must be in order to achieve a sufficient dif- 5
fusion of the key bits in combination with the round functions. A first study of this is done 6
by Jialin Huang and Xuejia Lai in [HL12,HL14], where they propose a criterion to evaluate for 7
necessary key schedule diffusion that takes into account the round diffusion. 8
Even though a theoretically good data obfuscation path is necessary to achieve security (as 9
DES shows), it is not sufficient: for instance, a periodic key schedule of length𝑡 ⩾ 1reduces the 10
security of the full cipher to that of a𝑡rounds-reduced one,regardless of the actual length of the
11
cipherbecause of slide attacks (Subsection2.6.2 on page 110). On the other hand, slide attacks 12
require the ability to mount anefficientknown plaintext attack on the𝑡rounds-reduced version 13
of the cipher, which in turn means that if𝑡is a number large enough to make such an attack 14
sufficiently slow (even though, technically, the𝑡rounds-reduced version of the cipher may be 15
broken),thenusing that periodic key schedule may still be fine. 16
1.7.2 Construction of the Key Schedule
17
We have just mentioned that the simplest key schedule, i.e. the constant key schedule, is funda- 18
mentally weak in simple product ciphers, because it reduces the security of the cipher to that of 19
a single round. One possible opposite extreme of the spectrum is represented by independent 20
round keys, or the use of a complex key derivation function – a strong PRNG (pseudo-random 21
number generator) – to derive the keys from a seed. 22
Most proofs of security for block ciphers rely on strong assumptions about the independence 23
of the round keys, or more generally about the pseudo randomness of the output of the key 24
schedule process – an approach that is fruitful in cryptanalysis, as proved by the usefulness of 25
the theory of Markov ciphers (cf. Subsection2.1.2 on page 78). Using independent round keys 26
would make the effective key length very big, while mixing only parts of it in each round and 27
at the same time breaking the principle of confusion – rendering in fact the cipherlesssecure 28
with respect to the effective key length Also, the resulting cipher would be trivially susceptible 29
to a meet-in-the-middle attack (Section2.4 on page 97) with complexity exponential in half of 30
the effective key length. Hence, depending on the actual structure of the data obfuscation path 31
the actual security level could be even lower. 32
Therefore many designs put a strong emphasis on complex key schedules, some of which ap- 33
proach the complexity of pseudo-random number generators (PRNGs), seeded with a master 34
key that has a length matching the desired security level. The key schedules of KHAZAD (Sub- 35
section3.21.2 on page 190), RC5 (Section3.18 on page 159), RC6 (Section3.22 on page 169), and 36
Blowfish (Section3.9 on page 157), are such examples. Indeed, some block ciphers evendouse 37
a cryptographically strong PRNG as their key schedule, such as C and KFC. With a complex 38
key schedule, the hope is that confusion, as expressed in key avalanche (avalanche effect of the 39
key bits), can be achieved also with a relatively simple data obfuscation path. 40
On the other hand, the intuition expressed earlier, that combining a data obfuscation path 41
providing good confusion together with a simple key schedule (but still eschewing trivial key 42
schedule design mistakes), suggests that the key schedule construction issue itself may be over- 43
blown. A proof of this might be indeed represented by the later members of the SAFER family 1
(Section3.8 on page 150) and by IDEA (Section3.6 on page 144). 2
So there are two extremes, represented by trivial key schedules and very complex ones, where 3
the latter give a more solid foundation at the price of reduced key agility. And it is perhaps 4
because of this consideration that some design methodologies, such as the wide trail design 5
strategy, that favour the design of an “ideal” data obfuscation path, do not include key schedule 6
design techniques. 7
There are several ways to construct a key schedule. Some common strategies (with blurry mu- 8
tual boundaries) are: 9
1. Use a linear key schedule, combining bit permutations and extractions and other linear oper- 10
ations. This is done in Lucifer, DES, KeeloQ (Subsection3.3.3 on page 138) GOST (Section3.4 11
on page 140), IDEA, Skipjack (Section3.14 on page 166), and Bel-T (Section3.33 on page 214). 12
2. The same as the previous method, but also masking with fixed constants, such as in the 13
SAFER family (Section3.8 on page 150), SQUARE (Section3.11 on page 160), SIMON (Sec- 14
tion3.36 on page 222), and Piccolo (Subsection3.37.2 on page 228). 15
PRINCE (Section3.35 on page 217) is an extreme example because each round key is just the 16
master key XORed with a different round constant. 17
3. Sometimes, a non-linear component is added to the previous two processes, such as in the 18
AES, PRESENT (Section3.29 on page 206), and SPECK (Section3.36 on page 222). 19
4. Encrypt the master key using a block or stream cipher with fixed keys, and use the interme- 20
diate states of the block cipher or the output of the stream cipher as the subkeys. 21
The same algorithm as the data obfuscation path (possibly shortened) can be reused to gen- 22
erate some or all of the subkeys, as in Camellia (Section3.18 on page 172), or NOEKEON 23
(Subsection3.21.4 on page 193); or a different one, possibly reusing some of the components 24
of the the data obfuscation path, as in FEAL (Subsection3.3.4 on page 139), KHAZAD, RC5, 25
RC6, Twofish, ICEBERG (Section3.24 on page 197), SEA (Section3.26 on page 199), CLEFIA 26
(Section3.28 on page 203), and KLEIN (Subsection3.37.1 on page 226). 27
Two more extreme cases are Blowfish, that repeatedly uses the encryption routine to gener- 28
ate the key expansion, and SHARK (Subsection3.21.2 on page 190), whose key schedule is 29
based on cipher itself in CFB mode. (We note that in SHARK key mixing is done both by 30
simple XORs and more complex affine transforms.) 31
It has not been conclusively proved that key schedule plays a part in providing strength against 32
linear and differential cryptanalysis. Some experimental evidence is given in Knudsen and 33
Mathiassen in [KM04]: using a toy cipher, they observed that complex schedules can reach a 34
uniform distribution for the probabilities of differentials and linear hulls faster than those with 35
poorly designed key schedules. 36