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 <[email protected]>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 <[email protected]> > 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 >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> -- > --------------------------------------------------- > Dr Lucas Hope - lucas.r.hope@skype > Machine Learning and Software Engineering Consultant > Melbourne, Australia > > > _______________________________________________ > zeromq-dev mailing > [email protected]http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > -- --------------------------------------------------- Dr Lucas Hope - lucas.r.hope@skype Machine Learning and Software Engineering Consultant Melbourne, Australia
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
