I personally would _strongly_ recommend against sharing keypairs across machines. Keypairs are not designed for encrypted communication, they are actually designed for providing identification and non-repudiation based on the assumption that only one entity knows the private key. How can Alice, Bob and Charlie ever trust each other if they don't even know who the other is? If Alice ever does want to talk to Bob in private, or if Charlie ever needs to prove his identity to the others, then they must not share their private key.
There are other ways to securely communicate machines without sharing keys using well established protocols. Use pub/priv keypairs to derive a shared key and then use a much more efficient manner of encryption (symmetric crypto such as AES) to actually encrypt the communication. These protocols are actually pretty easy to implement. Take a look at ECDH (Elliptic Crypto Diffie Hellman - https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman) on how to derive a shared secret key based on each party's own public key. They also have ECDSA (Elliptic Curve Digital Signature Algorithm - https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) which is a way to validate an entity's identity. ECDSA establishes the "trust" you mentioned before between Alice, Bob and Charlie. Here's a nice javascript library I've used in the past with nice simple examples: https://github.com/indutny/elliptic. Hope this helps! On Fri, Dec 15, 2017 at 7:01 AM, Luca Boccassi <[email protected]> wrote: > On Thu, 2017-12-14 at 15:50 -0500, Kent Borg wrote: > > Question: Is it okay for Alice and Bob to communicate with each > > other > > using a single shared public/private elliptic key pair? > > Experimentally > > it seems to work, but does it introduce any security holes? (Beyond > > the > > obvious that keys can't be individually deployed and revoked when > > they > > are not individually issued.) > > > > Motivation: Alice and Bob are in the same household, they trust each > > other. They are, um, liberal, Charlie might be joining, too, they > > will > > trust him, too. When he does join they would rather not do a bunch > > of > > two-way key distribution. Also, there might be more than one instance > > of > > Alice (and of Bob and Charlie), and the Alices (and Bobs and > > Charlies) > > want to be able to talk to among themselves. They are willing to > > rekey > > the entire household if need be. And if later they need more > > resolution > > of who trusts whom they can start issuing some unique keys then. But > > in > > the meantime, does sharing keys open up any vulnerabilities? > > > > Thanks, > > > > -kb > > Premise: I am not a security expert. > > Using the same key pair for both endpoints should be the equivalent of > using a pre-shared key, so per-se it shouldn't have any consequences. > > Apart from the obvious ones with deployment, double exposure of the > private key (one machine gets compromised == all machines are > compromised) and so on, which you already identified. > > -- > Kind regards, > Luca Boccassi > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > > -- Chad Cravens +1 (800) 214-9146 x700 [email protected] http://www.ossys.com [image: Open Source Systems] <https://www.ossys.com> [image: LinkedIn] <https://www.linkedin.com/company/open-source-systems-llc> [image: Facebook] <https://www.facebook.com/OpenSrcSys> [image: Twitter] <https://www.twitter.com/OpenSrcSys> [image: YouTube] <https://www.youtube.com/OpenSrcSys> [image: Instagram] <https://www.instagram.com/OpenSrcSys> [image: RSS Feed] <http://www.ossys.com/feed>
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
