First, I realize trying to come up with your own crypto schemes is not a good idea. I'm a relatively new member of a team of developers utilizing such a custom scheme and I'm trying to come up with arguments to argue against that policy.
To secure communications between a client and a server, we have a standard Diffie-Hellman implementation as described on Wikipedia but modified in such a way that
g (base) and
B (the server's private/public key) are static.
b are constants in the server code, while
B are embedded in the client code.
The client then picks
A, computes the shared secret, uses that as a key for AES256-GCM, then embeds the encrypted payload &
A in one message to the server, which can then derive the shared secret and decrypt as in standard DH.
Standard Diffie-Hellman provides no authentication and so is vulnerable to MITM - in this case, since the server's public key is fixed, it seems that this weakness is avoided?
I've been reading about ephemeral vs static DH modes, the article on Wikipedia has a section on the subject. It seems like we're using the ephemeral-static variant. However, the information I found is usually in the context of SSL/TLS (, ), which incorporates X509 as an authentication mechanism, so for purposes of considering MITM weaknesses, that seems different.
- does our modification of DH (alone) provide sufficient security against man-in-the-middle attacks?
- does it break anything in Diffie-Hellman otherwise?