I don't know CURVE well, but in general, key management is a hard problem. Usually encryption assumes keys have been pre-distributed "somehow," and they are almost never baked into an executable (that isn't secure).
Take ssh, for instance. The common use-case is to run ssh-keygen, and then put your public key "somehow" onto whatever server you want to log in to, while keeping your private key strictly off the network. The details of getting your public key onto the server are an exercise for the reader, and it's likely the same with this. On Wed, Apr 2, 2014 at 7:50 PM, Steve Murphy <[email protected]> wrote: > OK, I've read the man pages for zcert, zcertstore, and zauth. > I've read the tutorial about the wood, stone, and iron houses. > I've compiled those examples, and run them, shoot, I even > wiresharked the ports and captured the conversations to see > the unencrypted vs. encryped communication. Cool. > > But now, it's time to actually write up some code and use this > stuff in a real set of distributed applications, and I find the > docs very frustrating. > > Firstly, little to no explanation in zauth about curve parameters > "domain" and "location", and how to use them. > > Nextly, zcert gives us zcert_new_from(..) which takes byte* args, > but no zcert_new_from_txt(...) with char* args. > > The zcertstore manpage says "To actually create certificates on disk, > use the zcert_class in code, or the tools/makecert.c command line > tool, or any text editor." That's nice, but the only tool in zeromq-4.0.x > is tools/curve_keygen, and it doesn't create a file, > it just prints out the keys with some explanatory text, not even > in cert file format. > > The zmq_curve_keypair example code shows a call to "crypto_box_keypair" > instead of zmq_curve_keypair, which I assume is > a typo, probably left over from "legacy" versions of the > document prototype. > > All the examples use zcert_new(), and provide public keys up front > to the clients, with > no examples of actually doing a certificate store of just public > keys, and no in-program storage of secret keys. It's almost as if one > is forced to create and distribute secret key files. (there's load > and save options in czmq). > > Let's say I want to store all my public keys in /etc/something/store. > I can distribute that pretty easily to hundreds of machines. > I want to compile a secret key into my servers and clients, for their > respective usage. Clients can fetch the public keys from the disk > store dir. So can the servers. But, the feeling I get from actually > looking over the API's, is that the above is not the intended > usage case. There are no public functions to convert to/from binary > and string key representations. Well, OK, that's entirely fair, > therre is zmq_z85_decode and encode, but I have to wrap that > in a fair amount of code to yield something like > byte secret_key[] = { 0xaf, 0x39, 0x45, 0xc3, .... }; > that I could compile into a program... if that is even the intended > best way to handle keys (shrug). > > Don't get me wrong. I realize this stuff is brand-spanking-shiny-new > and hot-off-the-press, and usage cases are in their infancy. I'd just > like to NOT charge off in a wildly different direction than what you > guys envision, and be left with code I may have to rewrite someday. > > Please, can someone with a higher level view give me some idea of how > I best attack this situation? What's the best way to use this in > production environments, where the server and client are not in the same > executable? > > Pieter, up to writing a "part 3" tutorial outlining separate > servers and clients, using disked public keys, etc? > > One or two variants of suggested "best practice" for clients and > servers will answer all my questions and get me up and running full > speed! > > Many thanks! > > murf > > > -- > > Steve Murphy > ParseTree Corporation > 57 Lane 17 > Cody, WY 82414 > ✉ murf at parsetree dot com > ☎ 307-899-5535 > > > > _______________________________________________ > 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
