There's no encrypted bit or anything. This isn't 'Encrypted ZMQ', it's just an object that encrypts messages prior to sending them. Think of it more as a wrapper than anything. The messaging library has no sense of whether a message is encrypted or not, you have to specify that in user code:
a.send(msg, encrypt=True) must be matched with: b.recv(decrypt=True) Otherwise b would just receive the encrypted buffer, which is perfectly valid, if for instance b is just going to relay it to c without looking at it, and c is the real destination. Another example, in the sample code, I used blowfish to encrypt the messages. Any program in any language that has access to a blowfish implementation (and the original password) can understand the messages, and any zmq implementation can receive the encrypted messages. This follows in general: The EncryptedSocket is passed an opaque cypher object, and it is up to the user to ensure that the destination has a complementary cypher. This is encryption *on top of* zmq, not inside it. By the way, we would really love it if an SSL/TLS transport were part of the underlying ZMQ. As the earlier security discussion pointed out, message encryption and transport encryption are different things, and both are valuable. Transport encryption would be part of zmq itself, but message encryption can be done entirely without the knowledge of the library, as is done here, since an encrypted message is itself just a message. -MinRK On Nov 2, 2010, at 0:58, Mikael Helbo Kjær <[email protected]> wrote: > 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
