On the road to Bandol

Starting a session

Protocol

For our session start, we will here use a classical architecture, but with slightly different commands. First, here is a definition of the exchanges between two actors (say, Alice and Bob) to start a secure session:

1. Alice sends a 16-byte random number to a₁ … a₁₆ to Bob.
2. Bob replies with his own 16-byte random number b₁ … b₁₆.
3. Alice and Bob both encrypt a₁ … a₁₆ with their shared secret, getting the value α₁ … α₁₆.
4. Alice and Bob both encrypt b₁ … b₁₆ with their shared secret, getting the value β₁ … β₁₆.
5. The session key becomes α₉ … α₁₆ β₁ … β₈.
6. Alice sends the value β₉ … β₁₆ to Bob, encrypted with the session key, as a proof of authentication.
7. Bob verifies that the value is correct.
8. Bob then sends the value α1 … α₈ to Alice, encrypted with the session key, as a proof of authentication.
9. Alice verifies that the value is correct.
10. The session has started.

I will not attempt to prove that this algorithm has many interesting properties, but I will just highlight a few of its features:

• In steps 1 and 2, both Alice and Bob generate random data that is used in the session startup process, and the session key depends on both sets of random data, as a measure against replay attacks.
• In steps 3 and 4, the simple encryption used here can be replaced by a more complex algorithm, in order to make it more difficult for an attacker to derive the shared secret from a session key.
• The value returned by Alice to Bob on step 6 (and vice-versa on step 8) as proof of authentication shows that Alice got Bob’s random data, and that Alice knows the shared secret.
• The value returned in steps 6 and 8 are both encrypted with the session key, in order to avoid giving away precious information about the shared secret to a potential attacker.

Continue Reading »