Cryptography Lecture 9

CPA-secure encryption Let F be a pseudorandom function Gen(1n): choose a uniform key k  {0, 1}n Enck(m), where|m| = |k| = n: Choose uniform r  {0, 1}n (nonce/initialization vector) Output ciphertext < r, Fk(r)  m > Deck(c1, c2): output c2  Fk(c1) Correctness is immediate

Proof of security (high level) Replace Fk with a random function f Whenever f is evaluated on a new input, the result is uniform and independent of everything else Prove security assuming f is never evaluated on the same input twice Argue that f is never evaluated on the same input except with negligible probability

Breaking encryption schemes Let F be a block cipher Two general CPA-attacks on a scheme F not used correctly (Function of) plaintext directly leaked in ciphertext E.g., < m, Fk(m) > F not used with a random, unknown key E.g., Enck(m) = < r, Fr(m) > Cause F to ever be evaluated on same input twice E.g., Enck(m1, m2) = < r, Fk(r)  m1, Fk(m1)  m2 > Any deterministic scheme

CPA-secure encryption We have shown a CPA-secure encryption scheme based on any block cipher/PRF Enck(m) = <r, Fk(r)  m> Drawbacks? A 1-block plaintext results in a 2-block ciphertext Only defined for encryption of n-bit messages

Encrypting long messages? Recall that CPA-security  security for the encryption of multiple messages So, can encrypt the message m1, …, mt as Enck(m1), Enck(m2), …, Enck(mt) This is also CPA-secure!

Drawback The ciphertext is twice the length of the plaintext I.e., ciphertext expansion by a factor of two Can we do better? Modes of operation Block-cipher modes of operation Stream-cipher modes of operation

ECB mode Enck(m1, …, mt) = Fk(m1), …, Fk(mt) Deterministic Not CPA-secure! Can tell from the ciphertext whether mi = mj Not even EAV-secure!

Not just a theoretical problem! original encrypted using ECB mode (Taken from http://en.wikipedia.org and derived from images created by Larry Ewing (lewing@isc.tamu.edu) using The GIMP.)

CTR mode Enck(m1, …, mt) // note: t is arbitrary Decryption? Choose ctr  {0,1}n, set c0 = ctr For i=1 to t: ci = mi  Fk(ctr + i) Output c0, c1, …, ct Decryption? Ciphertext expansion is just 1 block

CTR mode ctr ctr+1 ctr+2 ctr+t … Fk Fk Fk m1 m2 mt    c0 c1 c2 ct

CTR mode Theorem: If F is a pseudorandom function, then CTR mode is CPA-secure Proof sketch: The sequence Fk(ctri + 1), …, Fk(ctri + t) used to encrypt the ith message is pseudorandom Moreover, it is independent of every other such sequence unless ctri + j = ctri’ + j’ for some i, j, i’, j’ Just need to bound the probability of that event

CBC mode Enck(m1, …, mt) // note: t is arbitrary Decryption? Choose random c0  {0,1}n (also called the IV) For i=1 to t: ci = Fk(mi  ci-1) Output c0, c1, …, ct Decryption? Requires F to be invertible, i.e., a permutation Ciphertext expansion is just 1 block

CBC-mode encryption m1 m2 mt IV    … Fk Fk Fk c0 c1 c2 ct

CBC mode Theorem: If F is a pseudorandom permutation, then CBC mode is CPA-secure Proof is more complicated than for CTR mode

Stream ciphers

Stream ciphers As we defined them, PRGs are limited They have fixed-length output They produce output in “one shot” In practice, stream ciphers are used Can be viewed as producing an “infinite” stream of pseudorandom bits, on demand More flexible, more efficient

Stream ciphers Pair of efficient, deterministic algorithms (Init, GetBits) Init takes a seed s (and optional IV), and outputs initial state st0 GetBits takes the current state st and outputs a bit y along with updated state st’ In practice, y would be a block rather than a bit

Stream ciphers Can use (Init, GetBits) to generate any desired number of output bits from an initial seed s IV Init GetBits GetBits st0 st1 st2 y1 y2

Stream ciphers A stream cipher is secure if the output stream (from a uniform seed) is pseudorandom I.e., regardless of how long the output stream is (so long as it is polynomial) See book for formal definition

Modes of operation Stream-cipher modes of operation Synchronized Unsynchronized

Synchronized mode Sender and receiver maintain state (i.e., they are stateful), and must be synchronized Makes sense in the context of a limited-time communication session where both parties are online and messages are received in order, without being dropped

Synchronized mode s s Init Init st0 st0 m1 y1 y1 c1 GetBits  

Unsynchronized mode Choose random IV to encrypt next message Similar to the first CPA-secure scheme we saw But “natively” handles arbitrary-length messages with better ciphertext expansion

Unsynchronized mode s IV IV s Init Init st0 st0 m1, m2, … y1, y2, … c1, c2, … GetBits   GetBits m1, m2, …

Message integrity

Secrecy vs. integrity So far we have been concerned with ensuring secrecy of communication What about integrity? I.e., ensuring that a received message originated from the intended party, and was not modified Standard error-correction not enough! The right tool is a message authentication code

Passive attacks vs. active attacks So far we have been considered only passive (i.e., eavesdropping) attacks Attacker simply observes the channel In the setting of integrity, we explicitly consider active attacks Attacker has full control over the channel

m m’ m

m, t m’, t’ k k m t = Mack(m) Vrfyk(m’, t’) = 1?