Random walks and analysis of algorithms in cryptography Ilya Mironov Stanford University

Talk overview Cryptanalysis RC4 stream cipher card shuffling brute force attack Broadcast encryption analysis optimization Other work

Talk overview

RC4 stream cipher RC stands for “Ron’s Code,” designed in 1987 by Ron Rivest. Several design goals: speed support of 8-bit architecture simplicity (to circumvent export regulations)

Abridged history of [alleged] RC4™ 1994 – leaked to cypherpunks mailing list first weakness (USENET post) 1996 – appeared in “Applied Cryptography” by B. Schneier as “alleged RC4” 1997 – first published analysis MS theses: 3 PhD thesis: 1

Usage SSL/TLS Windows, Lotus Notes, Oracle, etc. Cellular Digital Packet Data OpenBSD pseudo-random number generator

Encryption key  plain text = cipher text cipher t state

Decryption key  cipher text cipher t = plain text state

Security Requirement Indistinguishability from a perfect source of randomness: given part of the output stream, it is impossible to distinguish it from a random string

Second byte [MS01] Second byte of RC4 output is 0 with twice the expected probability

Related key attack [FMS01] Wireless Equivalent Privacy protocol (part of b standard): Using keys with known prefixes - BAD IV 1, key  IV 1, IV 2, key  IV 2, IV 3, key  IV 3, IV 4, key  IV 4, key

Recommendation Discard the first 256 bytes of RC4 output [RSA, MS] Is this enough?

RC4 internal state Permutation S on 256 bytes: Two indices i, j log 2 (256!  256)  1700 bits …

Key scheduling algorithm (all arithmetic is mod 256) for i := 0 to 255 S[i] := i j := 0 for i := 0 to 255 j := j + S[i] + key[i] swap (S[i], S[j])

Pseudo-random number generator i := 0 j := 0 repeat i := i + 1 j := j + S[i] swap (S[i], S[j]) output (S[ S[i] + S[j] ])

Both RC4’s routines for i := 0 to 255 S[i] := i j := 0 for i := 0 to 255 j := j + S[i] + key[i] swap (S[i], S[j]) i, j := 0 repeat i := i + 1 j := j + S[i] swap (S[i], S[j]) output (S[ S[i] + S[j] ]) key scheduling pseudo-random number generator

Both RC4’s routines for i := 0 to 255 S[i] := i j := 0 for i := 0 to 255 j := j + S[i] + key[i] swap (S[i], S[j]) i := 0 repeat i := i + 1 j := j + S[i] swap (S[i], S[j]) key scheduling pseudo-random number generator j := random (256), j

Both RC4’s routines for i := 0 to 255 S[i] := i j := random (256) swap (S[i], S[j]) key scheduling pseudo-random number generator i := 0 repeat i := i + 1 j := random (256) swap (S[i], S[j]) for i := 0 to 255

S[i] := i i := 0 repeat i := i + 1 j := random (256) swap (S[i], S[j]) Idealization of RC4

for i := 0 to n - 1 S[i] := i i := 0 repeat i := i + 1 j := random (n) swap (S[i], S[j]) Idealization of RC4

Talk overview

Exchange shuffle RC4 card shuffling: i random j iii When i = n - 1 the permutation is random i … not

Perfect shuffling The textbook algorithm to shuffle cards: i random j iii When i = n - 1 the permutation is perfectly random i swap( S[i], S[j]) …

Why is it not random? n! does not divide n n Sign of the permutation: the sign changes each time with probability 1-1/n Positions of individual cards are predictable

First byte of RC4 output The first byte, S[S[1]+S[S[1]]], is biased:

Distinguisher Less than 2,000 to recognize a non- random output with 10% error

Mixing time The permutation becomes more and more random. time nonrandomness

Variation distance Variation distance between two distributions, P and Q on S: d(P,Q)=½  s  S |P(s)-Q(s)| time variation distance

The end of the beginning of RC4 What is the sufficient number of swaps for the permutation to become random? Find t such thatd(P t, U) < 

Card shuffling To shuffle 52 cards: - 7 riffle shuffles ~ 100 random transpositions ~ 30,000 adjacent transpositions - exchange (RC4) shuffles?

Lower bound Sign of the permutation: after t rounds sign can be predicted with probability e -2t

Upper bound Checking argument: initially all cards are unchecked check S[i] if - either i=j - or S[j] is checked keep doing until all cards are checked

Checking argument i j

i j S[i] is indistinguishable from other checked cards j

Checking argument It takes  (n log n) steps to check all cards. It gives an upper bound.

Mixing time at least  (n) at most O (n log n)

What if n = 256? Optimistically (go with the lower bound) mixes in 4  256 steps Conservatively (use the upper bound) mixes in 16  256 steps

New development E. Mossel, A. Sinclair, Y. Peres (Berkeley): the upper bound is tight mixing time = Θ(n log n) Distinguisher: look at the cards from the left half

Talk overview

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[j]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[j] S[2]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[j] S[2] S[j]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[j] S[2] S[j] S[3]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[j] S[2] S[j] S[3] S[j]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[j] S[2] S[j] S[3]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[j] S[2] S[j] S[3] S[j]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[j] S[2] S[j] S[3]

Backtracking j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[j] S[2] S[j] S[3] S[j]

Cost of backtracking Keep guessing until there is a critical mass ≈ 100 entries Keep guessing until there is a critical mass ≈ 100 entries Each guess is ≈ 8 bits, which multiplies the running time by 2 8 Each guess is ≈ 8 bits, which multiplies the running time by 2 8 Estimated running time ~ (for comparison – there are particles in the universe) Estimated running time ~ (for comparison – there are particles in the universe)

Improvement j := S[1] t := S[1] + S[j] output S[t] j := j + S[2] t := S[2] + S[j] output S[t] j := j + S[3] t := S[3] + S[j] output S[t] S[1] S[2] S[3]

Running time of improved algorithm Much more intricate analysis of an unbalanced tree Much more intricate analysis of an unbalanced tree Estimated less than Estimated less than 2 600

Why is it interesting? What about “short RC4”: 64-byte permutation? What about “short RC4”: 64-byte permutation? internal state has size 300 bits 64-byte RC4 is secure against the old attack, borderline under the new attack 64-byte RC4 is secure against the old attack, borderline under the new attack

Talk overview

Broadcast encryption source receivers k kk k kk kk k k k  One rogue user compromises the whole system  Very little overhead

Broadcast encryption source receivers k 1, k 2, k 3, k 4, k 5,…, k n k1k1 k2k2 k3k3 k4k4 k5k5 k6k6 k7k7 knkn … broadcast E[k 1,k], E[k 2,k],…, E[k n,k], E[k,M]

Broadcast encryption source receivers k 1, k 2, k 3, k 4, k 5,…, k n k1k1 k2k2 k3k3 k4k4 k5k5 k6k6 k7k7 knkn …  Too many keys  Simple user revocation

Subset-cover framework (Naor-Naor-Lotspiech’01) S3S3 S5S5 S6S6 S1S1 S2S2 S4S4 S7S7 S8S8

S3S3 S5S5 S6S6 S1S1 S2S2 S4S4 S7S7 S8S8 k3k3 k4k4 k5k5 u receiver u knows keys:

Key distribution Based on some formal characteristic: e.g., DVD’s serial number Based on some formal characteristic: e.g., DVD’s serial number Using some real-life descriptors: Using some real-life descriptors: — Microsoft employees — researchers — California state residents — PhD’s

Broadcast using subset cover S3S3 S5S5 S6S6 S1S1 S8S8 S 10 header uses k 1, k 3, k 5, k 6, k 8, k 10

Subtree difference All receivers are associated with the leaves of a full binary tree k0k0 k 00 k 01 k 0…0 k 0…1 k 1…1

Subtree differences i j special set S i,j

Subtree difference

Greedy algorithm Easy greedy algorithm for constructing a subtree cover for any set of revoked users Easy greedy algorithm for constructing a subtree cover for any set of revoked users

Greedy algorithm Find a node such that both of its children have exactly one revoked descendant Find a node such that both of its children have exactly one revoked descendant

Greedy algorithm Add (at most) two sets to the cover Add (at most) two sets to the cover

Greedy algorithm Revoke the entire subtree Revoke the entire subtree

Greedy algorithm Could be less than two sets Could be less than two sets

Analysis of this algorithm R - number of revoked users R - number of revoked users C – number of sets in the cover C ≤ 2R-1 averaged over sets of fixed size [NNL’01] averaged over sets of fixed size [NNL’01] E[C] ≤ 1.38R simulation experiments give [NNL’01] simulation experiments give [NNL’01] E[C] ~ 1.25R

Analysis of this algorithm R - number of revoked users C – number of sets in the cover If a user is revoked with probability p«1: E[C] ≈ E[R]

Exact formula where

Mellin transform

Asymptotic p E[C]/E[R]

Asymptotic … … 3log 2 4/3 p

Talk overview

Halevy-Shamir scheme Noticed that subtree differences are decomposable: Noticed that subtree differences are decomposable:

Halevy-Shamir scheme Fewer special sets reduce memory requirement on receivers Fewer special sets reduce memory requirement on receivers

Improvement For practical parameters save additionally 20% compared to the Halevy-Shamir scheme For practical parameters save additionally 20% compared to the Halevy-Shamir scheme This is joint work with N. Alon, D. Halevy, A. Shamir This is joint work with N. Alon, D. Halevy, A. Shamir

Talk overview

Other work New classes of hash functions and analysis of a construction for hash functions [Eurocrypt’01] New classes of hash functions and analysis of a construction for hash functions [Eurocrypt’01] Crypto and game theory in peer-to-peer filesharing networks [EC’01, FC’02] Crypto and game theory in peer-to-peer filesharing networks [EC’01, FC’02] Construction of short signatures based on discrete logarithm [CT-RSA’03] Construction of short signatures based on discrete logarithm [CT-RSA’03]