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

[Laurent Alebarde]

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 <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
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

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