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

Mon Aug 19 02:35:37 CEST 2013

Hi Laurent,

No problem with taking the security concerns to CurveCP. I just want to
note that the 'MAY' part of authenticating C indicates a per application
decision. Some applications - like yours - require authentication of
clients, others do not (e.g. an anonymous, but securely encrypted
fileserver may not wish to authenticate C). It is up to the app. I agree IP
address is not appropriate authentication.

I haven't looked at the CurveZMQ implementation yet, but as a guess this
authentication would be implemented by a callback/handler.

Luke

On Mon, Aug 19, 2013 at 9:08 AM, Laurent Alebarde <l.alebarde at free.fr>wrote:

>  Hi Luke,
>
> Thank you very much for your remarks. Some comments below. As Pieter
> rightly suggested it, let's go on with the CurveCP mailing list as of now.
>
> Cheers,
>
>
> Laurent.
>
>
> Le 18/08/2013 23:43, Lucas Hope a écrit :
>
>  Hi Laurent,
>
> I had a think about this, and there are a couple of issues with the logic.
> If there is a vulnerability where you suggest, then that vulnerability
> would render the whole encryption scheme useless. I guess what I‘m saying
> is that you’ve found an incredibly huge leak, or it isn‘t a leak at all.
>
> Sure, but I prefer raising naively the question.
>
>   Here’s some points.
>
>    -
>
>    The server *does not* know C a priori. C is actually an important
>    secret - we don't want attackers to know who exactly is communicating with
>    S. The spec says that S *MAY* authenticate C, but it doesn‘t have to.
>    And the client may choose to generate an anonymous throwaway ’long term' C.
>
>   In my use case, it is desirable that the client is authenticated by the
> server. And I have understood that CurveCP enables that. Besides, they
> consider an IP is a very bad authentication method.
>
>
>    -
>
>    Having a known signature is important, as it validates the client's
>    implementation of the algorithm. A random key is not something the server
>    can validate against. That validation assures the client is saying what
>    they mean to say.
>
>   It could be made later in the protocol I think, especially with the
> same keys than the ones used for messages.
>
>
>    -
>
>    If the attack you suggest is feasible, then it is probably trivial to
>    determine the server‘s private key in exactly the same way. After all, the
>    message is encrypted using a joint shared secret computed from either (c’,
>    S) or (s, C') - as described in that excellent PDF you shared.
>
>   I agree.
>
>
>    -
>
>    Even if the signature was changed to something random, the attacker
>    can just connect to the server with their own c‘/C’, and they‘ll be able to
>    craft whatever ’random' string they like to best attack the server -
>    including the current case of all zeros.
>
>   That would implies other modifications of the protocol.
>
>
>    -
>
>    The above two points mean that the vulnerability you describe would be
>    more devastating (you steal the server's long term private key!), and nis
>    ot actually protected by the randomized signature. I think thus that the
>    protocol is well protected if the designer is at all worth their salt.
>
>   That's a proof by absurd, and you are certainly right.
>
>
>    -
>
>    (I agree the spec should always put private keys in lower case, it is
>    confusing when you're new to the spec).
>
> Just some points which may be wrong. IANAC (I am not a cryptographer :-) ).
>
> Luke
>
> On Sun, Aug 18, 2013 at 8: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
>>
>>   --
> ---------------------------------------------------
> Dr Lucas Hope - lucas.r.hope at skype
> Machine Learning and Software Engineering Consultant
> Melbourne, Australia
>
>
> _______________________________________________
> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://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
>
>

-- 
---------------------------------------------------
Dr Lucas Hope - lucas.r.hope at skype
Machine Learning and Software Engineering Consultant
Melbourne, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130819/43dca414/attachment.htm>