Is the X3DH protocol used by Signal overly complex?

Question

I feel that the X3DH protocol's use of a 3-way DH handshake is unecessary. Couldn't Bob just publish his set of one-time prekeys (each signed with his identity key) to the server, then Alice creates a shared secret using her ephemeral key (signed with her identity key)? This way it doesn't have to even rely on the DH handshake which as for now doesn't have a post-quantum version of it standardized (since SIKE has already been broken), you can easily substitute it for ML-KEM. Is there some kind of disadvantage to using this sort of scheme?

Edit: To clarify, when i say overly complex, i mean that the X3DH protocol's 3-way DH handshake provides no meaningful benefit of any form compared to the simpler process of signing the sender (Alice's) ephemeral key

Answer 1

Edit: To clarify, when i say overly complex, i mean that the X3DH protocol's 3-way DH handshake provides no meaningful benefit of any form compared to the simpler process of signing the sender (Alice's) ephemeral key

Well, this is easy enough to refute. The naïve protocol of "just sign your DH message" is rather substandard:

1. It has poor properties in the face of randomness compromise. Alice's message is $g^a$ along with a signature $S$ on $g^a$. If the adversary compromises her randomness $a$, they can impersonate Alice at will (by replaying $g^a, S$ and using $a$ to compute the session key). You might be saying, "of course compromising her secrets leads to impersonation, what's the point?" Compromising a user's long-term secret inevitably leads to impersonation, but the long-term secret in this protocol is the signing key. This attack is about compromise of the ephemeral secret, and we can easily make protocols where compromising the ephemeral secret does not lead to impersonation.

2. It does not sign/authenticate enough information, making it vulnerable to identity-misbinding attacks (see also this question). The attack is summarized below:

   

   The adversary Charlie replaces one user's signature with its own signature (on the same value). This causes Alice and Bob to agree on a key, but disagree on the identity of their partner. (It is important to state that Charlie does not learn the key in this attack.) Bob correctly thinks that he shares a key with Alice, but Alice thinks the key is shared with Charlie, when in fact it is shared with Bob. Imagine at some later time, Bob publishes the solution to a contest, encrypted under the session key. Alice will think that Charlie is responsible; i.e., Charlie has stolen credit from Bob.

These attacks can be mitigated by making parties sign more information -- instead of just signing their DH message, they must sign their partner's DH message (to fix attack 1) and their partner's public key / identity (to fix attack 2). But this adds additional rounds to the protocol; Alice must wait to receive Bob's DH message before she can sign it. Extra rounds are a bad choice in a messaging app like Signal, because parties are not guaranteed to be online simultaneously. Instead, Signal uses a completely different approach based on implicit authentication, to achieve authenticated key exchange without extra rounds of communication.