Hi Pieter,
You are right. That makes sense. BTW, I suppose you wanted to write :
"it's wise that CurveZMQ track CurveCP as close as possible".
Cheers,
Laurent.
Le 18/08/2013 19:09, Pieter Hintjens a écrit :
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 <[email protected]> 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
[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
