Hi > Brian, > > We are not security experts and would love feedback on this design. > > It is quite simple, but for many of us, security is the show stopper > > with 0MQ. This at least gets us moving in the right direction. > > > I am not a security expert either, but anyway: nice! > > One problem I can see is that you can enable/disable encryption on > per-message basis, which presumably means you have encryption bit > stored > somewhere in the message body. That in turn means pyzmq has its own > wire > protocol and is not able to transparently interoperate with other > language bindings. Am I wrong? >
If they've done it like that you're right. Either each binding implements an equivalent or they can't understand the payload. That makes me wonder if the message encryption stuff belongs underneath the 0mq API or maybe in zfl so that all the bindings can at least share the model for communication and collectively improve it over time. I don't mean the transport but rather some form of function that initiates a shared key negotiation (via a few messages akin to SSL/TLS really) and maybe then negotiates the secure session (which is needed to be really secure I fear from my understanding of network security). Regards, Mikael _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
