not sure if this is relevant to the ongoing security discussion you guy's are having, but a very solid crypto person in the haskell community pointed me to noise protocol https://github.com/trevp/noise/wiki associate example haskell implementation https://github.com/thoughtpolice/hs-noise noise seems to have a lot of good properties, though i'm not sure how well it'd play with nanomsg :) -Carter On Wed, Mar 12, 2014 at 6:17 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > There have been a lot of talk about adding security to nanomsg in past > few days. > > In this email I am not going to discuss any concrete proposals, rather > it tries where the extension points are what pros/cons they have: > > Adding security at network level > - -------------------------------- > > 1. The security is added below the transports, e.g. IPSec, VPN. > 2. No need to change nanomsg in any way. > > Adding security at transport layer > - ---------------------------------- > > 1. The security is added as a new transport protocol (e.g. "tls://") > 2. The mechanism is transport-specific and won't work for other > transport protocols. > 3. It works only on hop-by-hop basis. > 4. All the necessary params are passed to the transport either via > connection string (e.g. "tcp://192.168.0.111:5555") or transport > specific socket options (e.g. NN_TCP_NODELAY) > 5. The transport does its best to keep the communication channels > open, for expample by re-trying to open a channel after a failure. > 6. It doesn't report any errors to the user (except via > monitoring/management tools). > 7. It doesn't report any specifics about peer identities to the user. > 8. The problem is well understood and addressed by existing libraries. > > Adding security at scalability layer > - ------------------------------------ > > 1. The security is added to a specific SP protocol (e.g. REQ/REP) > 2. It won't work for other SP protocols (e.g. PUB/SUB). In other > words, if Drew is interested of implementing SP-level security for > REQ/REP he can fully ignore PUB/SUB issues. > 3. It works on end-to-end basis. The devices are not involved in any way. > 4. All the necessary info can be passed via SP-protocol-specific > socket options (e.g. NN_SUB_SUBSCRIBE). > 5. It is completely agnostic of the underlying transport, i.e. is > should work as well with TCP as with UDP etc. > 5. The problem is not well understood and requires some original research. > > - From the implementation point of view, the good news is that in all > cases the security is clearly decoupled from nanomsg core: > > 1. Security on network level -- nanomsg can be completely agnostic > about it. > 2. Security on transport layer -- the functionality is neatly > contained in a transport. Transports have a well-defined interface and > although they are compiled as part of nanomsg at the moment, they can > be moved to separate shared libraries in the future. > 3. Security on scalability layer -- in theory this can be built on top > of nanomsg and possibly merged into it later on. Alternatively, it may > turn out that it has to live directly inside existing SP protocols > (rather than atop of them), in which case we have well-defined > interfaces for building new SP protocols and we can even move them > into independent shared libraries in the future. > > Martin > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTIDQzAAoJENTpVjxCNN9Y900H/0vo058CNNoYxgASce2MJVdv > 4QsMMId2yCaVZSfP3abyLJva8YL7GsTfTP0W38AI9BQP0VIc4e+v7g2NTBR9i+8f > KfTRQrRWLqfTYNleo7qUMHPHwDfb2zn+X0X8+qIq312S+cqkT6/HXvKVLmpKnGnu > RG2JiiF6GigIgwaC31jrSGiiaLNY/MaslGlNkCIhQlJbG8hqWoECC2vwujtMJUUZ > YSIKzQKpp2jAWc1uE1f47pYMgJBR9Fv4+i5I0c6ZezGksZ+dg2aOPjEFK3DUSZHS > cHI3bF9IrDxhoP/0VDnWy8bEVnjLFqrViN1HspFb0srC8aO9pPnywdGNIfQcnWw= > =3oQT > -----END PGP SIGNATURE----- > >