[zeromq-dev] Is there a reasonable way to use an existing PKI and D/TLS with 0MQ?

Wed Feb 14 10:05:32 CET 2018

Hi John,

One cool thing about Curve25519 is that, given the secret key, the public key can be derived from it. And it seems that you actually you can use random bytes for the secret key (almost). Only a few bits in the first and last byte are fixed. Here an excerpt from [1]:

> Computing secret keys. Inside your program, to generate a 32-byte Curve25519 secret key, start by generating 32 secret random bytes from a cryptographically safe source: mysecret[0], mysecret[1], ..., mysecret[31]. Then do
> 
>      mysecret[0] &= 248;
>      mysecret[31] &= 127;
>      mysecret[31] |= 64;
> 
> to create a 32-byte Curve25519 secret key mysecret[0], mysecret[1], ..., mysecret[31].

Of course the conversion tool would have to print the public key so you can collect those centrally.

Yes, it might be too much effort if you want to keep using the existing PKI as-is. Having used ZMQ for a while now, I'd say it's worth the effort! ;-)

Regards,
Patrik

[1] https://cr.yp.to/ecdh.html

> On 14 Feb 2018, at 08:32, John Lane Schultz <jschultz at spreadconcepts.com> wrote:
> 
> Hi Patrik,
> 
> I’m not terribly familiar with the details of elliptic curve cryptography myself.
> 
> Even so, there must be a strong EC relationship (inversion?) between the public and private parts of each key pair, just like there is for RSA key pairs.  I highly doubt that simply using a random-ish transform of RSA parameters will yield proper ECC key pairs.
> 
> I probably could automate the creation of a parallel PKI system, but then it would need to be mapped to, maintained, watered, and fed alongside our X509 / CA PKI infrastructure.  I doubt I want to take on that burden simply to reduce my socket programming pains.
> 
> Thanks,
> John
> 
> On Feb 13, 2018, at 8:06 PM, Patrik VV. <paddor at gmail.com> wrote:
> 
> Hi
> 
> WARNING: I’m no infosec expert.
> 
> I’m just thinking out loud, so please bear with me. To my understanding, the keys used by the crypto primitives (NaCl/TweetNaCl) used in CurveZMQ are just 32 secret bytes. You already have about 2000 secrets for those 2000 identities, their current format just isn’t usable. Can’t you just convert those secrets to 32 secret bytes each using a cryptographically secure hash function? Of course it should be a hash function that gives you a hash of 32 bytes or more to avoid losing entropy.
> 
> I’m sure you could automate this process and store the converted identities as zcerts using CZMQ. See [1]
> 
> Regards,
> Patrik
> 
> [1] http://czmq.zeromq.org/czmq-master:zcert
> 
> On 13 Feb 2018, at 23:42, Luca Boccassi <luca.boccassi at gmail.com> wrote:
> 
>> On Tue, 2018-02-13 at 17:03 -0500, John Lane Schultz wrote:
>>> I’m new to 0MQ, so please excuse my ignorance about it.  I read the
>>> guide book, the blog entries on CurveZMQ, looked at the directory of
>>> 0MQ GitHub repositories, and googled around to see if anyone had
>>> added a D/TLS layer into 0MQ. I didn’t find much of anything.
>>> 
>>> I did find the email below from 4 years ago, that seems to answer a
>>> similar question from back then.  Is it still the situation that 0MQ
>>> doesn’t readily support using D/TLS to secure its communications?
>>> 
>>> I ask because we have an existing PKI managing more than 2000
>>> distributed identities and we use D/TLS to secure our mutually
>>> authenticated (the “Ironhouse Pattern") point-to-point
>>> communications.  If it matters, we use Ephemeral Diffie-Hellman key
>>> exchanges with long term RSA keys.
>>> 
>>> From my reading, 0MQ looks really appealing to get away from low-
>>> level programming OpenSSL D/TLS, UDP, and TCP sockets, but not being
>>> able to use our existing security infrastructure would probably be a
>>> deal breaker.
>>> 
>>> I’d greatly appreciate any information on the current state of
>>> affairs of 0MQ security layers and whether or not adding D/TLS
>>> support to 0MQ is reasonable or not.
>>> 
>>> Thanks!
>>> John
>> 
>> Hi,
>> 
>> The situation is the same - security is only supported through Curve or
>> Kerberos.
>> 
>> Not for any particular reason if not that nobody has contributed any
>> other implementation. This is probably due to the fact that SSL is
>> awfully, awfully complex (but I understand your requirements.
>> 
>>> From ph at imatix.com  Fri Oct  4 00:46:06 2013
>>> From: ph at imatix.com (Pieter Hintjens)
>>> Date: Fri, 4 Oct 2013 00:46:06 +0200
>>> Subject: [zeromq-dev] Using other kinds of certificates with CurveZMQ
>>> In-Reply-To: <F321E1DDD74B4747BE218256F9B069F313064041 at GQ1-EX10-MB05.
>>> y.corp.yahoo.com>
>>> References: <F321E1DDD74B4747BE218256F9B069F313064041 at GQ1-EX10-MB05.y
>>> .corp.yahoo.com>
>>> Message-ID: <CADL5_shGNyOg8=NBsQW7eOBnu4qsKD_1pVWXp4PJda3MJePtpg at mail
>>> .gmail.com>
>>> 
>>> On Fri, Oct 4, 2013 at 12:34 AM, Steve Carney <carney at yahoo-
>>> inc.com> wrote:
>>> 
>>>> I have an infrastructure with existing certificates that is not
>>>> ready to
>>>> move to CurveCP yet.    Does CurveZMQ have an underlying framework
>>>> (due
>>>> using SASL) that I could use to implement SSL authentication (with
>>>> and
>>>> without encryption)?
>>> 
>>> No, CurveZMQ has its own properties. I've described this
>>> superficially
>>> here: http://hintjens.com/blog:48
>>> 
>>>> I also have simple proprietary certificates that I?d like to
>>>> support as part
>>>> of establishing a client-server connection.  A simple cleartext key
>>>> exchange
>>>> would be sufficient.  Could CurveZMQ be leveraged for this as well?
>>> 
>>> Not directly... The keys that CurveZMQ uses are specific to the
>>> elliptic curve cryptography used.  However you could use your
>>> existing
>>> certificates and some (non-ZeroMQ) transport to exchange CurveZMQ
>>> certificates.
>>> 
>>> -Pieter
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
>> -- 
>> Kind regards,
>> Luca Boccassi
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev