[zeromq-dev] About CURVE and ROUTER sockets

Andre Caron andre.l.caron at gmail.com
Sun Jan 18 20:05:27 CET 2015

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.


> On Jan 18, 2015, at 1:57 PM, Benjamin <benjamin.l.cordes at gmail.com> 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 <andre.l.caron at gmail.com> 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 <ph at imatix.com> 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 <andre.l.caron at gmail.com>
>>> 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
>>>> zeromq-dev at lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list