Cipher Transmission and Storage Modes Part 2: Stream Cipher Modes CSCI 5857: Encoding and Encryption

Outline Basic structure of stream ciphers Cipher Feedback Mode Output Feedback Mode Counter Mode Tradeoffs of different stream modes

Need for Stream Ciphers Encrypted data transmitted one block at a time by ECB or CBC – Blocks of size 64 or 128 bits Large blocks not efficient for streaming – Better if messages in terms of individual bits/bytes Goal: Create/transmit ciphertext in smaller blocks

Key Stream Generator Generates “pseudorandom stream” of bits k i – Based on cipher key K – XOR with plaintext bits p i to generate ciphertext bits c i – Recipient uses same key to generate same stream of bits k i for decryption

Block Cipher Stream Generators Uses existing block ciphers (AES or DES) Generates r-bit ciphertext from n-bit blocks – Usually last r bits of ciphertext created by block cipher Input to encryption algorithm usually depends on previous blocks to avoid patterns (like CBC mode)

Cipher Feedback Mode (CFB) Previous ciphertexts used to create shift register S Shift register contents encrypted with key Results placed in “temporary register” T

Cipher Feedback Mode Encryption First r bits of T used to create byte key k i Byte key XORed with next r bits of plaintext to produce next r bits of ciphertext for transmission

CFB Shift Register Previous r bits of ciphertext added to end of shift register S – All other bits in S shifted left – First r bits discarded

CFB Structure and Initial Vector Initial contents of shift register S is some initialization vector IV Generated and sent securely as first ciphertext

CFB Decryption Decryption: Recipient uses previous ciphertext to create same shift register S – Encrypted with key – First r bits taken to create byte key k i – XORed with next r bits of ciphertext received to get next r bits of plaintext

CFB Disadvantages Problem: CFB inherently sequential – Each block depends on previous block(s) – Cannot take advantage of parallel hardware to speed up encryption/decryption – Cannot generate key stream in advance while waiting for rest of message Solutions: Output Feedback Mode (OFB) Counter Mode (CTR)

Output Feedback Mode (OFB) Contents added to shift register taken directly from T Not dependent on the plaintext Could theoretically generate all of key stream in advance

Counter Mode (CTR) Use a simple counter to generate next bytes of ciphertext – Counter increments each time  different ciphertext generated – Know all counter values in advance  Generate all byte keys k i in advance

Counter Mode Structure Counter generates next n bits used in key generator – Encrypted with key – XORed with plaintext Counter incremented before next bits encrypted

Counter Mode Increment Sender/recipient increment counter in same way for each block encrypted/decrypted Sender /recipient must know initial counter value IV – Can be transmitted via ECB mode

OFB and CTR Vulnerabilities If opponent has single known plaintext P 1 and C 1 can then derive entire key stream as P 1  C 1 Key stream same for all plaintext messages, so can decrypt them as well – In OFB/CTR, key stream independent of plaintext encrypted Must use different key each transmission – Must be able to exchange new keys securely Problem for any non-chained stream cipher

What’s Next Let me know if you have any questions Continue on to the next lecture on File Cipher Modes