I'm getting familiar with Signal key exchange phase and as far as I understand all 3 exchanges between Alice ephemeral key and all of Bob keys from the bundle, I have some thoughts about key exchange between Alice identity key and Bob pre signed key.

I'm aware this is to authenticate Alice and confirm she has identity private key but could this exchange be replaced with one of:

  1. Alice identity key <-> Bob identity key
  2. Alice identity key <-> Bob one time key
  • 2
    $\begingroup$ The protocol discussed is not widely known. Therefore, a link to the description used as reference would help. $\endgroup$
    – fgrieu
    Oct 5, 2021 at 14:11

2 Answers 2


If something in the Signal protocol looks surprising, then the reason it's there is probably related to key compromise. The main thing to keep in mind is the fact that the "identity keys" are long-term secrets.

Suppose Alice has long term key $a^*$ and Bob has long-term key $b^*$, with corresponding public keys $g^{a^*}$ and $g^{b^*}$. They can do normal DH key agreement with these long-term keys, and agree to the secret $g^{a^*b^*}$ and proceed to exchange encrypted messages. But we care about compromise of long-term keys. If Alice's long-term key $a^*$ is compromised at some later time, then the attacker can compute $g^{a^*b^*}$ and violate the privacy of the encrypted messages (in all of Alice's connections!).

If you're familiar with Signal, then you probably know how Signal recovers from key compromise under normal situations. We use a "continuous asymmetric ratchet." Alice sends a new/fresh $g^{a_i}$ with every message, and Bob sends a new $g^{b_j}$ with every message. At all times, they can use the most recent $g^{a_i}$ and $g^{b_j}$ to derive the current shared key $g^{a_i b_j}$.

The important point here is that the $a_i$ and $b_j$ keys are temporary. Alice can throw away $a_i$ after Bob acknowledges that he has moved on to using $g^{ a_{i+1}}$. If an attacker compromises Alice at time $t$, this attacker learns only $a_t$. After a short time, Alice and Bob will stop using $a_t$ and begin using $a_{t+1}$, and the attacker will stop being able to read their messages.

So, if continuous asymmetric ratcheting is the way to recover from key compromise, and we are worried about the long-term (identity) keys being compromised, then the natural solution is to do an asymmetric ratchet as soon as the connection is established (using the identity keys).

This is how I like to think of X3DH. Think of the long-term identity keys as $a_0$ and $b_0$. The parties can agree on a key $g^{a_0 b_0}$. They also immediately send the next messages in their asymmetric ratchet: Alice sends $g^{a_1}$ and Bob sends $g^{b_1}$. Then there will be ratcheted key agreements that give $g^{a_1 b_0}$ and $g^{a_0 b_1}$. X3DH incorporates all 3 of these key agreements together. Importantly, $a_1$ and $b_1$ are short-term secrets -- unique to this session, and discarded after the ratchet moves past them. If a long-term key like $a_0$ is leaked, even the first messages in the connection are protected because the parties have preemptively advanced the ratchet one step, incorporating fresh values $a_1, b_1$.

This is the essence of X3DH. The Signal specification looks a little different than what I described, because one of the goals is to allow parties to establish a connection asynchronously. So we would let Alice (for example) precompute and post $g^{a_1}$ ahead of time, as a "signed pre-key". When Bob wants to establish a connection with Alice for the first time, he fetches $g^{a_1}$ and then sends his $g^{b_1}$ to her. In my view of X3DH, $g^{a_1}$ and $g^{b_1}$ have symmetric roles, but in Signal their roles are not quite the same -- one of them has been precomputed (Alice's "signed pre-key") and the other is computed at the moment of connection (Bob's "ephemeral key"). In the Signal spec, you will see the different terminology break what is otherwise a symmetry in the protocol.


I have a same question, because finally the equations for calculation of SK, SK = KDF (DH1 | | DH2 | | DH3 | | DH4). For replacing the original DH1 = DH(Alice identity key, Bob signed prekey) with DH1 = DH(Alice identity key, Bob identity key) should be able to deduce the shared key SK just as well.

Here the protocol is designed with DH1 = DH(IKA, SPKB) in mind for what additional reason. Is it just because SPKB is the intermediate key?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.