[zeromq-dev] Custom authenticator

Pieter Hintjens ph at imatix.com
Sat Aug 9 23:49:21 CEST 2014


You can look at the test cases in libzmq to see examples of custom ZAP
handlers (CZMQ is only one option, you can indeed write your own
handlers).

As for signing keys... there's been a long thread on certificate
formats on this list, the upshot wasn't clear.

On Fri, Aug 8, 2014 at 10:44 PM, Charles West <crwest at ncsu.edu> wrote:
> Also, does anyone know of a good way to sign using CurveZMQ keys?  I could
> bind them to a second key (used for signing) using a permission signed by a
> certificate authority, but that seems clunky.
>
>
>
> On Fri, Aug 8, 2014 at 4:42 PM, Charles West <crwest at ncsu.edu> wrote:
>>
>> Hello,
>>
>> I've been digging into the spec for CurveZMQ as part of my efforts to
>> build a secure alternative to ROS.  I believe I have figured out what I need
>> to do for the next part, but I thought I should ask to see if I am on the
>> right track and see if there might be better ways that more experienced
>> people know of.
>>
>> I need to maintain an in-memory list of accepted keys for each socket and
>> have connections for each of those sockets accepted/rejected based on the
>> associated key stores.
>>
>> It looks like once security domains are implemented I will be able to make
>> something of this nature by creating a security domain for each socket and a
>> folder to maintain the allowed certificates for each domain.  In the mean
>> time, I could have a context for each socket and its own associated folder
>> (clunky, but works).  However, as this is suppose to be a background
>> library, it would be much better if it didn't need to have a folder with
>> write access to do its own book keeping.
>>
>> 27/ZAP - ZeroMQ Authentication Protocol and looking at the source for CZMQ
>> seems to indicate a better way.  If I am reading it correctly, ZeroMQ will
>> send any connection requests over to an inproc server with endpoint
>> "inproc://zeromq.zap.01".  This server is normally made automatically by
>> CZMQ calls, but it is not necessary that the library creates it.  Instead,
>> my code could bind the endpoint and implement its part of the 27/ZAP
>> protocol (the curve part, at least).  It can maintain its own list of keys
>> and implement the security domains to allow a unique in-memory store to be
>> kept for each object.
>>
>> If I may ask, does this last solution sound right?  Is there any better
>> way to do it?
>>
>> Thank you for your time,
>> Charlie West
>
>
>
> _______________________________________________
> 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