Is this scenario of static ECDH public key exchange right?

Question

I'm thinking about the way to build encryption mechanism for 'peer-2-peer' communication. This is a mechanism I had a thought of:

Alice wants to communicate with Bob

First of all, Alice and Bob must know and trust the existence of the same public key server, and retrieved its static DH public key from secure mechanism (like downloading it from secure website.)

1. Alice randomly generates a new DH key-pair, and calculates secret key for the server, then send the public key to the server.

2. Server receives public key from Alice, calculate a secret key from Alice, and send encrypted reply back to her.

3. Alice decrypts the message, if the decrypted is as expected, means the connection is now secure and ready to do key-exchange with Bob.

4. Bob does the same thing as Alice to establish a secure key exchange mechanism.

5. Alice and Bob, yet again, generate a new DH key-pair, and tell the server about the key to exchange with each other.

6. Alice requests a location and public key of Bob from the server.

7. Alice sends a public key from (5) to Bob.

8. Bob calculates secret key for Alice, and sends an encrypted response back.

9. Alice decrypts the message, if the result is as expected, the connection is now established.

Is this (or relevant) method exist in real-world? If so, are there any references?

Sincerely

Answer 1

If I'm understanding your protocol correctly, both parties must trust the server to not do anything malicious. For example, in step 6, what if the server 'lies', and sends its own location and public key, instead of Bob's, in its response back to Alice? In other words, if the server were to act maliciously, it could intercept the messages between Alice and Bob.

Ideally, the server should not have to be trusted - i.e. if Alice and Bob can mutually verify each others public keys (e.g. through some out-of-band channel, or through some sort of PKI, or through some sort of web-of-trust model), then that alone should be sufficient for both of them to ensure secrecy and integrity of the messages sent between the two of them.

Another property that is found in most modern secure protocols is perfect forward secrecy. Perfect forward secrecy ensures that even if and eavesdropper records the ciphertext sent between Alice and Bob, then later Alice and/or Bob's long-term private key is compromised, this private key cannot be used to go back and decrypt the recorded ciphertext. In addition, modern secure protocols should ensure that earlier keys can not be used to derive later keys, and later keys can not be used to derive earlier keys.

The Double Ratchet Algorithm, used in the Signal Protocol has all of the above properties. It has undergone extensive peer review, and has been widely adopted through its implementation in the Signal app and WhatsApp. You might want to consider using this protocol, instead of inventing your own. See https://signal.org/docs/specifications/doubleratchet/ for more info.