[zeromq-dev] CurveZMQ - RFC26 : possible Hello weaknesses ?

[Pieter Hintjens]

Laurent,

I think it's wise that CurveZMQ track CurveCP as far as possible,
changing only when it's clearly appropriate to the TCP transport
(CurveCP being designed for UDP). This means any weakness in CurveZMQ
should be matched by CurveCP, and the discussion can be done there.

Would you raise this on the CurveCP mailing list? I'm sure DJB will
enjoy the feedback.

-Pieter

On Sun, Aug 18, 2013 at 12:31 PM, Laurent Alebarde <l.alebarde at free.fr> wrote:
> Hi all,
>
> Studying CurveZMQ, CurveCP, libsodium and NaCl, I find it good to discuss
> possible weaknesses on the protocol, especially the Hello packet :
>
> Notation, I use the modified notation (C',0,Box[0'](c'->S)) instead of
> (C',0,Box[0'](C'->S)) from the original (http://curvecp.org/packets.html)
> since it is more clear onto what is performed : encryption with server
> public key and authentication with client short term secret key.
>
> Problem :
> C' is sent in the clear in (C',0,Box[0'](c'->S)) . In theory, it is not a
> problem as it is the base of asymmetric encryption. But here, the content of
> the box is all zeros, meaning a clear text attack can be performed to have
> information on (c', S). As S is public, we have leaks on c'. I don't know
> how far thought. As it is a short term key, it may  not be a problem. Who
> knows ? I am not a cryptography expert but I know that avoiding leaks is
> good.
>
> Solutions :
>   1) Fill the box with random data. From the CurveCP spec, "Current servers
> enforce the 64-byte length requirement but do not enforce the all-zero
> requirement" (http://curvecp.org/packets.html), and "They are also an
> extension mechanism". As CurveZMQ embeds a version of the protocol, this is
> pointless, and we can feel the box with random data. Then, we avoid any leak
> on c'.
>   2) Why doing the minimum when we can do the maximum for free ? It would be
> nice to put C' in the box and use c instead of c' to sign it. C is already
> known by the server.
> So, the final proposition is to replace (C',0,Box[0'](c'->S))  with
> (F',0,Box[C',R'](c->S)) or (Box[C',R'](c->S)) or (Box[C'](c->S)), F' being a
> fake key and R' random data. C' staying secret prevents any attack on c. For
> future extension, half of the box (R') should be enough.
> Remark : If the client is an enemy with wrong c, the server gets the enemy
> C' but cannot tell if it is friend or foe.
>
> There might be implications on the next packets. But I would like your
> remarks at this stage first.
>
>
> Cheers,
>
>
> Laurent.
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>