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
