[zeromq-dev] Curve question... changing keys after binding server socket...

Pieter Hintjens ph at imatix.com
Fri May 23 19:24:03 CEST 2014


You can IMO simply destroy the server socket, recreate it, set the new
key, rebind it, and continue.

On Thu, May 22, 2014 at 12:36 AM, Keith Henrickson
<Keith.Henrickson at nominum.com> wrote:
> Sorry, I was writing that and trying to get out of the office. Never a great combination.
>
> First, I think regularly rotating the long-term keys is dangerous for exactly the reasons you describe. However, when someone has a info sec policy that says, “All keys must be rotated every x months.”, there’s a limit to how much you can tell them, “This isn’t the solution you’re looking for.”
>
> Second, and this took me a while to understand, which shames me… Although the options are re-read on each connection, they’re stored on the own_t root object. Although passed in by reference, they’re stored as a regular member, and thus, a copy is created when an own_t derived type is instantiated. The connections therefore use the keys that are current at the time a tcp_listener_t is created. Once that’s created (looks like it’s done around the bind() time), it’s set in stone. Can we count on that behavior remaining the same in the future?
>
>
> On May 20, 2014, at 12:36 AM, Pieter Hintjens <ph at imatix.com> wrote:
>
>> First, long term keys are not meant to change, that's the whole point.
>> Distributing new keys is a complex and risky part of the process so
>> the only time you'd want to generate new long term keys is if the
>> server private key was compromised.
>>
>> Second, yes, it does (afaik) re-read the long term key before each
>> connection so you could change the LT key randomly. There's no sane
>> use case for this that I can see.
>>
>> Third, once a connection is established the LT keys aren't used again.
>> This is inherent in the CurveZMQ design. You could and would normally
>> force all connections to end, by restarting the server.
>>
>>
>> On Tue, May 20, 2014 at 2:44 AM, Keith Henrickson
>> <keith.henrickson at nominum.com> wrote:
>>> Presently once the server socket is bound, the keys can never change, as they’re not read from the socket options again.
>>>
>>> Not a bad idea, but I’m wondering if that would ever change? Would the server-side ever be changed to read the keys from the options upon each connection?
>>>
>>> If the server keys were allowed to change, what would happen to connections in progress? It looks to me like the long-term keys are not involved in the per-message crypto, so my guess would be that changing the server’s long-term secret would have no effect on connections that have already negotiated?
>>>
>>> _______________________________________________
>>> 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