You should not be changing public keys IMO. It is supported and documented and thus guaranteed, however I believe it's a misfeature that solves no real problem and rather, opens the door for confusion.
On Sun, Jan 18, 2015 at 8:05 PM, Andre Caron <[email protected]> wrote: > Yes, I understand the web of trust model. In my case, all (legitimate) nodes > are controlled by the same organization, so I can afford something akin to a > CA. My question stays, how could I adapt the Harmony pattern to use curve? > > And, back to my original question: can I assume that zmq-connect() takes a > snapshot of the current curve server key option and is not affected by > updating the option later on? It currently works, I'm just wondering if it's > guaranteed as it's not entirely clear from the docs. > > André > >> On Jan 18, 2015, at 1:57 PM, Benjamin <[email protected]> wrote: >> >> It's a very difficult and deep question, if you're building a true P2P >> network. If all peers are equal, nobody has some truth with regards to >> the identity of another peer. Say you have the following protocol: >> each peer starts announcing the identity of all known peers before >> exchange data. One peer Bob says that Alice's pubkey is 123, while >> another says its 456. Who is right? Maybe Bob is lying, or Bob is >> mistaken about Alice. >> >> The way cryptography works, is that there is an exchange of keys >> through a central system - the Public-key infrastructure (PKI). On a >> fundamental level PKI requires central key-exchange. It's an authority >> who declares that Alice is indeed Alice. On the Internet that >> authority is the Internet Corporation (or other central servers). >> Usually when people talk about cryptography they mean this kind of >> cryptography. >> >> An alternative framework is web-of-trust. Alice knows Bob and Bob >> knows Charlie, so Alice knows who Charlie is. The problem with this >> scheme is that each user, has to maintain a list of peer he trusts and >> peers can't talk to peers they did not know before. You can read more >> about WoT here: http://en.wikipedia.org/wiki/Web_of_trust >> >>> On Sun, Jan 18, 2015 at 7:43 PM, André Caron <[email protected]> >>> wrote: >>> I've looked at that already and still prefer the router-router setup and >>> have a convenient solution for discovery, which I'll get back to shortly. >>> >>> Obviously my immediate curve problem would be solved when using the Harmony >>> pattern because you always create a new dealer socket for each outbound >>> connection. However, it seems to me like this is a non-starter because the >>> Harmony pattern doesn't provide for secure exchange of public keys. How >>> would you prevent untrusted peers from connecting to your nodes? >>> >>> The problem I'm trying to solve is running an elastic group of nodes securly >>> over an untrusted network. My current solution is to use a directory >>> service which is known to all nodes prior to joining. This directory >>> service has a well-known endpoint, identity and public key. To add a new >>> node on the network, the administrator generates a new keypair, registers >>> the new public key with the directory service and then starts the new node, >>> which can then connect to the directory and discover other nodes. Since >>> each node has a secure connection with the directory, it can discover the >>> endpoint, identity and public key for each peer it wants to connect to. >>> Then, nodes can connect to each other using whatever protocol of their >>> choosing. >>> >>> The pros are that this solution is simple to configure and maintain and that >>> the directory is not a performance bottleneck. The cons are that it >>> requires a "central" directory service which is a potential security SPOF, >>> but that's perfectly acceptable to me for this problem. >>> >>> Maybe you have a better suggestion, but I don't see how I can do this with >>> the Harmony pattern. >>> >>> André >>> >>>> On Sun, Jan 18, 2015 at 1:17 PM, Pieter Hintjens <[email protected]> wrote: >>>> >>>> I'd recommend reading about the Harmony pattern in the Guide. >>>> Router-to-router topologies tend to be nasty. I don't use them, and >>>> don't recommend them. >>>> >>>> On Sun, Jan 18, 2015 at 5:57 PM, André Caron <[email protected]> >>>> wrote: >>>>> Hi all, >>>>> >>>>> I've been building an example of a router-router setup in which all >>>>> nodes >>>>> dynamically discover each other. This currently works like a charm. >>>>> Now, >>>>> I'm trying to add curve support for this application, which is proving a >>>>> bit >>>>> confusing despite the API's apparent simplicity. >>>>> >>>>> Basically, all my nodes have a single router socket which is used both >>>>> to >>>>> connect to other peers and to receive connections. However, I can't >>>>> seem to >>>>> do this when each peer has their own curve keypair. >>>>> >>>>> I have two problems: >>>>> - the same socket can not be a curve server and client at the same time >>>>> (so >>>>> I need at least both two sockets, one to connect and one to receive >>>>> connections); and >>>>> - a curve client can only set one server key so I cannot connect to >>>>> multiple >>>>> peers using a single router socket. >>>>> >>>>> The first problem I can live with -- have 2 sockets instead of 1 is not >>>>> a >>>>> major issue. However, the 2nd problem is really annoying. Creating a >>>>> new >>>>> socket for each logical outbound connection smes to me like an >>>>> anti-pattern >>>>> in ZeroMQ. >>>>> >>>>> So I'm wondering how I should handle this. >>>>> >>>>> I found this on the zmq_curve(7) man page: >>>>> >>>>>> A socket can change roles at any point by setting new options. The role >>>>>> affects all zmq_connect and zmq_bind calls that follow it. >>>>> >>>>> Is it safe to assume that I can simply set a new server key before each >>>>> zmq_connect()? >>>>> >>>>> Thanks, >>>>> >>>>> André >>>>> >>>>> _______________________________________________ >>>>> zeromq-dev mailing list >>>>> [email protected] >>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>>>> >>>> _______________________________________________ >>>> zeromq-dev mailing list >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
