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]
<mailto:[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] <mailto:[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
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
