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.

### Like this:

Like Loading...

*Related*

This entry was posted on September 14, 2009 at 8:20 pm and is filed under lectures. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

September 27, 2009 at 7:19 am |

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.

September 27, 2009 at 8:38 am |

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. =)

September 27, 2009 at 8:39 am |

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

September 27, 2009 at 11:33 am |

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.

September 27, 2009 at 11:43 am |

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

everyrandomized 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).

September 27, 2009 at 12:08 pm |

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?

September 27, 2009 at 2:34 pm |

Yes, we have covered schemes that would suffice for answering these questions.

September 29, 2009 at 3:10 pm |

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?

September 29, 2009 at 3:34 pm |

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.)

This should answer your question about repeating IVs as well.

September 29, 2009 at 4:09 pm |

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.

September 29, 2009 at 4:13 pm

Exactly right!

September 29, 2009 at 3:36 pm |

[…] 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 […]

September 29, 2009 at 5:32 pm |

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.

Answer-1++:

—————-

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.

September 29, 2009 at 5:56 pm |

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 asEnc_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…

September 29, 2009 at 6:25 pm |

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))

September 29, 2009 at 11:31 pm

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.

September 29, 2009 at 5:40 pm |

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).