[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?


Other related posts: