Reusing Keys

When presenting the protocol, Chapter 4 says an enigmatic thing:

[…] we may restart the protocol the other way around, however the keys need to be updated to keep the Server in the dark […]

Let’s discover why.

Update your diagram. More specifically, update the equations. Play the role of an adversary Server that only sees \(x_{a_0}, x_{b_0}, r_0, x_{a_1}, x_{b_1}, r_1, x_{a_2}, x_{b_2}, r_2, \dots\) Show that it makes the protocol not secure (according to our security definition).

This is the fun part where you break stuff!

Tip

Click here to get a first hint.

Here, we consider the Server being the adversary. Look closely at our security definition, there is only one property concerning the Server. This is the one you’re trying to break.

Tip

Click here to get a second hint.

The Server can manipulate and combine values.

Tip

Click here to get a third hint.

A bit lost? No worries. This stuff is not obvious the first time you face it.

Here’s a good hint to make it simpler: you only need two rounds to prove that it’s not secure. Keep it simple, don’t exchange Alice and Bob’s roles in the protocol.

Tip

Click here to get a fourth hint.

Another good hint to make it even simpler: you only need to focus on Alice, forget about Bob for now. The reason is you won’t be able to guess \(r_0\) nor \(r_1\) anyway.

Tip

Click here to get the final hint.

You guessed it by now, we’re trying to show that, if Alice and Bob reuse keys, the Server can deduce information. What’s “information”? It can be quite abstract, but any information about \(x_{a_0}\) and \(x_{a_1}\) will do. You don’t have to deduce their exact respective value.

Take a bit more time but, at this point, you may already have the solution without even realizing yet.