# How Mutual authentication and Forward secrecy in The X3DH Key Agreement Protocol work?

Can someone explain the statement below from section 3.3 in The X3DH Key Agreement Protocol?

DH1 = DH(IKA, SPKB)

DH2 = DH(EKA, IKB)

DH3 = DH(EKA, SPKB)

DH4 = DH(EKA, OPKB)

SK = KDF(DH1 || DH2 || DH3 || DH4)

DH1 and DH2 provide mutual authentication, while DH3 and DH4 provide forward secrecy

How do DH1 and DH2 provide mutual authentication, and how do DH3 and DH4 provide forward secrecy?

Are these also providing integrity of keys in X3DH exchange between server and Alice while fetching the prekey bundle ?

Bob uploads his signed prekey along with its signature to the server. This can be used to check the key integrity.

After Alice does this, Bob learns who Alice is because she sends him her public identity key $IK_A$ and they compute a shared secret ($DH_1$). Then Alice tells Bob who she is by generating an ephemeral public key $EK_A$ and they generate another shared secret ($DH_2$) that they can both confirm. Notice that at this point, Bob and Alice have authenticated themselves to each other, but since Alice is using an ephemeral key which will be discarded, they cannot prove themselves to a third party (deniability). This is why they don't just compute $DH(IK_A, IK_B)$.

Right after she calculates the secret key $SK$ Alice deletes her private ephemeral key and the DH outputs, but she sends the public part $EK_A$ as part of the initial message to Bob, who does the exact same calculations. The important part is that $EK_A$ is ephemeral and so will be deleted, providing forward secrecy.

If there's a one-time prekey and you get a $DH_4$, that only gives the $KDF$ more key material to enhance the security of the secret key. But it serves the same purpose of forward security that $DH_3$ does.

• how can Bob be sure that the identity key and ephemeral key he got is from Alice ? Bob is just authenticating the use of SK to a person with IKa and EKa ? May 30 '17 at 11:33
• You are correct. This is the statement of Section 4.1: "Before or after an X3DH key agreement, the parties may compare their identity public keys IKA and IKB through some authenticated channel. For example, they may compare public key fingerprints manually, or by scanning a QR code. Methods for doing this are outside the scope of this document. If authentication is not performed, the parties receive no cryptographic guarantee as to who they are communicating with."
– user47922
May 30 '17 at 11:42
• In section 6.2 4th point here whispersystems.org/docs/specifications/sesame/sesame.pdf says that compromising SKb (session key of Bob) allows attacker to impersonate any third party to Bob. Why is that so? We even don't require SK for such impersonation? May 30 '17 at 11:53
• I'm looking at the 4th point in 6.2 from the document you posted. I see "An attacker might try to use compromised keys for passive decryption..." I don't see anything about impersonation in this 4th point. Also, since this is about Sesame (built atop X3DH), you should ask this in a separate question (I'm not as familiar with Sesame off the top of my head).
– user47922
May 30 '17 at 17:05