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

[Laurent Alebarde]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130818/ae5276fc/attachment.htm>