[hintjens]

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

[aktau]

I've got an application in the pipeline that is meant to go live in 1-2 months. Does this mean that I can build it now and when the time comes I can pre-share the keys and activate CurveZMQ so I can safely traverse the hostile waters of the internet? That would be absolutely awesome. And it would be the difference between CurveZMQ and the Salt stack model (which I also looked at and quite liked actually, because it sounds simple). I realize that I'm not a cryptographer and should not be making these decisions, so the premise of CurveCP sounds awesome, I'd rather place my trust in DJB than myself.

On another note, the comments about the flaws of the Salt model on http://www.zeromq.org/topics:pubsub-security do worry me, although they seem fixable. Have you or the Salt guys thought about that?

[jacques_chester]

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]

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