Lecture 4: Using Block Ciphers Outline encrypting large messages checking integrity securing DES

Electronic Code Book (ECB) How to use a block cipher to encrypt a large message? break message into blocks M1 C1 E M2 C2 E M3 C3 E M4 C4 E encrypt each block separately with secret key

Problems with ECB plaintext ECB encrypted ciphertext same plaintext block produces same ciphertext can be analyzed, rearranged plaintext ECB encrypted ciphertext rearranging example (from the book) – copy president’s salary into your own position without decoding

One-Time Pad proven (Shannon): XOR a message with a (truly) random number (never reuse it again) – unbreakable (no information is given away) one-time pad – such usage of random numbers stream cipher – generates one-time pad and XORs it with the stream of plaintext to generate ciphertext

Fixing ECB M1 M2 M3 M4 transmit r1, c1, r2, c2, r3, c3, r4, c4 r1 r2 consider this: generate random numbers and XOR with blocks before encoding M1 M2 M3 M4 transmit r1, c1, r2, c2, r3, c3, r4, c4 r1 r2 r3 r4 E E E E C1 C2 C3 C4 M1 XOR R1 = M2 XOR R2; XOR both sides with R1, get M1 = M2 XOR R2 XOR R1; XOR with M2 M1 XOR M2 = R1 XOR R2 problems: need to send twice as much data can still rearrange blocks if two ciphertext blocks equal, know XOR of two plaintext blocks = XOR of the corresponding two random numbers

Cipher Block Chaining (CBC) randomizes output by using previous ciphertext block first block is randomized using initialization vector (IV) IV M1 M2 M3 M4 E E E E see next hidden slide IV C1 C2 C3 C4 how does CBC do decoding?

CBC Decryption & Analysis IV C1 C2 C3 C4 D D D D IV M1 M2 M3 M4 if Ci is lost or garbled then next data item is garbled, the rest are okay to change Mi one needs to change Ci-1 What happens if Ci gets lost or garbled? How much data gets lost? assume an attacker knows block Mi and wants to change it, what does it need to change? can encryption/decryption be done in parallel?

Output Feedback (OFB) Mode OFB is a stream cipher IV – based, IV is transmitted in clear two versions no shifting pad1=e(IV, key) pad2=e(pad1, key) padi=e(padi-1,key) k-bit shifting (see pic) advantages the pad can be pre-generated – no costly operations at run-time (good for multimedia or resource-constrained devices) how much info is affected if portion of ciphertext is garbled/lost? problems if known plaintext, can be altered is random access possible? can encryption/decryption be done in parallel? k-bit shifting version of OFB advantages if garbled (no shifting) – only those plaintext bits are garbled, if shifting – all lost; if lost or duplicated – synchronization lost, rest of stream damaged problems for example – the bad guy got the stream, knows plaintext, XORs with plaintext – gets the pad, then can use the pad to encrypt anything depends on how much shifting, if no shifting – sure, if all shifting - none the picture shows a more complex version of OFB where k bits are shifted

Cipher Feedback (CFB) Mode similar to OFB message data is also used to generate padding advantages is random access possible? what if part of ciphertext is garbled/lost/duplicated? problems is OFB-like pad pre-generation possible? can it be altered if plaintext is known can encryption/decryption be done in parallel? advantages yes the decryption eventually resynchronizes, this is not immediately visible, draw a “broken ladder” of keys as they are used to decrypt a packet (the “ladder” bytes of previous 4 packets (assuming 1-byte shifting) is used to decrypt a packet) problems no not without garbling adjacent blocks encryption – no, decryption - yes

Counter (CTR) Mode CTR is another stream cipher to create pad, IV is incremented and encrypted is random access possible? what if part of ciphertext is garbled/lost/duplicated? is pad pre-generation possible can encryption/decryption be done in parallel? is known plaintext alteration possible? yes no problem – minimum garbling known plaintext alteration possible

Integrity checking automated integrity checking – computer should be able to detect tampering (a human presence should not be required any “garbage” can pass through) message authentication code (MAC) – a cryptographic checksum generated with the help of a key CBC, OFB, CFB and CTR – good security, integrity vulnerable

CBC Residue IV M1 M2 M3 M4 C1 C2 C3 residue E Do CBC encryption on M using key K, throw away all but last block. send message in clear + the “residue”, Used in banking Has property that if you don’t know the key you can’t generate (or verify) the MAC, or modify the message without (probably) changing the MAC however, can generate an arbitrary message matching MAC IV M1 M2 M3 M4 C1 C2 C3 residue E

Joint Privacy and Integrity concurrently use two CBCs – one for privacy, the other for integrity why can’t use only one for both?

Securing DES purpose: retain the same mechanism, expand key size why not double DES? encrypt with K1 twice. How much more work (over DES) for good guys? Bad guys? encrypt with K1 then K2. What is time/memory for bad guys? Good guys? subject to subtle known plaintext attack double encryption with the same key – yet another DES-like block cipher, key the same size, brute force attack possible two different keys: subtle attack becomes possible suppose have a few <m,c> pairs, run it forward on m and backward on c of the first pair for all keys, match results, get matching pairs of keys and try against next pairs

3DES Defined as doing EDE with K1, K2, K3, but standardly K1 is set equal to K3. reason: because of known-plaintext attack, 3DES is considered to only have time-strength equal to 112 bit key, not 168. also, 112 bits considered enough (for now). why EDE instead of EEE? Initial and final permutations would cancel each other out with EEE (minor advantage to EDE) EDE compatible with single DES if K1=K2=K3. double encryption with the same key – yet another DES-like block cipher, key the same size, brute force attack possible two different keys: subtle attack becomes possible suppose have a few <m,c> pairs, run it forward on m and backward on c of the first pair for all keys, match results, get matching pairs of keys and try against next pairs

3DES and CBC same integrity problems as with regular CBC CBC is defined to be done on the outside of 3DES same integrity problems as with regular CBC CBC can potentially be done on the inside of 3DES more secure against tampering but more work garbling/loosing/duplicating of one block garbles the rest of message double encryption with the same key – yet another DES-like block cipher, key the same size, brute force attack possible two different keys: subtle attack becomes possible suppose have a few <m,c> pairs, run it forward on m and backward on c of the first pair for all keys, match results, get matching pairs of keys and try against next pairs