Does Pyre support CurveZMQ?

[Cgettys]

Does Pyre support CurveZMQ?

[sphaero]

Never tried it but if pyzmq does it would be possible

On June 16, 2016 7:04:58 PM GMT+02:00, Charlie Gettys notifications@github.com wrote:

Does Pyre support CurveZMQ?

---

You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/zeromq/pyre/issues/94

Sent from my Hipster Android device with way too many features.

[Cgettys]

I've been digging into how it works; the answer is no, but it should be possible to add it (and I may well do so, we'll see) CurveZMQ is implemented in pyzmq, but is at the socket level, and Pyre does not expose the incoming socket. That being said, it shouldn't be too bad to add some arguments which get passed through Pyre ,Pyre-Node, ZActor, etc, in order to configure the socket. Thoughts?

[wesyoung]

i was kinda thinking about it the same way. started by passing --interface down through (still doing some internal testing) to enable re-wiring the interface that it listens on (seems to work OK), was thinking same kinda thing for curve, but prob needs more though since you can do diff auth stuff with curve....

there was some "set_interface" functions that weren't all the way implemented, so wasn't sure if passing args down through actor was the "correct" way, just haven't had a chance to think through it other than passing args down through actor...

[Cgettys]

Another way to attack it might be to create the socket, but not bind until after the start command is called, and expose the socket via a method. That'd require some reworking because of the threading I think.

I also tried setting the default sockopts on the context to what they would need to be, but for some reason that had no effect. I do not know if that is a bug or me misusing sockopts.

[Cgettys]

May be more complicated than just passing arguments down and interpreting them; I'm running into issues figuring out how to deal with the security protocols which seem? to be asymmetric.

[wesyoung]

just so we're "speaking the same language" have you seen:

https://github.com/zeromq/pyzmq/tree/master/examples/security

and thought about this using something like an authenticator thread and passing that around teh context? (or am i interpreting how you wanna implement security?)

i've only been just starting to think how to do this; first getting something TLS style between the peers and dealing with auth on top of that. outside of digesting the pyre code and reading through the examples/security starting to put the pieces together. you might be a-head of me here.. (thinking out-loud).

[Cgettys]

I saw that; it could be I'm thinking about it wrong. I'll put up my code a bit later; my first attempt was just to setup the socket with keys. But when I looked into ZAP (specifically curveZMQ) it seems (though I may be wrong) that one socket must be designated as client and the other as server. Unless I misunderstand how pyre is working, it uses one Socket instance for both sending and receiving, so I don't see how to get an arbitrary number of nodes to use curveZMQ

[Cgettys]

See http://hintjens.com/blog:36

[wesyoung]

iirc; look for inbox/outbox https://github.com/zeromq/pyre/blob/master/pyre/pyre_node.py (i'll try to throw up my interface diff sometime this week too... sounds like we're both barking up the same tree).

[Cgettys]

I've been looking at ZRE a bit more: the key will be in both the dealer sockets and the router sockets I think

[Cgettys]

To correct my previous comment, Zyre is using two ports; all dealers should be "servers" and all routers should be "clients" or vs versa, removing the problem of asymmetry. The dealer sockets just have to be set up appropriately for their individual router.

[hintjens]

It's probably not that complex to add curve security. Indeed, set up each router socket as 'server' and dealer as 'client', and extend the API to provide a server and a client key to a node. Then, you need an authenticator that accepts ZAP requests and validates them, checking client keys. You can use the CZMQ zauth class as a model.

OK, not trivial, yet quite doable IMO.

On Mon, Jun 20, 2016 at 9:18 PM, Charlie Gettys notifications@github.com wrote:

To correct my previous comment, Zyre is using two ports; all dealers should be "servers" and all routers should be "clients" or vs versa, removing the problem of asymmetry. The dealer sockets just have to be set up appropriately for their individual router.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zeromq/pyre/issues/94#issuecomment-227241393, or mute the thread https://github.com/notifications/unsubscribe/AASzCJkMDKbOTaI2D4P173fuWvBqXI0sks5qNudugaJpZM4I3mW5 .

[wesyoung]

Only because of you ;) ty sir!

[Cgettys]

Yes, thanks for all of your great work. I am so glad not to have to touch TCP and UDP sockets anymore! Also, your guide on ZeroMQ blew my mind and changed how I think about networking. I'm planning to buy your books soon! To return to the technical discussion, I think we may even be able to reuse the existing zauth class as a whole, and do the key assignment in PyreNode or something; I'm still thinking this through though. It may make more sense to modify the zauth class instead; either way, it'll be doable.

[Cgettys]

@sphaero or @wesyoung perhaps this should be tagged enhancement or similar?

[Cgettys]

I have got things to the point where I can encrypt the data for the entire system using a set of keys. However, I haven't tried to extend this to keys for each group, which strikes me as the logical next step; this may require some rewriting of the zsocket class. Also, currently all nodes are using the same set of keys, which is poor security; I should try to figure out a way to make the keys per node, while retaining the group-based security feature. One way I can think of to do this is simply to have a list of allowed public keys for each group; one would have to add a frame or piece of the frame telling the other node your public key, or the receiving node will have to try all of the allowed public keys.

[wesyoung]

re: passing args down through the stack, i'm not sure this is the "correct" way to do this, but it was a prototype, fwiw:

https://github.com/zeromq/pyre/compare/master...wesyoung:fix/interface?expand=1

do you have a fork/diff somewhere of what you're modeling?