[zeromq-dev] CurveZMQ comments

[Trevor Perrin]

Hi,

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
[1]).

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
like:
 - 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).


Trevor


[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