## Lecture 4

In today’s lecture we covered quite a bit:

• We discussed chosen-plaintext security and why it is important.
• We noted that deterministic encryption schemes cannot be secure against chosen-plaintext attacks
• We introduced block ciphers, discussed the most common examples used in practice, and showed how to use block ciphers to construct encryption schemes secure against chosen-plaintext attacks.
• We then moved on to discuss message authentication codes

For those who want to test their understanding of the issues so far, try answering this question.

### 17 Responses to “Lecture 4”

1. Anonymous Says:

Even though I am not registered in this class, I think this question is a very good example to see understanding of the basics of the deterministic/randomized encryptions and authentication (I am trying to educate myself by following Prof. Katz’s lecture slides and this blog. I hope that Prof. Katz gives me the opportunity to join this blog actively).
Since I do not have the opportunity to verify my understanding, I try to write my solutions and hope to get a feedback if I am thinking right or wrong.

Question-1:
—————-
assume that the encryption scheme Enc_k(.) employed in the protocol is chosen-plaintext secure. That is, application of Enc_k(.) on the *same* message outputs different ciphertexts. This means, there are 2^n ways to encrypt the same message, where n-is the key-length of the encryption.
In fact, this is the main problem in the protocol.

Assume that Eve wants to impersonate Alice to Bob for the random value *r*. Furthermore, assume that Alice encrypts r into a ciphertext c_a. What Eve needs to do is sending an encryption of r, i.e., c_e with c_e !=c_a. As chosen-plaintext attack allows Eve to find such a value, She can send c_e to Bob to impersonate Alice.

Summarizing, the main problem is here that the encryption is randomized. This is not useful for authentication.

Question-2:
—————-
Any deterministic encryption scheme is not secure against chosen-ciphertext attack. A deterministic encryption means that the same message has to encrypt always the same ciphertext.

Assuming that Enc_k(.) is a deterministic encryption function, Eve has to find a ciphertext, c_e !=c_a, but, Dec_k(c_e) = Dec_k(c_a) to be able to impersonate Alice. However, this is computationally infeasible, if Enc_k(.) is a secure deterministic encryption function.

Question-3:
—————-
The right primitive in the protocol is a MAC.
In the protocol, Alice should send (t = MAC_k(r)) to Bob. Bob should check if Vrfy_k(r, t) = 1.

2. jonkatz Says:

Hmm…there seem to be some points of confusion here.

First of all, Q1 asks for a *specific example* of an encryption scheme secure against chosen-plaintext attacks (let me call such a scheme “CPA-secure”) that leads to an insecure protocol. You gave instead a general argument why randomized encryption schemes *always* lead to an insecure protocol. But that is not true — there exist CPA-secure encryption schemes for which the protocol *is* secure. The point of the question is that CPA-security does not *necessarily imply* a secure protocol.

(Also, you wrote that for a CPA-secure scheme there are 2^n ways to encrypt the same message…but there is not necessarily any relation between the randomness and the key length.)

For Q2, there are deterministic schemes that make the protocol secure as well as deterministic schemes that make the protocol insecure. So your argument is again not correct. (The question is asking for a *particular example* of a scheme that is not CPA-secure but for which the protocol is secure.)

Also, based on your answers I think you a misunderstanding the attack model. We are *not* looking at man-in-the-middle attacks here. Rather, you should consider an adversary who (1) eavesdrops on multiple executions of the protocol, and then (2) tries to impersonate Alice to Bob.

For Q3, you are absolutely right. =)

3. jonkatz Says:

Any other takers? This question (or a close variant) would make a good exam question…

4. Anonymous Says:

Thank you very much for the clarifications. Here goes my second try 🙂

Question-1:
—————-
Let Enc_k be an encryption function defined as
Enc_k(r,iv) = F_k(iv xor r).
Here F_k is a keyed invertible permutation, and iv is a chosen at random in each encryption. A resulting ciphertext is a tuple (Enc_k(r,iv),iv).

(Corresponding decryption function is
Dec_k(Enc_k(r,iv),iv) = F_k^-1 (Enc_k(r,iv)) xor iv.

This encryption scheme is randomized, since iv is chosen at random for each encryption. Therefore, the encryption is also CPA-secure (Assuming that F_k is secure).

Eve wants to to impersonate Alice to Bob after having eavesdropped a ciphertext for a random value r:
Since Eve knows r, iv, and F_k(iv xor r)), she can now impersonate Alice to Bob for any random r’ chosen by Bob by computing

iv’ = (r’ xor r xor iv)
and sending
(F_k(iv xor r), iv’) as the valid encryption of r’.

Summarizing, CPA-secure encryption does not imply security for the given protocol.

Question-2:
—————-
Encryption function is deterministic, therefore, not chosen-plaintext secure, if iv is selected as a constant string in the encryption scheme above:

Enc_k(r,iv) = F_k( r xor iv), where iv = {0}^n.

Now, Eve cannot impersonate Alice to Bob, since iv is a constant value known to Bob.

Summarizing, an encryption scheme which is not CPA-secure may imply security in the given protocol.

5. jonkatz Says:

Correct! But let me nit-pick a little bit:

Question-1:
—————-
Let Enc_k be an encryption function defined as
Enc_k(r,iv) = F_k(iv xor r).

It would be more accurate to say that encryption is defined as
Enc_k(r) = (iv, F_k(iv xor r)), where iv is chosen at random.
(The iv should not be given as input to encryption.)

Note also that this is exactly CBC mode.

This encryption scheme is randomized…Therefore, the encryption is also CPA-secure (Assuming that F_k is secure).

Well, a scheme must be randomized if it is to be CPA-secure, but that does not mean that every randomized scheme is CPA-secure! Fortunately, since your scheme corresponds to CBC encryption, it is CPA-secure.

Otherwise, you got it exactly right.

Question-2:
—————-

Enc_k(r,iv) = F_k( r xor iv), where iv = {0}^n.

Of course, this is just Enc_k(r) = F_k(r).

6. Anonymous Says:

I am very happy to be able to give *not completely* precise, but the correct answer.

But, I am also a little bit confused. In your fist e-mail, you meant that there is a CPA-secure encryption that also implies security in the given protocol. Similarly, you said that there is a deterministic encryption scheme for which the protocol is not secure.

Now, I am asking myself, if we are ready (according to slides what you have presented so far what I am following on-line) to be able to answer this questions?

7. Anonymous Says:

I have a question.
In the protocol, let say that Eve has eavesdropped the authentication protocol for random values r_1, …, r_n chosen by Bob. (I think) We say that Eve impersonates Alice to Bob, if she can generate a valid encryption of a random value r chosen by Bob, where r != r_i for all i=1 to n.
In case of an encryption mode, Eve also sees the IVs sent with the encryptions.
So, my question is, if it is allowed for Eve to use a IV which has been already used in previous encryptions. Or, does the answer depend on the attack model which we define?

• jonkatz Says:

Actually, we say Eve impersonates Alice to Bob if she can generate a valid encryption of a random value r chosen by Bob. There is no requirement that r != r_i for all r_i !! (Think in terms of the real world: would you say it’s ok for the adversary to impersonate Alice just because r=r_i for some i??)

It is for exactly this reason that we must choose the length of the random challenge long enough to make sure that r-values don’t repeat (except with very small probability.)

• Anonymous Says:

I have a feeling that I am seeing the things different than before after your answers. Thank you!!

Ok. if the length of r is large enough and it is chosen at random, the probability of a repetition is negligible => we do not require that r != r_i for all i.

This is also true for repeating IVs, if the length of IV is large enough and it is *honestly* chosen at random.

Eve is unlikely to see any repeating IV, since Alice is honest. But, Eve does not need to be honest and can re-use any IV which was chosen by Alice before. Since there is no requirement that IV != IV_i for all i, this would let Eve to be able to generate a valid encryption for Bob.

8. Encryption and authentication protocols « CMSC414: Computer/Network Security Says:

[…] By jonkatz In case you missed it, a question I asked on this blog way back in lecture 4 has generated a bit of discussion (which I am glad to see!). I’ll try to come up with similar […]

9. Anonymous Says:

Please let me bother you one more time on this topic.

Lessons learned so far:
———————————
The root of the insecurity above was the fact that Eve could re-use IVs. The is was also the idea in my attack above.

Now, I changed to the Question-1 and Question-2 as follows:
———————–
Question-1++:
———————–
Show an encryption scheme that is secure against CPA- attacks and that would
lead to a secure protocol if plugged into the above.

———————–
Question-2++:
———————–
Show an encryption scheme that is not secure against CPA-attacks and that
would lead to an insecure protocol if plugged into the above.

For now, I will try to answer the first question. Any taker for the second question is welcome. Otherwise, I will also try to solve it.

—————-
let be the encryption is defined as
Enc_k(r) = (iv, iv xor F_k(r)), where iv is chosen at random.

(Corresponding decryption is defined as
Dec_k(Enc_k(r)) = F_k^-1(Enc_k(r) xor iv))

claim: This encryption would led to a secure protocol if plugged into the given authentication protocol.

proof sketch:
I have a strong intuition that the encryption is CPA-secure. But, I do not know how to formally proof it. I think that the given encryption would be used, let say, to simulate CBC encryption.

Given a random value r’ and given the encryption above, Eve has to compute F_k(r’) to be able to impersonate Alice to Bob. However, she cannot do this without having the secret key k.

• jonkatz Says:

The root of the insecurity above was the fact that Eve could re-use IVs.

I don’t know if I would put it that way. Re-using the IV was a particular way to attack the scheme, but the problem is more fundamental…

let be the encryption is defined as
Enc_k(r) = (iv, iv xor F_k(r)), where iv is chosen at random.

Actually, this scheme is not CPA-secure. Note that the iv essentially doesn’t add anything, since an attacker can recover F_k(r) by xor’ing the first half of the ciphertext with the second. And then two encryptions of the same value r could be identified…

• Anonymous Says:

Yes, of course!!

the encryption and decryption should be defined as follows:

Enc_k(r) = (iv, F_k(iv) xor F_k(r)), where iv is chosen at random.

Dec_k(Enc_k(r)) = F_k^-1(Enc_k(r) xor F_k(iv))

• jonkatz Says:

Not at all what I was expecting, but yes this would work. (Notice that what you are doing is essentially applying CTR-mode encryption to the MAC F_k(r).)

The solution I was looking for was to just use an encryption scheme that gives you confidentiality *and* integrity, e.g., the encrypt-then-authenticate approach.

10. Anonymous Says:

Correction above:

Lessons learned so far:
———————————
The root of the insecurity above was the fact that Eve could choose IVs such that that enables the attack (re-using is not necessary. Eve’s IV is not randomly selected, but, deterministically to enable the attack).