Hi Jim, Indeed, [e]pgm doesn't fit into the neat world of CURVE as it sits today.
There are ways to get strong security though. Indeed you need to exchange keys out-of-band. I'd use a CURVE/TCP connection to authenticate clients and gain access to a group; then generate a keypair for each group on a rotating basis and distribute the public key via the secure unicast connection. Ideally this hybrid scheme would be written up as an RFC so people don't have to keep reinventing it, and we might even build support for it into OpenPGM. No reason it couldn't work with ZAP either. -Pieter On Mon, Mar 3, 2014 at 7:02 PM, Jim Garlick <garl...@llnl.gov> wrote: > Hi, > > I have a question about the new security model and epgm. > > I am pretty enthusiastic about the new ZAP design and the way > that CURVE was integrated. I'm not a security expert, but > the design seems quite clean to me, and I was able to quickly > incorporate CURVE in the prototype code I am working on. > > However, [e]pgm feels like a big loose end. Has any thought > been put into bootstrapping epgm security (privacy, authenticity) > by "external" means? For example, a distributed application could > generate a shared secret key, distribute it using CURVE protected > sockets, and then use use it for symmetric encryption over epgm? > > Maybe there are more obvious ways to extend the current security > model to cover epgm? > > I apologize if this has been discussed before. I didn't find anything > in my searches but I would be happy to be pointed to bugs/mail threads. > > Thanks, > > Jim Garlick > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
