CSCI 7000: Assignment #5

CSCI 7000 - Crypto Seminar - Spring 2003

Assignment #5

Due: Apr 22nd, 2003 at 11am MDT

1. In class we suggested that we might try building a MAC from a cryptographic hash function h() by simply turning h() into a keyed hash function. (Assume that h is constructed using the Merkle-Damgaard construction.) One suggestion was to prepend the key k to the message M. In other words, MAC_k(M) = h(k || M) where the double bars denote string concatenation. Show that this does not work (ie, show that given a valid pair M, MAC_k(M), you can efficiently produce a different message M' along with a tag MAC_k(M') without knowing k).

2. Now consider building a MAC from h() (where h() is once again formed via the Merkle-Damgaard construction and has a b-bit output) using the construction MAC_k(M) = h(M || k). This is still insecure, but a bit harder to crack. Show that in expected time O(2^b/2) you can find two distinct messages M and M' such that given MAC_k(M), you can find MAC_k(M') without knowing k.

3. Assume RSA. The public key is (411816231521, 5). The encoding method is to take 8 characters of plaintext and convert to an integer M1. Then encrypt under the public key as usual, to obtain C1. Then we take the next 8 characters of plaintext and convert to M2, which we encrypt to C2. And so forth.

The conversion works as follows: we treat a string of 8 alphabetical characters as a vector of 8 coordinates, each of which is between 0 and 25. (A is 0, B is 1, ..., Z is 25). For example, HEYTHERE converts to (7,4,24,19,7,4,17,4). We then convert this to an integer by taking these coordinates as the digits of a base-26 number. So HEYTHERE converts to the integer 7*26⁷ + 4*26⁶ + 24*26⁵ + 19*26⁴ + 7*26³ + 4*26² + 17*26 + 4 = 57752296086.

Show that this conversion process always produces an integer between 0 and n-1 for the n given above in the public key.
Assuming that the ciphertexts listed below are encrypted using the public key above and the given conversion process, recover the plaintext. Be sure and document your method. (Hint: Log on to a Unix box and type man factor.)
```
225803654487   27035345731   318496681005    222309193242   128671002039
```

4. Let C(N,r,g) be the probability that if you throw r red balls and g green balls into N bins, each ball being randomly and independently thrown, then at least one red ball and one green ball land in the same bin.

What is C(N,r,1)?
What is C(N,r,2)?
Find C(N,r,g) under the assumption that no two red balls ever land in the same bin.
Let r=g=sqrt(N). Find the limit as N goes to infinity of C(N,r,g) under the assumption that no two red balls ever land in the same bin.
Find the best bounds you can on C(N, r, g) without the assumption above. (Hard!!)

5. Let's suppose we're using a cryptographic hash function hash() which outputs 64 bits. As usual, we hash-then-sign messages rather than sign them directly. Consider the following setup:

We have two contracts, G and E (for "good" and "evil") for Bob to sign. We'd like Bob to sign E, which allows us to have all of his money. But we know he will sign only G.
We make 2³² distinct versions of G, G₁, G₂,..., which look just like G (we could, for example, replace SPACE with SPACE BACKSPACE SPACE in various places). We likewise make 2³² distinct versions of E, E₁, E₂,....
We now compute the hash on each G_i and each E_i.

Give a rough approximation on the probability that hash(G_i) = hash(E_j) for 1 <= i,j <= 2³².
If you find such a collision, can you get Bob to sign E? How?