4 ms·

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

• 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.