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

[Laurent Alebarde]

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 
> <mailto: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 <mailto: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 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/441a8840/attachment.htm>