Encryption
0MQ is not as such secure, any more than its underlying transports are secure. That is, you don't expect TCP to do encryption, and neither does 0MQ. However, 0MQ applications that carry data across the Internet _do_ need security and there's been quite a lot of talk on how to do this.
The options seem to be:
- Use a VPN (horrid, for most people except network admins who like this)
- Use per-message encryption (as PyZMQ does but it leaves the question of key exchange unsolved)
- Use TLS/SSL as a transport (seems cleanest but is incompatible with multicast and the notion of hops over devices)
- Tunnel over a secure protocol, e.g. HTTPS (should be interesting, especially to make 0MQ accessible to web applications)
Comments: 5
Written: 06 Nov 2010 16:30
Revised: 12 Dec 2011 09:35
If you found this page useful, please rate it up so others will find it.
Edit this page | Tags | Print
See also
- Binding Abstractions
- cppzmq
- Heartbeating and Keep-Alive
- libzutil
- Long-term Planning
- Monitoring Support
- ØMQ-over-HTTP discussion
- ØMQ Projects
- Project Basket
- Publisher Side Message Filtering
- Publish-Subscribe Authentication and Encryption (PSAE)
- Release Process
- Requirements For Reliability
- St. Valentine's Day Massacre
- zmq_poll workaround
Show summary of topics category
Who's watching this page?
... and more
page revision: 2, last edited: 12 Dec 2011 09:35
Any progress on that? Currently we're planning to use ZMQ in our project but absence of SSL transport or other standard encryption is a problem. We can use own encryption handling of course, but it's not good, i think…
Thinking about this, I can see a possible usage. In a chatroom-type application, the server can communicate with a Public Key server to encrypt outgoing message to whomever is logged on AND who has lodged their Public Key with the server.
The chat client can hold its own Private key, and the server's public key.
First message on login would handle the Key Exchange automatically and thereafter flag that person as 'securely logged on'.
Any comments, one way or the other?
munged may be an option.
Could you maybe add the ability to set a preshared key on a socket? If this is done in 0MQ it would by much easier than doing the encryption/decryption on different OS and different languages. Maybe it's not a perfect solution, but it would work with multicast and I think it's better than nothing while waiting on someting like SSL or so.
Hi, I am looking into the possibility to use the zeroMq from z/OS accessible from assembler. Does a z/OS option exist?
Then there is the question about security. In our organization nothing is accepted by security boards if the transport cannot be encryption and secured against manipulation. Currently I cannot see any alternative to SSL because of the administration of certs which is already in place in most organizations.
If no assembler routines exist in the existing implementation, what would be the cost to implement a component with basic support (point 2 point, safe delivery, delivery once? We will consider developing a “client” if the effort is reasonable in man hours.