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

[Lucas Hope]

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.
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.
    -

   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.
    -

   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.
    -

   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.
    -

   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.
    -

   (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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130819/6945081e/attachment.htm>