libcurve icon indicating copy to clipboard operation
libcurve copied to clipboard

Bob And Alice

Open voznesenskym opened this issue 10 years ago • 3 comments
trafficstars

A bit long winded, but I am at a roadblock.

First of all, thank you so much for this library/project. Internet security, privacy, and end-to-end encryption has never been more important. To cut to the chase:

I am modifying the curve_server.c to my needs. Currently, I have left the recv portion of the code alone, for the most part, except instead of relying on decrementing the test clients, I have changed it to a while(true) to allow it to persist:

...
while (true) {
        printf("recv \n");
        zmsg_t *msg = curve_server_recv (server);
        if (memcmp (zframe_data (zmsg_last (msg)), "END", 3) == 0)
            live_clients--;
        curve_server_send (server, &msg);
    }
...

Currently, on my client side, I am supplying this:

...
client = curve_client_new(&client_cert);
        curve_client_set_metadata (client, (char *)"Client", (char *)"CURVEZMQ/curve_client");
        curve_client_set_metadata (client, (char *)"Identity", (char *)"E475DA11");
        curve_client_set_verbose (client, true);
        curve_client_connect (client, (char *)"tcp://redacted:9000", zcert_public_key (server_cert));
...

And I know it connects, because the log output is:

Received C:HELLO
Received C:INITIATE
ZAUTH I: ALLOWED (CURVE) client_key=XiI!mAM>RoWle35!v@wqhxNaf?93}2Ks@@LA#lrM

Now, the pattern I want to support is as such:

  1. Bob connects (on IP example.0.0.1)
  2. Server gets connection from example.0.0.1, and reads identity, stores Bob in a hashtable with Identity and IP
  3. Alice connects (on IP example.0.0.2)
  4. Server gets connection from example.0.0.2, and reads identity, stores Alice in a hashtable with Identity and IP
  5. Bob sends message To Alice
  6. Server parses Bob's message target, pulls Alice from the Hashtable, and passes the message onto her.

Currently, this leads me to the following questions:

  1. I know how to get the IP from Bob connecting, but how do I get the Identity ("Bob") and other metadata ?
  2. How do I set data in Bob's message to allow the server to know to route it to Bob?

Thank you so much for your help! I look forward to contributing to this project once I get these basics out of the way.

voznesenskym avatar Jan 17 '15 08:01 voznesenskym

With libcurve, there's no authenticated metadata sent at the connection level. You can send this yourself in a first message. Dealing with messages at the application level is a whole science. There's good practice in stacks like Zyre, FileMQ, zproto, etc.

libcurve is for end-to-end security across untrusted middle points. If you have A-B without a central broker then you can use libzmq's CURVE mechanism, it is rather simpler to use and works with all socket types.

hintjens avatar Jan 17 '15 12:01 hintjens

So the examples in curve_codec where the metadata is read from the client, is that not true end to end security? Also, what is the difference r between libcurve and libzmq with the curve mechanism?

So I read the book almost cover to cover, and there's still a few questions I seem to have not been able to answer. For the case of a direct message router using zeromq and its related stacks, what is the best way to achieve a A-B message with end to end encryption? Both in terms of pattern and exact library stack. I was hoping for eventually following a majordomo pattern on pure libcurve but as you can see, I seem to have run into a few misunderstandings.

Thank you very much for your help.

voznesenskym avatar Jan 17 '15 20:01 voznesenskym

Doing end-to-end encryption across brokers is really quite hard. You can of course encrypt and decrypt at either side, that's fine. The hard part is creating a session key, which needs 2-way dialog. That can of course happen over untrusted fabric. However you have to have A and B talking, two-way, before any encrypted traffic can flow from A to B, either way.

This excludes any kind of abstract routing, e.g. Majordomo, unless you add a protocol phase (in MDP) where clients and workers can explicitly handshake to carry the curve security commands both ways.

If you read the curvezmq spec you'll see what I mean, I think.

I might make an example of end-to-end encryption over a broker at some stage. There is definitely a pattern for it, I just haven't worked through it yet.

-Pieter

On Sat, Jan 17, 2015 at 9:13 PM, voznesenskym [email protected] wrote:

So the examples in curve_codec where the metadata is read from the client, is that not true end to end security? Also, what is the difference r between libcurve and libzmq with the curve mechanism?

So I read the book almost cover to cover, and there's still a few questions I seem to have not been able to answer. For the case of a direct message router using zeromq and its related stacks, what is the best way to achieve a A-B message with end to end encryption? Both in terms of pattern and exact library stack. I was hoping for eventually following a majordomo pattern on pure libcurve but as you can see, I seem to have run into a few misunderstandings.

Thank you very much for your help.

— Reply to this email directly or view it on GitHub https://github.com/zeromq/libcurve/issues/24#issuecomment-70382450.

hintjens avatar Jan 17 '15 20:01 hintjens