Cryptography and

Network Security
Chapter 5
Fifth Edition
by William Stallings
Chapter 5 –Advanced Encryption
Standard

"It seems very simple."

"It is very simple. But if you don't know what
the key is it's virtually indecipherable."
—Talking to Strange Men, Ruth Rendell
 AES Origins
 clear a replacement for DES was needed

have theoretical attacks that can break it

have demonstrated exhaustive key search attacks
 can use Triple-DES – but slow, has small blocks
 US NIST issued call for ciphers in 1997
 15 candidates accepted in Jun 98
 5 were shortlisted in Aug-99
 Rijndael was selected as the AES in Oct-2000
 issued as FIPS PUB 197 standard in Nov-2001
 AES Requirements
 Private key symmetric block cipher
 128-bit data, 128/192/256-bit keys
 Stronger & faster than Triple-DES
 Active life of 20-30 years (+ archival use)
 Provide full specification & design details
 NIST have released all submissions &
unclassified analyses
 Evaluation Criteria
 Initial criteria:

security – effort for practical cryptanalysis

cost – in terms of computational efficiency

algorithm & implementation characteristics
 Final criteria

general security

ease of software & hardware implementation

implementation attacks

flexibility (in en/decrypt, keying, other factors)
SECURITY

•Actual security: compared to other submitted

algorithms (at the same key and block size).

•Randomness: the extent to which the algorithm

output is indistinguishable from a random permutation
on the input block.

•Soundness: of the mathematical basis for the

algorithm's security.

•Other security factors: raised by the public during

the evaluation process, including any attacks which
demonstrate that the actual security of the algorithm is
less than the strength claimed by the submitter.
COST

•Licensing requirements: NIST intends that when the AES

is issued, the algorithm(s) specified in the AES shall be
available on a worldwide, non-exclusive, royalty-free basis.

•Computational efficiency: The evaluation of computational

efficiency will be applicable to both hardware and software
implementations. Round 1 analysis by NIST will focus
primarily on software implementations and specifically on
one key-block size combination (128-128); more attention
will be paid to hardware implementations and other
supported key-block size combinations during Round 2
analysis.
Computational efficiency essentially refers to the speed of the
algorithm. Public comments on each algorithm's efficiency
(particularly for various platforms and applications) will also
be taken into consideration by NIST.
COST

•Memory requirements: The memory required to implement

a candidate algorithm—for both hardware and software
implementations of the algorithm--will also be considered
during the evaluation process.

Round 1 analysis by NIST will focus primarily on software

implementations; more attention will be paid to hardware
implementations during Round 2.
Memory requirements will include such factors as gate
counts for hardware implementations, and code size and
RAM requirements for software implementations.
ALGORITHM AND IMPLEMENTATION CHARACTERISTICS

•Flexibility: Candidate algorithms with greater flexibility will meet

the needs of more users than less flexible ones, and therefore,
inter alia, are preferable. However, some extremes of functionality
are of little practical application (e.g., extremely short key lengths);
for those cases, preference will not be given. Some examples of
flexibility may include (but are not limited to) the following:
a. The algorithm can accommodate additional key- and block-
sizes (e.g., 64-bit block sizes, key sizes other than those
specified in the Minimum Acceptability Requirements section,
[e.g., keys between 128 and 256 that are multiples of 32 bits,
etc.])
b. The algorithm can be implemented securely and efficiently in
a wide variety of platforms and applications (e.g., 8-bit
processors, ATM networks, voice & satellite communications,
HDTV, B-ISDN, etc.).
c. The algorithm can be implemented as a stream cipher,
message authentication code (MAC) generator,
pseudorandom number generator, hashing algorithm, etc.
ALGORITHM AND IMPLEMENTATION CHARACTERISTICS

•Hardware and software suitability: A candidate algorithm shall

not be restrictive in the sense that it can only be implemented in
hardware. If one can also implement the algorithm efficiently in
firmware, then this will be an advantage in the area of flexibility.

•Simplicity: A candidate algorithm shall be judged according to

relative simplicity of design.
 AES Shortlist
 After testing and evaluation, shortlist in Aug-99:

MARS (IBM) - complex, fast, high security margin

RC6 (USA) - v. simple, v. fast, low security margin

Rijndael (Belgium) - clean, fast, good security margin

Serpent (Euro) - slow, clean, v. high security margin

Twofish (USA) - complex, v. fast, high security margin
 then subject to further analysis & comment
 Contrast between algorithms with

few complex rounds verses many simple rounds

which refined existing ciphers verses new proposals
 The AES Cipher - Rijndael
 designed by Rijmen-Daemen in Belgium
 has 128/192/256 bit keys, 128 bit data
 an iterative rather than Feistel cipher

processes data as block of 4 columns of 4 bytes

operates on entire data block in every round
 designed to have:

resistance against known attacks

speed and code compactness on many CPUs

design simplicity
 AES Parameters

Key Size ( word/byte/bits) 4/16/128 6/24/192 8/32/256

Plaintext Block Size ( word/byte/bits) 4/16/128 4/16/128 4/16/128

Number of Rounds 10 12 14
Round Key Size ( word/byte/bits) 4/16/128 4/16/128 4/16/128
Expanded Key Size ( word/byte) 44/176 52/208 60/240
 AES
Encryption
Process
 AES Structure
 data block of 4 columns of 4 bytes is state
 key is expanded to array of words
 has 9/11/13 rounds in which state undergoes:

byte substitution (1 S-box used on every byte)

shift rows (permute bytes between groups/columns)

mix columns (subs using matrix multiply of groups)

add round key (XOR state with key material)

view as alternating XOR key & scramble data bytes
 initial XOR key material & incomplete last round
 with fast XOR & table lookup implementation
AES Structure
 Some Comments on AES
1. an iterative rather than Feistel cipher
2. key expanded into array of 32-bit words
1. four words form round key in each round
3. 4 different stages are used as shown
4. has a simple structure
5. only AddRoundKey uses key
6. AddRoundKey a form of Vernam cipher
7. each stage is easily reversible
8. decryption uses keys in reverse order
9. decryption does recover plaintext
10. final round has only 3 stages
 Substitute Bytes
 a simple substitution of each byte
 uses one table of 16x16 bytes containing a
permutation of all 256 8-bit values
 each byte of state is replaced by byte indexed
by row (left 4-bits) & column (right 4-bits)

eg. byte {95} is replaced by byte in row 9 column 5

which has value {2A}
 S-box constructed using defined transformation
of values in GF(28)
 designed to be resistant to all known attacks
Substitute Bytes
Substitute Bytes Example
 Shift Rows
 a circular byte shift in each each

1st row is unchanged

2nd row does 1 byte circular shift to left

3rd row does 2 byte circular shift to left

4th row does 3 byte circular shift to left
 decrypt inverts using shifts to right
 since state is processed by columns, this step
permutes bytes between the columns
Shift Rows
 Mix Columns
 each column is processed separately
 each byte is replaced by a value
dependent on all 4 bytes in the column
 effectively a matrix multiplication in GF(28)
using prime poly m(x) =x8+x4+x3+x+1
Mix Columns
Mix Columns Example
 AES Arithmetic
 uses arithmetic in the finite field GF(28)
 with irreducible polynomial
m(x) = x8 + x4 + x3 + x + 1
which is (100011011) or {11b}
 e.g.
{02} • {87} mod {11b} = (1 0000 1110) mod {11b}
= (1 0000 1110) xor (1 0001 1011) = (0001 0101)
 Mix Columns
 can express each col as 4 equations

to derive each new byte in col
 decryption requires use of inverse matrix

with larger coefficients, hence a little harder
 have an alternate characterisation

each column a 4-term polynomial

with coefficients in GF(28)

and polynomials multiplied modulo (x4+1)
 coefficients based on linear code with
maximal distance between codewords
Mix Columns - Decryption
 Add Round Key
 XOR state with 128-bits of the round key
 again processed by column (though
effectively a series of byte operations)
 inverse for decryption identical

since XOR own inverse, with reversed keys
 designed to be as simple as possible

a form of Vernam cipher on expanded key

requires other stages for complexity / security
Add Round Key
AES Round
 AES Key Expansion
 takes 128-bit (16-byte) key and expands
into array of 44/52/60 32-bit words
 start by copying key into first 4 words
 then loop creating words that depend on
values in previous & 4 places back

in 3 of 4 cases just XOR these together

1st word in 4 has rotate + S-box + XOR round
constant on previous, before XOR 4th back
AES Key Expansion
 Key Expansion Rationale
 designed to resist known attacks
 design criteria included

knowing part key insufficient to find many more

invertible transformation

fast on wide range of CPU’s

use round constants to break symmetry

diffuse key bits into round keys

enough non-linearity to hinder analysis

simplicity of description
 AES
Example
Key
Expansion
 AES
Example
Encryption
 AES
Example
Avalanche
 AES Decryption
 AES decryption is not identical to
encryption since steps done in reverse
 but can define an equivalent inverse
cipher with steps as for encryption

but using inverses of each step

with a different key schedule
 works since result is unchanged when

swap byte substitution & shift rows

swap mix columns & add (tweaked) round key
AES Decryption
 Implementation Aspects
 can efficiently implement on 8-bit CPU

byte substitution works on bytes using a table
of 256 entries

shift rows is simple byte shift

add round key works on byte XOR’s

mix columns requires matrix multiply in GF(28)
which works on byte values, can be simplified
to use table lookups & byte XOR’s
 Implementation Aspects
 can efficiently implement on 32-bit CPU

redefine steps to use 32-bit words

can precompute 4 tables of 256-words

then each column in each round can be
computed using 4 table lookups + 4 XORs

at a cost of 4Kb to store tables
 designers believe this very efficient
implementation was a key factor in its
selection as the AES cipher
General Security
Rijndael has no known security attacks. Rijndael uses S-boxes as nonlinear
components. Rijndael appears to have an adequate security margin, but
has received some criticism suggesting that its mathematical structure may
lead to attacks. On the other hand, the simple structure may have facilitated
its security analysis during the timeframe of the AES development process.

Software Implementations
Rijndael performs encryption and decryption very well across a variety of
platforms,
including 8-bit and 64-bit platforms, and DSPs. However, there is a
decrease in performance with the higher key sizes because of the increased
number of rounds that are performed. Rijndael’s high inherent parallelism
facilitates the efficient use of processor resources, resulting in very good
software performance even when implemented in a mode not capable of
interleaving. Rijndael’s key setup time is fast.
Restricted-Space Environments
In general, Rijndael is very well suited for restricted-space environments
where either
encryption or decryption is implemented (but not both). It has very low RAM
and ROM requirements. A drawback is that ROM requirements will increase
if both encryption and decryption are implemented simultaneously, although
it appears to remain suitable for these environments. The key schedule for
decryption is separate from encryption.

Hardware Implementations
Rijndael has the highest throughput of any of the finalists for feedback
modes and second highest for non-feedback modes. For the 192 and 256-
bit key sizes, throughput falls in standard and unrolled implementations
because of the additional number of rounds. For fully pipelined
implementations, the area requirement increases, but the throughput is
unaffected.
Attacks on Implementations
The operations used by Rijndael are among the easiest to defend against
power and timing attacks. The use of masking techniques to provide
Rijndael with some defense against these attacks does not cause significant
performance degradation relative to the other finalists, and its RAM
requirement remains reasonable. Rijndael appears to gain a major speed
advantage over its competitors when such protections are considered.

Encryption vs. Decryption

The encryption and decryption functions in Rijndael differ. One FPGA study
reports that the implementation of both encryption and decryption takes
about 60% more space than the implementation of encryption alone.
Rijndael’s speed does not vary significantly between encryption and
decryption, although the key setup performance is slower for decryption
than for encryption.
Key Agility
Rijndael supports on-the-fly subkey computation for encryption. Rijndael
requires a one-time execution of the key schedule to generate all subkeys
prior to the first decryption with a specific key. This places a slight resource
burden on the key agility of Rijndael.

Other Versatility and Flexibility

Rijndael fully supports block sizes and key sizes of 128 bits, 192 bits and
256 bits, in any combination. In principle, the Rijndael structure can
accommodate any block sizes and key sizes that are multiples of 32, as well
as changes in the number of rounds that are specified.

Potential for Instruction-Level Parallelism

Rijndael has an excellent potential for parallelism for a single block
encryption.
 Summary
 have considered:

the AES selection process

the details of Rijndael – the AES cipher

looked at the steps in each round

the key expansion

implementation aspects