4 ms·

I believe the Salt Stack guys have already got a crypto implementation on top of ZMQ that has been pretty thoroughly vetted. Might be worth checking it out and

by cbsmith 14y ago

I believe the Salt Stack guys have already got a crypto implementation on top of ZMQ that has been pretty thoroughly vetted. Might be worth checking it out and collaborating with them.

jacques_chester 14y ago
I'm not sure where I'd place my trust. The CurveZMQ is based on CurveCP, which was designed by CJ Bernstein. CJB is a well known and generally well-regarded cypto expert, so that gives him substantial points. However, CurveZMQ drops a number of CurveCP features that are deemed unimportant in the context of the ZMQ environment (to do with session handling in UDP). Maybe that's fine ... maybe it's not. Software in general has the annoying characteristic of spooky second-order effects appearing from "totally unrelated" local changes; in security those second-order effects are quickly found and exploited. Meanwhile the Salt Stack guys seem to have stitched together some common crypto primitives into something workable, but ... again, I'm unclear about that. There are so many ways to fuck up a crypto protocol -- I recently spent three months iterating one and the final design was as far from the original as oranges from unicorns. One of the beauties of sticking with TLS, for all its inconvenience at times, it that is under constant scrutiny. Security is one area where Linus's Law really does seem to apply.
- cbsmith 14y ago
  The Salt Stack guys basically did OpenSSL over UDP. I totally agree about the difficulties involved and most importantly Linus' Law, which is why I think working with the Salt Stack guys is a good idea: their code has been audited for security by a number of other parties.
  - lucian1900 14y ago
    But it's not actually DTLS tunneled over ZMQ (which would have been reasonable), but their own protocol. Just how many vulnerabilities did the various versions of SSL have?
    - cbsmith 14y ago
      So far, not much has been found. I'd still take it over CurveCP.
      - lucian1900 14y ago
        But something will be found. My point is that I trust neither Salt's thing nor CurveCP. One is used by a single application, the other is too new. SSL was built and vetted by many parties over a long period of time and it was still broken. Anything other than an existing widespread protocol is folly.
        cbsmith 14y ago
        My point was that Salt is much further along towards being that goal than CurveCP. It also minimized how much it reinvented (most of what it does is straight OpenSSL), so it benefits to a large extent from SSL's heritage.
      - hintjens 14y ago
        It's not an either-or choice. Salt's security is good but it's been a request from that team, as from others, to get security into the libzmq core. Doing it at the application level is problematic for many reasons. It's unreasonably complex, and does not play well with 0MQ sockets (many of which like PUB-SUB and PUSH-PULL are unable to do two-way negotiation). With CurveCP you can still use TLS for key exchange itself; what CurveCP provides is a highly robust answer for the actual connection: short term keys and nonces. It's new but so is Salt's crypto algorithm, which was not built to quite the same level of paranoia as CurveCP. We're still some time away from working code in libzmq and as much as a year or two from a crypto layer that's properly hardened. Having it in libzmq will mean it gets much more attention, which can only be good.
    - rumcajz 14y ago
      DTLS works only for payloads up to 16kB.
  - ibotty 14y ago
    but how can a curvecp based protocol benefit from a tls over udp protocol?
- b6 14y ago
  Correction: D. J. Bernstein, DJB.
  - jacques_chester 14y ago
    Oh jeeze, I'm embarrassed. :|
- hintjens 14y ago
  The Salt security layer is great, and I've worked with Thomas Hatch on abstracting it for wider use. We wrote this http://www.zeromq.org/topics:pubsub-security http://www.zeromq.org/topics:pubsub-security some time ago. While it's good, it has a number of weaknesses that CurveCP addresses, and which CurveZMQ includes. The parts of CurveCP that we don't implement are quite specifically to do with traffic control over UDP, name resolution, etc. and not security. The second problem with Salt's security is that it's not inside 0MQ but layered on top. This has a number of consequences such as interoperability and reusability. Our goal with CurveZMQ is to put this into the 0MQ kernel so it's available across all socket types. It will work over PUB-SUB as well as ROUTER-DEALER or PUSH-PULL. It will work over any intermediaries and since it's basically CurveCP, it will let you do things like migrate your clients (changing IP address) without re-establishing the secure session. CurveCP is really awesome and worth learning. It is really the security model we've been looking for for years, for ZeroMQ. The big difference between CurveZMQ and TLS is this: using TLS is complex. One of the visions of NaCl and thus CurveCP and CurveZMQ in turn is that simple is more secure than complex. Users can't make as many mistakes. CurveCP and CurveZMQ are simple. The current code for CurveZMQ is under 700 lines of C (assuming you have libsodium) and I didn't try to abstract any of the encryption calls; it's a flat implementation of the CurveCP handshake.
  - jacques_chester 14y ago
    OK, TLS is complex. But a lot of that is due to its configurability. How would you have fared if you'd picked a simpler TLS library (PolarSSL, for example, is meant to be embedded) and then simply defined a single ZeroMQ configuration profile and said "that's it, that's all we're going to support"?
    - cbsmith 14y ago
      > OK, TLS is complex. But a lot of that is due to its configurability. ...and as many have noted, that configurability is the root of a lot of security problems. The pick one approach and say, "that's all we're going to do" might be one way to solve the problem. I'm not sure it'd be any better.
  - 14y ago

by cbsmith 14y ago

I believe the Salt Stack guys have already got a crypto implementation on top of ZMQ that has been pretty thoroughly vetted. Might be worth checking it out and collaborating with them.

jacques_chester 14y ago

I'm not sure where I'd place my trust. The CurveZMQ is based on CurveCP, which was designed by CJ Bernstein. CJB is a well known and generally well-regarded cypto expert, so that gives him substantial points. However, CurveZMQ drops a number of CurveCP features that are deemed unimportant in the context of the ZMQ environment (to do with session handling in UDP). Maybe that's fine ... maybe it's not. Software in general has the annoying characteristic of spooky second-order effects appearing from "totally unrelated" local changes; in security those second-order effects are quickly found and exploited. Meanwhile the Salt Stack guys seem to have stitched together some common crypto primitives into something workable, but ... again, I'm unclear about that. There are so many ways to fuck up a crypto protocol -- I recently spent three months iterating one and the final design was as far from the original as oranges from unicorns. One of the beauties of sticking with TLS, for all its inconvenience at times, it that is under constant scrutiny. Security is one area where Linus's Law really does seem to apply.

cbsmith 14y ago
The Salt Stack guys basically did OpenSSL over UDP. I totally agree about the difficulties involved and most importantly Linus' Law, which is why I think working with the Salt Stack guys is a good idea: their code has been audited for security by a number of other parties.
- lucian1900 14y ago
  But it's not actually DTLS tunneled over ZMQ (which would have been reasonable), but their own protocol. Just how many vulnerabilities did the various versions of SSL have?
  - cbsmith 14y ago
    So far, not much has been found. I'd still take it over CurveCP.
    - lucian1900 14y ago
      But something will be found. My point is that I trust neither Salt's thing nor CurveCP. One is used by a single application, the other is too new. SSL was built and vetted by many parties over a long period of time and it was still broken. Anything other than an existing widespread protocol is folly.
      - cbsmith 14y ago
        My point was that Salt is much further along towards being that goal than CurveCP. It also minimized how much it reinvented (most of what it does is straight OpenSSL), so it benefits to a large extent from SSL's heritage.
    - hintjens 14y ago
      It's not an either-or choice. Salt's security is good but it's been a request from that team, as from others, to get security into the libzmq core. Doing it at the application level is problematic for many reasons. It's unreasonably complex, and does not play well with 0MQ sockets (many of which like PUB-SUB and PUSH-PULL are unable to do two-way negotiation). With CurveCP you can still use TLS for key exchange itself; what CurveCP provides is a highly robust answer for the actual connection: short term keys and nonces. It's new but so is Salt's crypto algorithm, which was not built to quite the same level of paranoia as CurveCP. We're still some time away from working code in libzmq and as much as a year or two from a crypto layer that's properly hardened. Having it in libzmq will mean it gets much more attention, which can only be good.
  - rumcajz 14y ago
    DTLS works only for payloads up to 16kB.
- ibotty 14y ago
  but how can a curvecp based protocol benefit from a tls over udp protocol?
b6 14y ago
Correction: D. J. Bernstein, DJB.
- jacques_chester 14y ago
  Oh jeeze, I'm embarrassed. :|
hintjens 14y ago
The Salt security layer is great, and I've worked with Thomas Hatch on abstracting it for wider use. We wrote this http://www.zeromq.org/topics:pubsub-security http://www.zeromq.org/topics:pubsub-security some time ago. While it's good, it has a number of weaknesses that CurveCP addresses, and which CurveZMQ includes. The parts of CurveCP that we don't implement are quite specifically to do with traffic control over UDP, name resolution, etc. and not security. The second problem with Salt's security is that it's not inside 0MQ but layered on top. This has a number of consequences such as interoperability and reusability. Our goal with CurveZMQ is to put this into the 0MQ kernel so it's available across all socket types. It will work over PUB-SUB as well as ROUTER-DEALER or PUSH-PULL. It will work over any intermediaries and since it's basically CurveCP, it will let you do things like migrate your clients (changing IP address) without re-establishing the secure session. CurveCP is really awesome and worth learning. It is really the security model we've been looking for for years, for ZeroMQ. The big difference between CurveZMQ and TLS is this: using TLS is complex. One of the visions of NaCl and thus CurveCP and CurveZMQ in turn is that simple is more secure than complex. Users can't make as many mistakes. CurveCP and CurveZMQ are simple. The current code for CurveZMQ is under 700 lines of C (assuming you have libsodium) and I didn't try to abstract any of the encryption calls; it's a flat implementation of the CurveCP handshake.
- jacques_chester 14y ago
  OK, TLS is complex. But a lot of that is due to its configurability. How would you have fared if you'd picked a simpler TLS library (PolarSSL, for example, is meant to be embedded) and then simply defined a single ZeroMQ configuration profile and said "that's it, that's all we're going to support"?
  - cbsmith 14y ago
    > OK, TLS is complex. But a lot of that is due to its configurability. ...and as many have noted, that configurability is the root of a lot of security problems. The pick one approach and say, "that's all we're going to do" might be one way to solve the problem. I'm not sure it'd be any better.
- 14y ago