1. No category

SE 4472a
Information Security
Week 3:
Symmetric Key Encryption
Block Ciphers, Modes of Operation, AES
Fall 2014
Prof. Aleksander Essex
The Ideal Block Cipher
Block Ciphers
•  Classical ciphers encrypted individual letters
•  It’s the computer age so let’s operate on strings of
bits
•  We’ll break up long strings of bits in to (fixedlength) blocks, and encrypt each block separately
Block Ciphers
•  A block cipher is a triple of functions
< Gen, Enc, Dec >
•  For a security parameter k, and block length b:
Gen : k ! {0, 1}k
Enc : {0, 1}b ⇥ {0, 1}k ! {0, 1}b
Dec : {0, 1}b ⇥ {0, 1}k ! {0, 1}b
Ideal Block Ciphers
What properties should an ideal block cipher have
1.  Encryption should be reversible
•  Decryption should always return the original message
•  Encryption should be a bijection (one-to-one mapping)
•  Set of strings maps objectively to itself (permutation)
2.  Encryption/decryption should be easy with the key,
hard otherwise
•  What if the key defines a random permutation drawn from the set of
possible permutations
3.  Computing the mapping (i.e., encrypting/decrypting)
should be efficient to compute
Ideal Block Ciphers
Enc
Dec
{0, 1}b {0, 1}b
{0, 1}b {0, 1}b
k1
k1
Decryption is the inverse of Encryption
Ideal Block Ciphers
{0, 1}b {0, 1}b
{0, 1}b {0, 1}b
k1
k2
{0, 1}b {0, 1}b
Not a permutation
(we don’t want this—and why not?)
•  There are b! possible permutations
•  There are 2^k possible keys
•  Key defines “chooses” permutation
Ideal Block Ciphers
{0, 1}b {0, 1}b
k1
Essentially a block cipher
acts is like a giant electronic
codebook
Ideal Block Ciphers
Basically what we want is something called a pseudorandom permutation (PRP)
•  The key defines the permutation
•  The permutation is random-looking
•  It’s efficient to compute
•  How can we build a PRP?
•  Could make a giant look-up table
o  Not efficient to compute: contains 2^k entries
Ideal Block Ciphers
{0, 1}b {0, 1}b
{0, 1}b {0, 1}b
k1
k2
Pseudo-random function (PRF)
•  Like a PRP:
•  Pseudo-random mapping defined by key
•  Must be efficiently computable •  Unlike a PRP:
•  Doesn’t require it to be one-to-one
•  Easier to construct (doesn’t have to be invertible)
The Feistel Network
The Feistel Network
•  Or, how to turn a PRF into a strong PRP in 4 easy
steps!
•  Proof due to Luby/Rackoff
•  Originally proposed by Horst Feistel as part of Data
Encryption Standard (DES) in the 70s
•  The first modern cipher
The Feistel Network (Encryption)
a
b
k
PRF
a’
a’
…
…
The Feistel Network
•  Simple “twisted ladder” structure
•  Encryption accomplished by iterating several rounds
•  How many rounds is enough?
•  4 rounds enough to convert a strong PRF into
strong PRP
•  Wait: if the PRF doesn’t necessarily have an inverse and a PRP does,
how can “undo” the Fiestel network to get back to the message? •  Wouldn’t you need to be able to invert the PRF?
•  Actually no due cleverness of the design
•  Check it out…
The Feistel Network (Decryption)
a
b
k
Decryption works
by running network
backwards
PRF
Notice PRF still
runs “forwards”
Exercise. Convince yourself
running the network
backwards like this really
does recover the message
a’
a’
…
…
The Feistel Network
•  DES is insecure today, do not use it
•  Not fault with Feistel network
•  Weak key length (56-bits)
•  Issues in the PRF
•  Many modern block ciphers still use the Feistel network
•  3-DES, CAST, Blowfish/Twofish, etc
•  Other popular ciphers like AES use other constructions
•  Point is: we can efficiently compute a PRP (i.e., our
“electronic code book”) even if it has exponentially many
elements
The “Electronic Code Book”
Electronic Codebook
•  Ok, we have the foundations to create a block
cipher
•  We can take b bits of message and encrypt them to
b bits of ciphertext
•  b=128 is a common modern block length •  Question:
•  How do we encrypt message longer than 128 bits?
Electronic Codebook
•  Example: AES-256-ECB •  Key derived from OpenSSL using password (and random salt appended to file)
CIPHERTEXT
PLAINTEXT
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 !
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01!
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02!
67 8E EE 31 4C FC 24 2E F7 62 9E 39 D3 08 A1 4E
51 03 35 71 62 68 87 E3 CB 16 86 BD EF C6 13 C3 !
3B 1D F9 59 A8 31 C6 70 AF A8 F2 4A B9 B8 27 4B!
…!
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD!
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FE!
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF!
…!
F1 34 B9 FD 4B 01 43 33 C7 20 C2 17 29 A5 CB 11 !
D1 2E 8D B2 4F F4 F3 77 E8 9F 92 31 A3 38 48 B0 !
B0 5B 46 3E 58 2A AE FC 5A 40 58 E9 B4 5F 34 B3!
•  One block contains 16 bytes
•  Each byte can be one of 256 possibilities
•  Codebook contains 256^16 = 2^128 elements
Electronic Codebook
•  Observation. According to our codebook:
!
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF !
will always encrypt to
!B0 5B 46 3E 58 2A AE FC 5A 40 58 E9 B4 5F 34 B3!
•  Ok, so what if message has a long run of such
bytes? • 
Would that ever happen in a real world setting?
Electronic Codebook
•  Example: Encrypting a .bmp •  0xFFFFFF means “white”
Slide1.bmp
hexdump
Electronic Codebook
•  Encrypt .bmp file
•  AES-256-ECB using OpenSSL
Electronic Codebook
•  Recall!
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF !
will always encrypt to
!B0 5B 46 3E 58 2A AE FC 5A 40 58 E9 B4 5F 34 B3!
!
•  Taking bmp encoding into acocunt:
•  A block of 4 white pixels will encrypt to a block of 4 pixels of random
colour
•  Taking ECB into account:
•  Every block of 4 white pixels will encrypt to the same 4 random
colour pixels
Electronic Codebook
•  Result!
Electronic Codebook
So we encrypted an image with AES-256-ECB. Behold the result:
Electronic Codebook
Thinking about our last
lecture, what security
level would you ascribe
to this?
Electronic Codebook
Final thought. How can we
use a block cipher to encrypt a
large message (e.g., a bmp) so
that the result looks like random
noise?