"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 <[email protected]
<mailto:[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 <tel:307-899-5535>
_______________________________________________
zeromq-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
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
