[zeromq-dev] "real" usage of curve algorithms with zeromq?

[Laurent Alebarde]

"keys have been pre-distributed "somehow"" may be performed with use of 
the Diffie--Hellman key exchange algorithm: 
http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange


Le 03/04/2014 10:23, Lindley French a écrit :
> 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 <murf at parsetree.com 
> <mailto:murf at parsetree.com>> 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 <tel:307-899-5535>
>
>
>
>     _______________________________________________
>     zeromq-dev mailing list
>     zeromq-dev at lists.zeromq.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140403/c714f8e1/attachment.htm>