Chapter 3: Symmetric Key Crypto

Chapter 3: Symmetric Key Crypto
The chief forms of beauty are order and symmetry…  Aristotle “You boil it in sawdust: you salt it in glue: You condense it with locusts and tape: Still keeping one principal object in view  To preserve its symmetrical shape.”  Lewis Carroll, The Hunting of the Snark Part 1  Cryptography

Symmetric Key Crypto Stream cipher  generalize One-Time Pad (OTP)
Except that key is relatively short Key is stretched into a long keystream Keystream is used just like a One-Time Pad Block cipher  generalized codebook Block cipher key determines a codebook Each key yields a different codebook Employs both “confusion” and “diffusion” Part 1  Cryptography

When & Where For applications that require encryption/decryption of a stream of data, such as over a data communications channel or a browser/Web link, a stream cipher might be the better alternative. For applications that deal with blocks of data, such as file transfer, , and database, block ciphers may be more appropriate. However, either type of cipher can be used in virtually any application.

Stream Ciphers Processes input elements continuously
Key input to a pseudorandom bit generator Produces stream of random like numbers Unpredictable without knowing input key XOR keystream bits output with plaintext bytes A block cipher processes the input one block of elements at a time, producing an output block for each input block. A stream cipher processes the input elements continuously, producing output one element at a time, as it goes along. Although block ciphers are far more common, there are certain applications in which a stream cipher is more appropriate. Examples are given subsequently in this book. In this section, we look at perhaps the most popular symmetric stream cipher, RC4. We begin with an overview of stream cipher structure and then examine RC4. A typical stream cipher encrypts plaintext 1 byte at a time, although a stream cipher may be designed to operate on 1 bit at a time or on units larger than a byte at a time. Figure 2.3b is a representative diagram of stream cipher structure. In this structure a key is input to a pseudorandom bit generator that produces a stream of 8-bit numbers that are apparently random. A pseudorandom stream is one that is unpredictable without knowledge of the input key and that has an apparently random character. The output of the generator, called a keystream, is combined 1 byte at a time with the plaintext stream using the bitwise exclusive-OR (XOR) operation.

Stream Ciphers Once upon a time, not so very long ago… stream ciphers were the king of crypto Today, not as popular as block ciphers We’ll discuss two Stream Cipher Algorithms: A5/1 Based on shift registers (LFSR) Used in GSM mobile phone system RC4 Based on a changing lookup table Used in many places (i.e. WEP, WPA) Part 1  Cryptography

A5/1: Shift Registers A5/1 uses 3 shift registers
X: 19 bits (x0, x1, x2, … , x18) Y: 22 bits (y0, y1, y2, … , y21) Z: 23 bits (z0, z1, z2, … , z22) Part 1  Cryptography

A5/1: Keystream At each iteration: m = maj(x8, y10, z10)
Examples: maj(0,1,0) = 0 and maj(1,1,0) = 1 If x8 = m then X steps (shifts as follows) t = x13  x16  x17  x18 #predefined set of bits in X xi = xi1 for i = 18, 17, … , 1 and then x0 = t If y10 = m then Y steps t = y20  y21 #predefined set of bits in Y yi = yi1 for i = 21, 20, … , 1 and then y0 = t If z10 = m then Z steps t = z7  z20  z21  z22 #predefined set of bits in Z zi = zi1 for i = 22, 21, … , 1 and then z0 = t Finally, Keystream bit is the result of: x18  y21  z22 Key Part 1  Cryptography

A5/1 Each variable here is a single bit
X x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17 x18 steps  Keystream bit Y y0 y1 y2 y3 y4 y5 y6 y7 y8 y9 y10 y11 y12 y13 y14 y15 y16 y17 y18 y19 y20 y21  steps  Z z0 z1 z2 z3 z4 z5 z6 z7 z8 z9 z10 z11 z12 z13 z14 z15 z16 z17 z18 z19 z20 z21 z22  steps Each variable here is a single bit Key is used as initial fill of registers Each register steps (or not) based on maj(x8, y10, z10) Keystream bit is the XOR of rightmost bits of registers Part 1  Cryptography

A5/1 In this example, m = maj(x8, y10, z10) = maj(1,0,1) = 1
steps  y10 y21 Y  1 steps  z10 z22 Z 1  steps In this example, m = maj(x8, y10, z10) = maj(1,0,1) = 1 Register X steps, Y does not step, and Z steps Keystream bit is XOR of right bits of registers S = x18  y21  z22 Here, the new keystream bit will be the result of: 0  1  0 = 1 Part 1  Cryptography

Shift Register Crypto Shift register crypto efficient in hardware
Often, slow if implemented in software In the past, very, very popular Today, more is done in software due to fast processors Shift register crypto still used in some applications Especially in resource-constrained devices Part 1  Cryptography

RC4 RC4 is a stream cipher (by Ron Rivest for RSA Security)
It is a variable-key-size stream cipher with byte-oriented operations; based on the use of a random permutation It is used in the SSL/TLS (Secure Sockets Layer/Transport Layer Security) standards It is also used in the WEP (Wired Equivalent Privacy) protocol and the newer WiFi Protected Access (WPA) protocol that are part of the IEEE wireless LAN standard The RC4 algorithm: A variable length key: from 1 to 256 bytes (8 to 2048 bits) is used to initialize a 256-byte state vector S, with elements S[0], S[1], , S[255] At all times, S contains a permutation of all 8-bit numbers from 0 through 255 For encryption and decryption, a byte k is generated from S by selecting one of the 255 entries in a systematic fashion As each value of k is generated, the entries in S are once again permuted Part 1  Cryptography

RC4 A self-modifying lookup table
Table always contains a permutation of the byte values 0,1,…, 255 Initialize the permutation using Key At each step, RC4 does the following Swaps elements in current lookup table Selects a keystream byte from table Each step of RC4 produces a byte Efficient in software Each step of A5/1 produces only a bit Efficient in hardware Part 1  Cryptography

RC4 Initialization S[] is permutation of 0, 1, ... , 255
K[] contains N bytes of key # Initialization for i = 0 to 255 S[i] = i T[i] = K [i mod N] #N is the key length next i # Initial Permutation of S j = 0 j = (j + S[i] + T[i]) mod 256 swap(S[i], S[j]) i = j = 0 # Initialization for i = 0 to 255 S[i] = i T[i] = K [i mod N] #N is the key length next i # Initial Permutation of S j = 0 for i = 0 to 255 j = (j + S[i] + T[i]) mod 256 swap(S[i], S[j]) next i i = j = 0 Part 1  Cryptography

RC4 Keystream At each step, swap elements in table and select keystream byte i = (i + 1) mod 256 j = (j + S[i]) mod 256 swap(S[i], S[j]) t = (S[i] + S[j]) mod 256 keystreamByte = S[t] Use keystream bytes like a One-Time Pad To encrypt, XOR the value keystreamByte with the next byte of plaintext. To decrypt, XOR the value keystreamByte with the next byte of ciphertext. Note: first 256 bytes should be discarded Otherwise, related key attack exists /* Stream Generation */ i, j = 0 while (True) i = (i + 1) mod 256 j = (j + S[i]) mod 256 Swap (S[i], S[j]) t = (S[i] + S[j]) mod 256 keystreamByte = S[t] Part 1  Cryptography

Byte S[256] is permutation of 0,1,...,255
Byte K[N] contains N bytes of key Figure 20.6 illustrates the RC4 logic. RC4 is a stream cipher designed in 1987 by Ron Rivest for RSA Security. It is a variable key-size stream cipher with byte-oriented operations. The algorithm is based on the use of a random permutation. Analysis shows that the period of the cipher is overwhelmingly likely to be greater than [ROBS95]. Eight to sixteen machine operations are required per output byte, and the cipher can be expected to run very quickly in software. RC4 is used in the SSL/TLS (Secure Sockets Layer/Transport Layer Security) standards that have been defined for communication between Web browsers and servers. It is also used in the WEP (Wired Equivalent Privacy) protocol and the newer WiFi Protected Access (WPA) protocol that are part of the IEEE wireless LAN standard. RC4 was kept as a trade secret by RSA Security. In September 1994, the RC4 algorithm was anonymously posted on the Internet on the Cypherpunks anonymous r ers list. The RC4 algorithm is remarkably simply and quite easy to explain. A variable-length key of from 1 to 256 bytes (8 to 2048 bits) is used to initialize a 256-byte state vector S, with elements S[0], S[1], …, S[255]. At all times, S contains a permutation of all 8-bit numbers from 0 through 255. For encryption and decryption, a byte k (see Figure 2.3b) is generated from S by selecting one of the 255 entries in a systematic fashion. As each value of k is generated, the entries in S are once again permuted. To begin, the entries of S are set equal to the values from 0 through 255 in ascending order; that is, S [0] = 0, S [1] = 1, , S [255] = 255. A temporary vector, T, is also created. If the length of the key K is 256 bytes, then K is transferred to T. Otherwise, for a key of length keylen bytes, the first keylen elements of T are copied from K and then K is repeated as many times as necessary to fill out T. These preliminary operations can be summarized as follows: /* Initialization */ for i = 0 to 255 do S[i] =i; T[i] = K[i mod keylen]; Next we use T to produce the initial permutation of S. This involves starting with S[0] and going through to S[255], and, for each S [i], swapping S [i] with another byte in S according to a scheme dictated by T[i]: /* Initial Permutation of S */ j = 0; j = (j + S[i] + T[i]) mod 256; Swap (S[i], S[j]); Because the only operation on S is a swap, the only effect is a permutation. S still contains all the numbers from 0 through 255. Once the S vector is initialized, the input key is no longer used. Stream generation involves cycling through all the elements of S [i], and, for each S [i], swapping S [i] with another byte in S according to a scheme dictated by the current configuration of S. After S[255] is reached, the process continues, starting over again at S[0]: /* Stream Generation */ i, j = 0; while (true) i = (i + 1) mod 256; j = (j + S[i]) mod 256; t = (S[i] + S[j]) mod 256; k = S[t]; To encrypt, XOR the value k with the next byte of plaintext. To decrypt, XOR the value k with the next byte of ciphertext. Figure 20.5 illustrates the RC4 logic.

RC4 is a stream cipher designed in 1987 by Ron Rivest for RSA Security
RC4 is a stream cipher designed in 1987 by Ron Rivest for RSA Security. It is a variable key-size stream cipher with byte-oriented operations. The algorithm is based on the use of a random permutation. Analysis shows that the period of the cipher is overwhelmingly likely to be greater than [ROBS95]. Eight to sixteen machine operations are required per output byte, and the cipher can be expected to run very quickly in software. RC4 is used in the SSL/TLS (Secure Sockets Layer/Transport Layer Security) standards that have been defined for communication between Web browsers and servers. It is also used in the WEP (Wired Equivalent Privacy) protocol and the newer WiFi Protected Access (WPA) protocol that are part of the IEEE wireless LAN standard. RC4 was kept as a trade secret by RSA Security. In September 1994, the RC4 algorithm was anonymously posted on the Internet on the Cypherpunks anonymous r ers list. The RC4 algorithm is remarkably simply and quite easy to explain. A variable-length key of from 1 to 256 bytes (8 to 2048 bits) is used to initialize a 256-byte state vector S, with elements S[0], S[1], …, S[255]. At all times, S contains a permutation of all 8-bit numbers from 0 through 255. For encryption and decryption, a byte k (see Figure 2.3b) is generated from S by selecting one of the 255 entries in a systematic fashion. As each value of k is generated, the entries in S are once again permuted. To begin, the entries of S are set equal to the values from 0 through 255 in ascending order; that is, S [0] = 0, S [1] = 1, , S [255] = 255. A temporary vector, T, is also created. If the length of the key K is 256 bytes, then K is transferred to T. Otherwise, for a key of length keylen bytes, the first keylen elements of T are copied from K and then K is repeated as many times as necessary to fill out T. These preliminary operations can be summarized as follows: /* Initialization */ for i = 0 to 255 do S[i] =i; T[i] = K[i mod keylen]; Next we use T to produce the initial permutation of S. This involves starting with S[0] and going through to S[255], and, for each S [i], swapping S [i] with another byte in S according to a scheme dictated by T[i]: /* Initial Permutation of S */ j = 0; j = (j + S[i] + T[i]) mod 256; Swap (S[i], S[j]); Because the only operation on S is a swap, the only effect is a permutation. S still contains all the numbers from 0 through 255. Once the S vector is initialized, the input key is no longer used. Stream generation involves cycling through all the elements of S [i], and, for each S [i], swapping S [i] with another byte in S according to a scheme dictated by the current configuration of S. After S[255] is reached, the process continues, starting over again at S[0]: /* Stream Generation */ i, j = 0; while (true) i = (i + 1) mod 256; j = (j + S[i]) mod 256; t = (S[i] + S[j]) mod 256; k = S[t]; To encrypt, XOR the value k with the next byte of plaintext. To decrypt, XOR the value k with the next byte of ciphertext. Figure 20.5 illustrates the RC4 logic.

Stream Ciphers: Summary
Stream ciphers were popular in the past Efficient in hardware Speed was needed to keep up with voice, etc. Today, processors are fast, so software-based crypto is usually more than fast enough Future of stream ciphers? Shamir declared “the death of stream ciphers” May be greatly exaggerated… Part 1  Cryptography

Block Ciphers Part 1  Cryptography

(Iterated) Block Cipher
The design goals for block ciphers are security and efficiency. Plaintext and ciphertext consist of fixed-sized blocks Ciphertext obtained from plaintext by iterating a round function Input to round function consists of: key and output of previous round Usually implemented in software Part 1  Cryptography

Feistel Cipher: Encryption
Feistel cipher is a type of symmetric structure used in block cipher General cipher design principle, not a specific cipher named after the German IBM cryptographer Horst Feistel In a Feistel cipher, Split plaintext block into left and right halves: P = (L0, R0) And for each round i = 1, 2, ..., n, compute Li = Ri1 Ri = Li1  F(Ri1, Ki) where F is round function and Ki is subkey for round i. The subkey is derived from the key K according to a specified key schedule algorithm ? Ciphertext: C = (Ln, Rn) Part 1  Cryptography

Feistel Cipher: Decryption
Start with ciphertext C = (Ln, Rn) For each round i = n, n1, …, 1, compute Ri1 = Li Li1 = Ri  F(Ri1, Ki) where F is the round function and Ki is subkey The final result of this decryption process is the Plaintext: P = (L0, R0) Decryption works for any function F But only secure for certain functions F Part 1  Cryptography

DES: Data Encryption Standard
DES (an example of a Feistel Cipher) developed in 1970’s Based on IBM’s Lucifer cipher Lucifer was the name given to several of the earliest civilian block ciphers, developed by Horst Feistel and his colleagues at IBM. Lucifer uses a combination of Transposition and Substitution crypting as a starting point in decoding ciphers. DES was a U.S. government standard Development of DES was controversial The U.S. National Security Agency (NSA) secretly involved Design process was secret Key length reduced from 128 to 56 bits Subtle changes to Lucifer algorithm Part 1  Cryptography

DES Numerology DES is a Feistel cipher with…
64 bit block length 56 bit key length 16 rounds 48 bits of key used in each round (subkey) Round function is simple (for block cipher) Security depends heavily on the “S-boxes” In DES, each S-box maps 6 bits to 4 bits, and DES employs eight distinct S-boxes. The S-boxes, taken together, map 48 bits to 32 bits. The same S-boxes are used at each round of DES and each S-box is implemented as a lookup table. Part 1  Cryptography

F(Ri-1, Ki) = P-box(S-boxes(Expand(Ri-1)  Ki))
One Round of DES L R expand shift key S-boxes compress 28 48 32 Ki P box  The round function F is the composition of the expansion permutation, addition (XORing) of subkey, S-boxes, and P-box F(Ri-1, Ki) = P-box(S-boxes(Expand(Ri-1)  Ki))

DES Example The expansion permutation expands its input from 32 to 48 bits, and the subkey is XORed with the result. The S-boxes then compress these 48 bits down to 32 bits before the result is passed through the P-box. The P-box output is XORed with the old left half to obtain the new right half. It's important to keep in mind and realize that the overall structure of DES is actually fairly simple. In fact, some of the DES operations are of no security benefit whatsoever, and if these were stripped away to reveal the essential security features, the algorithm becomes even simpler. Convention: bits are numbered from left to right, beginning with the index 0

DES: 1. Expansion Permutation
The expansion permutation expands its input from 32 to 48 bits, and the subkey is XORed with the result. Input 32 bits Output 48 bits Part 1  Cryptography

DES: 2. S-box The S-boxes then compress these 48 bits down to 32 bits before the result is passed through the P-box. each S-box can be viewed as an array of 4 rows and 16 columns, with one nibble (4-bit value) stored in each of the 64 positions Each row is a permutation of the hexadecimal digits 0,1,2,... ,E,F.

DES: 2. S-box DES has 8 different “substitution boxes” or S-boxes
Each S-box maps 6 bits to 4 bits Here is S-box number 1 input bits (0,5)  input bits (1,2,3,4) | 00 | 01 | 10 | 11 | 6 bits: b0b1b2b3b4b5 b0b6 b1b2b3b4 Part 1  Cryptography

DES: 3. P-box Input 32 bits Output 32 bits
The P-box output is XORed with the old left half to obtain the new right half. Input 32 bits Output 32 bits Part 1  Cryptography

DES Last Word (Almost) An initial permutation before round 1
Halves are swapped after last round A final permutation (inverse of initial perm) applied to (R16, L16) None of this serves any security purpose Part 1  Cryptography

Security of DES Security depends heavily on S-boxes (8 of them)
Everything else in DES is linear 35+ years of intense analysis has revealed no back door Attacks, essentially exhaustive key search 256 possible keys  ? Inescapable Conclusions Designers of DES knew what they were doing Designers of DES were way ahead of their time (at least w.r.t. certain cryptanalytic techniques) Part 1  Cryptography

Block Cipher Notation P = plaintext block C = ciphertext block
Encrypt P with key K to get ciphertext C C = E(P, K) Decrypt C with key K to get plaintext P P = D(C, K) Note: P = D( E(P,K),K ) and C = E( D(C,K),K ) But P  D( E(P, K1), K2 ) and C  E( D(C, K1), K2 ) when K1  K2 Part 1  Cryptography

DES vs. Double DES vs. 3DES K P C E DES Key Space: 256 K1 P X E
Double DES or 2DES K2 C Key Space: 256 X 256 K1 P X1 E Triple DES or 3DES K2 X2 K3 C Key Space: 256 X 256 X 256 K1 P X1 E Triple DES or 3DES, also K2 X2 D C Key Space: 256 X 256

Meet In The Middle (MITM) Attack
Double DES (2DES) is supposed to give 112-bit key length. E( E(P,K1), K2 ) and D( D(P,K1), K2 ) 256 * 256 = 2112,key space (possible keys) Instead, attackers may end up trying 257, how come? Thus, double encryption is not that significant in terms of added security, but why? K1 P X E Double DES: Encryption K2 C K2 C X D Double DES: Decryption K1 P

2DES Why not C = E( E(P,K), K ) instead?
Trick question  still just 56 bit key Why not C = E( E(P,K1), K2 ) instead? A (semi-practical) known plaintext attack (MITM) Pre-compute table of X1 = E(P, K1) for every possible key K1 (resulting table has 256 entries, storage?) Then for each possible K2 compute X2 = D(C,K2) until a match in table is found Find when X1 == X2 and use it to infer the keys When match is found, have E(P,K1) = D(C,K2) Result gives us keys: C = E( E(P,K1),K2) Part 1  Cryptography

Triple DES Today, 56-bit DES key is too small
Exhaustive key search is feasible 2DES is not secure enough (almost similar to Single DES) But DES is everywhere, so what to do? Triple DES or 3DES (112-bit key or 168-bit, large enough) C = E( D( E(P, K1), K2), K1) P = D( E( D(C, K1), K2), K1) Why Encrypt-Decrypt-Encrypt with 2 keys? Backward compatible: E( D( E(P,K), K), K) = E(P, K) and 112 is a lot of bits Part 1  Cryptography

AES: Advanced Encryption Standard
Replacement for DES AES competition (late 90’s) U.S. NSA openly involved Transparent selection process Many strong algorithms proposed Rijndael Algorithm ultimately selected (pronounced like “Rain Doll” or “Rhine Doll”) Iterated block cipher (like DES) Not a Feistel cipher (unlike DES) Part 1  Cryptography

AES: Executive Summary
Block size: 128 bits (others in Rijndael) Key length: 128, 192 or 256 bits independent of block size in Rijndael 10 to 14 rounds (depends on key length) Each round uses 4 functions (3 “layers”) ByteSub : nonlinear layer ShiftRow : linear mixing layer MixColumn : nonlinear layer AddRoundKey : key addition layer Part 1  Cryptography

AES: 1. ByteSub Treat 128 bit block as 4x4 byte array
The ByteSub operation is applied to each byte aij, that is bij = ByteSub(ajj). The result is the array of bij as illustrated below: ByteSub is AES’s equivalent to the DES “S-boxes” Can be viewed as nonlinear (but invertible) composition of two math operations; simply as a lookup table Part 1  Cryptography

AES: 1. ByteSub ByteSub(3c) = eb since eb appears in row 3 and column c Last 4 bits of input First 4 bits of input Part 1  Cryptography

AES: 2. ShiftRow Cyclic shift rows
The ShiftRow operation is a cyclic shift of the bytes in each row of the 4 x 4 byte array. This operation is given by first row doesn't shift, second row circular left-shifts by one byte, third row left-shifts by two bytes, and last row left-shifts three bytes. Note: ShiftRow is inverted, simply shifting in the opposite direction. Part 1  Cryptography

AES: 3. MixColumn Invertible, linear operation applied to each column
the MixColumn operation is applied to each column of the 4 x 4 byte array MixColumn consists of shift and XOR operations, and it's most efficiently implemented as a (big) lookup table. The overall operation is nonlinear but invertible, and, as with ByteSub, it serves a similar purpose as the DES S-boxes Part 1  Cryptography

AES: 4. AddRoundKey XOR subkey with block
RoundKey (subkey) determined by key schedule algorithm Key schedule algorithm is used to generate a subkey for each round. Let kij be the 4 x 4 subkey array for a particular round. Then the subkey is XORed with the current 4 x 4 byte array aij. Part 1  Cryptography

AES: Decryption To decrypt, process must be invertible
Inverse of MixAddRoundKey is easy, since “” is its own inverse MixColumn is invertible (inverse is also implemented as a lookup table) Inverse of ShiftRow is easy (cyclic shift the other direction) ByteSub is invertible (inverse is also implemented as a lookup table) Part 1  Cryptography

AES Summary AES has both excellent confusion and diffusion
Look-up tables: non-linear, good at destroying patterns (confusion) Diffusion stage spreads every part of the input to the output: changing one bit of input changes half the output bits on average The MixColumns operation along with the ShiftRows step, is the primary source of diffusion Both confusion and diffusion are repeated multiple times for each input to increase the amount of scrambling The secret key is mixed at every stage so that an attacker cannot pre-calculate what the cipher does. None of this would happen if you used a simple one-stage scramble based on a key.

A Few Other Block Ciphers
Briefly… IDEA Blowfish RC6 More detailed… TEA Part 1  Cryptography

Block Cipher Modes Using a stream cipher is easy—you generate a keystream that is the same length as the plaintext (or ciphertext) and XOR. Using a block cipher is also easy, provided that you have exactly one block to encrypt. But how should multiple blocks be encrypted with a block cipher? It turns out that the answer is not as straightforward as it might seem. Part 1  Cryptography

Multiple Blocks How to encrypt multiple blocks?
Do we need a new key for each block? If so, as impractical as a One-Time Pad! Encrypt each block independently? Is there any analog of codebook “additive”? What about partial blocks, how to handle them? What about Padding or CFC Part 1  Cryptography

Block Cipher: Modes of Operation
Many modes  we discuss 3 most popular Electronic Codebook (ECB) mode Encrypt each block independently Most obvious approach, but a bad idea Cipher Block Chaining (CBC) mode Chain the blocks together More secure than ECB, virtually no extra work Counter Mode (CTR) mode Block ciphers acts like a stream cipher Popular for random access Part 1  Cryptography

ECB: Electronic Codebook Mode
Notation: C = E(P, K) Given plaintext P0, P1, …, Pm, … Most obvious way to use a ECB block cipher: Encrypt Decrypt C0 = E(P0, K) P0 = D(C0, K) C1 = E(P1, K) P1 = D(C1, K) C2 = E(P2, K) … P2 = D(C2, K) … For fixed key K, this is “electronic” version of a codebook cipher (without additive) With a different codebook for each key This approach works, but there are serious security issues with ECB mode and, as a result, it should never be used in practice. Suppose ECB mode is used, and an attacker observes that Ci = Cj. Then the attacker knows that Pi = Pj. Although this may seem innocent enough, there are cases where the attacker will know part of the plaintext, and any match with a known block reveals another block. But even if the attacker does not know Pi or Pj, some information has been revealed, namely, that these two plaintext blocks are the same, and we don't want to give the cryptanalyst anything for free—especially if there is an easy way to avoid it. Part 1  Cryptography

ECB: Electronic Codebook
the same key is used for all blocks Figure 2.2a shows the ECB mode. A plaintext of length nb is divided into n b-bit blocks (P1, P2,….,Pn). Each block is encrypted using the same algorithm and the same encryption key, to produce a sequence of n b-bit blocks of ciphertext (C1, C2,….,Cn). For lengthy messages, the ECB mode may not be secure. A cryptanalyst may be able to exploit regularities in the plaintext to ease the task of decryption. For example, if it is known that the message always starts out with certain predefined fields, then the cryptanalyst may have a number of known plaintext-ciphertext pairs with which to work. To increase the security of symmetric block encryption for large sequences of data, a number of alternative techniques have been developed, called modes of operation . These modes overcome the weaknesses of ECB; each mode has its own particular advantages. In a stream cipher structure, the key is input to a pseudorandom bit generator that produces a stream of 8-bit numbers that are apparently random. A pseudorandom stream is one that is unpredictable without knowledge of the input key and which has an apparently random character (see Section 2.5). The output of the generator, called a keystream, is combined one byte at a time with the plaintext stream using the bitwise exclusive- OR (XOR) operation.

ECB: Electronic Codebook
Simplest mode Plaintext is handled b-bit (block) at a time and each block is encrypted using the same key “Codebook” is used because there is an unique ciphertext for every b-bit block of plaintext Not secure for long messages since repeated plaintext is seen in repeated ciphertext this is a serious security issues and it should never be used in practice. To overcome security deficiencies: you need a technique where the same plaintext block, if repeated, produces different ciphertext blocks ?? The simplest way to proceed is what is known as electronic codebook (ECB) mode, in which plaintext is handled b bits at a time and each block of plaintext is encrypted using the same key ( Figure 2.3a ). The term codebook is used because, for a given key, there is a unique ciphertext for every b -bit block of plaintext. Therefore, one can imagine a gigantic codebook in which there is an entry for every possible b -bit plaintext pattern showing its corresponding ciphertext. With ECB, if the same b -bit block of plaintext appears more than once in the message, it always produces the same ciphertext. Because of this, for lengthy messages, the ECB mode may not be secure. If the message is highly structured, it may be possible for a cryptanalyst to exploit these regularities. For example, if it is known that the message always starts out with certain predefined fields, then the cryptanalyst may have a number of known plaintext-ciphertext pairs to work with. If the message has repetitive elements, with a period of repetition a multiple of b bits, then these elements can be identified by the analyst. This may help in the analysis or may provide an opportunity for substituting or rearranging blocks. To overcome the security deficiencies of ECB, we would like a technique in which the same plaintext block, if repeated, produces different ciphertext blocks.

ECB Weakness Suppose Pi = Pj
Then Ci = Cj and then Trudy will know that Pi = Pj This gives Trudy some information, even if she does not know Pi or Pj Trudy might know Pi. Then now she knows Pj Is this a serious issue? And when it will become one? Part 1  Cryptography

ECB: Cut-and-Paste Attack
Suppose plaintext is Alice digs Bob. Trudy digs Tom. Assuming 64-bit blocks and 8-bit ASCII: P0 = “Alice di”, P1 = “gs Bob. ”, P2 = “Trudy di”, P3 = “gs Tom. ” Ciphertext: C0, C1, C2, C3 Trudy cuts and pastes: C0, C3, C2, C1 Decrypts as Alice digs Tom. Trudy digs Bob. Part 1  Cryptography

Alice Hates ECB Mode Alice’s uncompressed image, and ECB encrypted
Why does this happen? Same plaintext yields same ciphertext! Part 1  Cryptography

CBC: Cipher Block Chaining Mode
Blocks are “chained” together A random Initialization Vector (IV) is required to start with the CBC mode IV is random, but not secret Encryption Decryption C0 = E(IV  P0, K), P0 = IV  D(C0, K), C1 = E(C0  P1, K), P1 = C0  D(C1, K), C2 = E(C1  P2, K),… P2 = C1  D(C2, K),… Analogous to classic codebook with additive Part 1  Cryptography

In the cipher block chaining (CBC) mode (Figure 20
In the cipher block chaining (CBC) mode (Figure 20.7), the input to the encryption algorithm is the XOR of the current plaintext block and the preceding ciphertext block; the same key is used for each block. In effect, we have chained together the processing of the sequence of plaintext blocks. The input to the encryption function for each plaintext block bears no fixed relationship to the plaintext block. Therefore, repeating patterns of b bits are not exposed. For decryption, each cipher block is passed through the decryption algorithm. The result is XORed with the preceding ciphertext block to produce the plaintext block. To see that this works, we can write: Cj = E(K, [Cj–1  Pj]) where E[K, X] is the encryption of plaintext X using key K, and  is the exclusive-OR operation. To produce the first block of ciphertext, an initialization vector (IV) is XORed with the first block of plaintext. On decryption, the IV is XORed with the output of the decryption algorithm to recover the first block of plaintext. The IV must be known to both the sender and receiver. For maximum security, the IV should be protected as well as the key. This could be done by sending the IV using ECB encryption. One reason for protecting the IV is as follows: If an opponent is able to fool the receiver into using a different value for IV, then the opponent is able to invert selected bits in the first block of plaintext.

CBC: Cipher Block Chaining Mode
Pros: Using the CBC, identical plaintext blocks yield different ciphertext blocks  this is very good! But what about errors in transmission (error propagation)? Suppose the ciphertext block Ci is garbled to, say, G  Ci . Then Pi  D(G, K) Ci-1 and Pi+1  D(Ci+1, K) G But Pi+2 = D(Ci+2,K)  Ci+1, … However, all subsequent blocks are decrypted correctly. That is, each plaintext block only depends on two consecutive ciphertext blocks, so errors do not propagate beyond two blocks. But, the fact that a single-bit error can cause two entire blocks to be garbled is a serious concern in high error-rate environments such as wireless. Stream ciphers do not have this problem—a single garbled ciphertext bit results in a single garbled plaintext bit—and that is one reason why stream ciphers are often preferred in wireless applications Garbled: a 0 bit could become 1 or vice versa Part 1  Cryptography

Alice Likes CBC Mode Alice’s uncompressed image, Alice CBC encrypted
Why does this happen? Same plaintext yields different ciphertext! Part 1  Cryptography

CTR: Counter Mode CTR is popular for random access
Use block cipher like a stream cipher Encryption Decryption C0 = P0  E(IV, K), P0 = C0  E(IV, K), C1 = P1  E(IV+1, K), P1 = C1  E(IV+1, K), C2 = P2  E(IV+2, K),… P2 = C2  E(IV+2, K),… Part 1  Cryptography

Although interest in the counter mode (CTR) has increased recently, with applications
to ATM (asynchronous transfer mode) network security and IPSec (IP security), this mode was proposed early on (e.g., [DIFF79]). Figure 20.9 depicts the CTR mode. A counter, equal to the plaintext block size is used. The only requirement stated in SP A is that the counter value must be different for each plaintext block that is encrypted. Typically, the counter is initialized to some value and then incremented by 1 for each subsequent block (modulo 2b, where b is the block size). For encryption, the counter is encrypted and then XORed with the plaintext block to produce the ciphertext block; there is no chaining. For decryption, the same sequence of counter values is used, with each encrypted counter XORed with a ciphertext block to recover the corresponding plaintext block. [LIPM00] lists the following advantages of CTR mode: • Hardware efficiency: Unlike the three chaining modes, encryption (or decryption) in CTR mode can be done in parallel on multiple blocks of plaintext or ciphertext. For the chaining modes, the algorithm must complete the computation on one block before beginning on the next block. This limits the maximum throughput of the algorithm to the reciprocal of the time for one execution of block encryption or decryption. In CTR mode, the throughput is only limited by the amount of parallelism that is achieved. • Software efficiency: Similarly, because of the opportunities for parallel execution in CTR mode, processors that support parallel features, such as aggressive pipelining, multiple instruction dispatch per clock cycle, a large number of registers, and SIMD instructions, can be effectively utilized. • Preprocessing: The execution of the underlying encryption algorithm does not depend on input of the plaintext or ciphertext. Therefore, if sufficient memory is available and security is maintained, preprocessing can be used to prepare the output of the encryption boxes that feed into the XOR functions in Figure When the plaintext or ciphertext input is presented, then the only computation is a series of XORs. Such a strategy greatly enhances throughput. • Random access: The i th block of plaintext or ciphertext can be processed in random access fashion. With the chaining modes, block Ci cannot be computed until the i - 1 prior block are computed. There may be applications in which a ciphertext is stored and it is desired to decrypt just one block; for such applications, the random access feature is attractive. • Provable security: It can be shown that CTR is at least as secure as the other modes discussed in this section. • Simplicity: Unlike ECB and CBC modes, CTR mode requires only the implementation of the encryption algorithm and not the decryption algorithm. This matters most when the decryption algorithm differs substantially from the encryption algorithm, as it does for AES. In addition, the decryption key scheduling need not be implemented.

CFB: Cipher Feedback Block Mode
Encrypt CFB: Cipher Feedback Block Mode It is possible to convert any block cipher into a stream cipher by using the cipher feedback (CFB) mode. A stream cipher eliminates the need to pad a message to be an integral number of blocks. It also can operate in real time. Thus, if a character stream is being transmitted, each character can be encrypted and transmitted immediately using a character-oriented stream cipher. One desirable property of a stream cipher is that the ciphertext be of the same length as the plaintext. It is assumed that the unit of transmission is s bits; Thus, if 8-bit characters are being transmitted, each character should be encrypted using 8 bits. If more than 8 bits are used. P1 = C1  Ss[E(K, IV)] C1 = P1  Ss[E(K, IV)] Decrypt

It is possible to convert any block cipher into a stream cipher by using the cipher feedback (CFB) mode. A stream cipher eliminates the need to pad a message to be an integral number of blocks. It also can operate in real time. Thus, if a character stream is being transmitted, each character can be encrypted and transmitted immediately using a character-oriented stream cipher. One desirable property of a stream cipher is that the ciphertext be of the same length as the plaintext. Thus, if 8-bit characters are being transmitted, each character should be encrypted using 8 bits. If more than 8 bits are used, transmission capacity is wasted. Figure 20.8 depicts the CFB scheme. In the figure, it is assumed that the unit of transmission is s bits; a common value is s = 8. As with CBC, the units of plaintext are chained together so that the ciphertext of any plaintext unit is a function of all the preceding plaintext. First, consider encryption. The input to the encryption function is a b-bit shift register that is initially set to some initialization vector (IV). The leftmost (most significant) s bits of the output of the encryption function are XORed with the first unit of plaintext P1 to produce the first unit of ciphertext C1, which is then transmitted. In addition, the contents of the shift register are shifted left by s bits and C1 is placed in the rightmost (least significant) s bits of the shift register. This process continues until all plaintext units have been encrypted. For decryption, the same scheme is used, except that the received ciphertext unit is XORed with the output of the encryption function to produce the plaintext unit. Note that it is the encryption function that is used, not the decryption function. This is easily explained. Let Ss(X) be defined as the most significant s bits of X. Then C1 = P1  Ss[E(K, IV)] Therefore P1 = C1  Ss[E(K, IV)] The same reasoning holds for subsequent steps in the process.

Block Cipher Modes of Operation
A symmetric block cipher processes one block of data at a time. In the case of DES and 3DES, the block length is 64 bits. For longer amounts of plaintext, it is necessary to break the plaintext into 64-bit blocks (padding the last block if necessary). To apply a block cipher in a variety of applications, five modes of operation have been defined by NIST SP A (Recommendation for Block Cipher Modes of Operation: Methods and Techniques, December 2001). The five modes are intended to cover virtually all the possible applications of encryption for which a block cipher could be used. These modes are intended for use with any symmetric block cipher, including triple DES and AES. The modes are summarized in Table 20.3, and the most important are described briefly in the remainder of this section.

Integrity Part 1  Cryptography

Data Integrity Integrity  detect unauthorized modification of data (i.e., writing) Example: Inter-bank money transfers Here, confidentiality may be nice, but integrity is critical Integrity not the same as confidentiality Encryption provides confidentiality Prevents unauthorized disclosure But, encryption with any cipher does not protect the data from malicious or inadvertent (accidental) changes. If changes in the ciphertext occurred during transmission, the data integrity has been lost; we need to automatically detect that a change has occurred. Thus, encryption alone does not provide integrity (encryption does not assure integrity) One-Time Pad, ECB Cut-and-Paste, etc. Previously, we understood that block ciphers and their use for confidentiality, Here we will see that block ciphers can also provide data integrity. Whereas confidentiality deals with preventing unauthorized reading, integrity is concerned with detecting unauthorized writing. For example, suppose that you electronically transfer funds from one account to another. You may not want others to know about this transaction, in which case encryption will effectively provide the desired confidential. But, whether you are concerned about confidentiality or not, you certainly want the transaction to be accurately received. This is where integrity comes into the picture. Part 1  Cryptography

MAC: Message Authentication Code
MAC: uses a block cipher to ensure data integrity The procedure is simple: Encrypt the data in CBC mode Discard all ciphertext blocks except the final one Save only the final ciphertext block (the MAC) This final ciphertext block is known as the CBC residue or remainder, serves as the MAC; (CBC-MAC). This MAC serves as a cryptographic checksum for data An Initialization Vector (IV) is needed, and the shared symmetric key required. Part 1  Cryptography

MAC Computation MAC computation (assuming N blocks)
C0 = E(IV  P0, K), C1 = E(C0  P1, K), C2 = E(C1  P2, K),… CN1 = E(CN2  PN1, K) = MAC Send IV, P0, P1, …, PN1 and MAC Receiver does the same computation and verifies that result agrees with MAC Both sender and receiver must know K Part 1  Cryptography

Does a MAC work? Suppose Trudy changes P1 to X C0 = E(IV  P0, K),
Suppose Alice has 4 plaintext blocks Alice computes C0 = E(IV  P0, K), C1 = E(C0  P1, K), C2 = E(C1  P2, K), C3 = E(C2  P3, K) = MAC Alice computes the MAC and sends the plaintext, the IV, and the MAC to Bob Alice sends IV, P0, P1, P2, P3 and MAC Bob computes the MAC using the key and received IV and plaintext. If his computed "MAC" matches the received MAC, then he is satisfied with the integrity of the data. Suppose Trudy changes P1 to X Bob computes C1 = E(C0  X, K), C3 = E(C2  P3, K) = MAC  MAC It works since error propagates into MAC Trudy can’t make MAC == MAC without K

Confidentiality and Integrity
Often confidentiality and integrity are both required. Thus, we could Encrypt data with one key Encrypt MAC with another key Why not use the same key? Send last encrypted block (MAC) twice? This cannot add any security! Using different keys to encrypt and compute MAC works, even if keys are related But, twice as much needed for either confidentiality or integrity alone it would be better to do both confidentiality and integrity with single CBC Can do a little better  ??” Computing a MAC based on CBC encryption is not the only way to provide integrity. A hashed MAC, or HMAC, is another standard approach to integrity digital signature is yet another option.

Uses for Symmetric Crypto
Confidentiality Transmitting data over insecure channel Secure storage on insecure media Integrity (MAC) Authentication protocols (later…) Anything you can do with a hash function (upcoming chapter…) Part 1  Cryptography

Summary: Block vs. Stream Ciphers
Processes the input one block of elements at a time Produces an output block for each input block Can reuse keys More common Block Cipher Processes the input elements continuously Produces output one element at a time Primary advantage is that they are almost always faster and use far less code Encrypts plaintext one bit or byte at a time Pseudorandom stream is one that is unpredictable without knowledge of the input key Stream Cipher A block cipher processes the input one block of elements at a time, producing an output block for each input block. A stream cipher processes the input elements continuously, producing output one element at a time, as it goes along. Although block ciphers are far more common, there are certain applications in which a stream cipher is more appropriate. Examples are given subsequently in this book. A typical stream cipher encrypts plaintext one byte at a time, although a stream cipher may be designed to operate on one bit at a time or on units larger than a byte at a time. With a properly designed pseudorandom number generator, a stream cipher can be as secure as block cipher of comparable key length. The primary advantage of a stream cipher is that stream ciphers are almost always faster and use far less code than do block ciphers. The advantage of a block cipher is that you can reuse keys. For applications that require encryption/decryption of a stream of data, such as over a data communications channel or a browser/Web link, a stream cipher might be the better alternative. For applications that deal with blocks of data, such as file transfer, , and database, block ciphers may be more appropriate. However, either type of cipher can be used in virtually any application.

Chapter 3: Symmetric Key Crypto

Similar presentations

Presentation on theme: "Chapter 3: Symmetric Key Crypto"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chapter 3: Symmetric Key Crypto

Similar presentations

Presentation on theme: "Chapter 3: Symmetric Key Crypto"— Presentation transcript:

Similar presentations

About project

Feedback