[nanomsg] Re: end-to-end security
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Tue, 11 Mar 2014 15:52:50 +0200
Hi Drew,
On Tue, Mar 11, 2014 at 2:59 PM, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx> wrote:
> Reporting authentication errors. A logical place to do this would be from
> nn_connect, however, my understanding is that the transport connection isn't
> established at that time. One possibility is to introduce a separate
> nn_authenticate function, called after nn_connect and before send/receive.
> Another possibility is to report errors from send/receive themselves.
I think the nanomsg way for now is to use statistics socket for it.
Just like we report connection errors. Because authentication, similarly to
establishing a connection is an asynchronous task (may be done multiple
times for single nn_connect).
> On a socket that has opted in to security, nn_send and nn_recv encrypt,
> decrypt, and verify messages as appropriate. Sockets not opted in are
> unaffected.
>
> New APIs nn_send_raw and nn_recv_raw allow unencrypted reads/writes on
> sockets that have opted into security
>
I think it should be handled by AF_SP_RAW protocol family.
>
> Again, I'm volunteering to land all of this, pretty soonish, if this is
> basically sounding like a patch you want to merge. And I am happy to
> collect feedback and refine some of these details as appropriate.
>
> However, I'd rather not bikeshed on this, as I have done enough bikeshedding
> about encryption features for message-queue projects to last many lifetimes
> ;) So if this work overall isn't feeling right for core, I am completely
> happy to find a place to do it that isn't in core. My feelings won't be
> hurt.
>
There were few threads already on this topic. There are many problems with
encryption. The only simple case being the symmetric key
encryption with a shared key. Is it what you are going to implement?
--
Paul
Other related posts:
