What I have designed starts from CurveCP and adds some orthogonal anti-backdoors features. Thought it diverge in the server knows the client long term public key which is supposed to have been transmitted by other means.
So it inherits of all CurveCP features: confidentiality, authentication, anti-replay attack, it actually manage correctly nonces and check they are unique.
But it uses uses full binary random nonces - no prefix. It doesn't send public keys in clear, nor encrypted known text as all-zeros in the HELLO message, which IMO may enable plain text attacks. I had a mail exchange with the author, Daniel J. Bernstein, some months ago, he assesses it is not exploitable, but for the respect of my customers, I am paranoid.
I have added some anti-replay attack features and some obfuscation.I will not publish it before the end of 2014, and I have not yet decided of the licence. Possibly a dual licence, one being commercial.
But in my original comment, I just wanted to argue it is better to build a separate security library, independant of the messaging library, and just add a glue patch in one or the other.
Cheers, Laurent. Le 11/03/2014 21:48, Paul Colomiets a écrit :
Hi Laurent, On Tue, Mar 11, 2014 at 7:00 PM, Laurent Alebarde <l.alebarde@xxxxxxx> wrote:That made me redevelop my security stack in a separate library, independent from libzmq. So now, I can choose libzmq or nanomsg or whatever. I have a simple API that do not require integration with the messaging library, and that work only on buffers : receive_handcheck_message send_handcheck_message is_handcheck_finished encode decodeYes. This kinda thing that's easy to implement in nanomsg itself. But, how this works? I.e. is it symmetric encryption with single shared key? -- Paul