Compiling keys into the binaries and then distributing them securely is no different than distributing certificates, isn't it?
CURVE lets you use the same client key as often as you like, so you could work with one secure client certificate (secret+public keys), and a server public key known to all clients. On Fri, Apr 4, 2014 at 7:12 PM, Jim Garlick <[email protected]> wrote: > On Thu, Apr 03, 2014 at 01:28:27PM -0600, Steve Murphy wrote: >> Pieter, Laurent, Lindley-- >> >> Many thanks for the responses. >> >> Laurent's mention of secure public key exchange got me thinking. >> >> === A Quick Trip to a Perfect World? >> >> As to the global, high-level view of this curve stuff, >> >> What If: >> >> A. Every Server and Every Client creates a brand-new, fresh zcert for >> itself in memory. >> Between the server and its clients, all they need is each other's public >> keys, and they can communicate securely. >> B. Before connect time, we still "apply" the zcert to socket. Now, the >> socket has both >> public and private keys for our side of the secure connection. >> C. At connection time, the underlying socket mechanisms should go ahead and >> use the >> Diffie-Hellman-Merkle-whoever Algorithm so the server can securely pass >> its public key to the >> client sockets, and each client can pass its public key to the server >> socket. > > Does your perfect world include magical public key certification elves? :-) > Protecting public keys with DH doesn't buy you anything here as you still > don't know who you're talking to, and the private keys aren't disclosed. > > If you want to get encryption bootstrapped without authentication, perhaps > you could pre-share a single long-term public,private keypair? > I think even publishing that keypair or say compiling it into your > application would be no less secure than what you've proposed, since > unique session keys for each connection are generated from the long-term > initial keys by CurveZMQ/ZMTP. If you wanted to prevent ousiders from > joining, then don't disclose this keypair to them. > > Jim > _______________________________________________ > 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
