You wouldn't want to use this. The key exchange is vulnerable to replay and identity misbinding attacks. To fix the replay attack, you also need to sign a non

You wouldn't want to use this. The key exchange is vulnerable to replay and identity misbinding attacks. To fix the replay attack, you also need to sign a nonce from the peer (or its ephemeral public key) to prove that the message is fresh. To fix the identity misbinding attack, you also need to sign the identity of the peer. Then it's probably secure, but the protocol would lack identity hiding. You really want a key exchange protocol like SIGMA, which is secure and provides identity hiding. See the following presentation, which presents insecure key exchange protocols (the key exchange from the article is on page 4) while building up to SIGMA: https://www.ietf.org/proceedings/52/slides/ipsec-9.pdf https://www.ietf.org/proceedings/52/slides/ipsec-9.pdf As you can see, this stuff is hard and you really shouldn't be designing your own. CurveZMQ (basically, DJB's CurveCP over TCP) is probably a better choice if you want a NaCl-based secure channel. CurveZMQ also happens to be pretty well documented if you want to learn about what it takes to design a secure protocol: http://curvezmq.org/page:read-the-docs http://curvezmq.org/page:read-the-docs