[zeromq-dev] CurveZMQ comments

Trevor Perrin trevp at trevp.net
Wed Sep 25 01:04:36 CEST 2013


I read about CurveZMQ with some interest, some comments / Qs:

1) Since it's running over TCP (not UDP), are the "anti-amplication
padding" and "cookie" from CurveCP still needed?

2) Assuming the exchange of messages happens over an in-order
transport like TCP, would it be possible to "rekey" for forward
secrecy as messages are exchanged, so a key compromise at time T would
not affect earlier data?  (See discussion of such mechanisms here

3) If the client doesn't already have the server's public key, it
would presumably need to retrieve it, which would add a 3rd round-trip
to the CurveZMQ handshake before data could be sent, on top of the TCP
handshake.  That's a lot of latency, would you consider alternatives
 - Allowing the server's long-term key to be sent in the WELCOME command
 - Allowing sending of client data in the INITIATE command

4) While the modifications to the CurveCP key agreement seem to fix
the known security problems, the key agreement still seems a bit
complicated, and I'm not aware of any security proofs for it.

I've been advocating "triple diffie-hellman" in this scenario, as it's
simpler, more bandwidth-efficient, and has some formal security
analysis [2,3,4].  Adapted here, that might look like:

Client -> Server: C'
Client <- Server: S'
Client -> Server: Encrypt(k1, C) || Encrypt(k2, plaintext)

Client <-> Server: Encrypt(k2, plaintext)

  k1 = HASH(ECDH(C'S) || ECDH(C'S') || C' || S || S')
  k2 = HASH(ECDH(CS') || k1 || C || S')

Note that this is the same 3 ECDH operations performed by the modified
CurveZMQ, but the results are used in a simpler way (they are simply
hashed together, inside of used with a sequence of cryptoboxes).


[1] http://lists.randombit.net/pipermail/cryptography/2013-September/005328.html
[2] http://www.isg.rhul.ac.uk/~kp/ModularProofs.pdf
[3] https://whispersystems.org/blog/simplifying-otr-deniability/
[4] https://github.com/trevp/noise/wiki

More information about the zeromq-dev mailing list