[zeromq-dev] CurveZMQ availability plan ?

[Laurent Alebarde]

Thanks a lot Pieter. Please, I have some remarks and questions below.

Cheers,

Laurent.


Le 07/08/2013 20:06, Pieter Hintjens a écrit :
> On Wed, Aug 7, 2013 at 4:15 PM, Laurent Alebarde <l.alebarde at free.fr> wrote:
>
>> Which RFC is implemented (26) ? Partially or totally ?
> * RFC 23, except commands.
> * RFC 24, 25, 26, 27, 28, 29, 30, 31, and 32 fully.
Great. In "https://github.com/zeromq/curvezmq/blob/master/README.txt", 
it is said : "CurveZMQ implements the rfc.zeromq.org/spec:26 elliptic 
curve security mechanism". I assumed this should be corrected ?
>
>> Do we have both sides authentication today or not ?
> Yes, client always authenticates server by setting socket option, and
> server optionally authenticates clients by using ZAP plugin.
If I try to translate RFC26 § "Overall Operation of CurveZMQ", with 
S{C'} being for example the public short term key of the client crypted 
with the public long term key of the server :

Client                                             Server
------                                             ----------
Knows S                                         Knows C
Generates short term keys C'/c'
HELLO    ------------------ S{C'} or C' ? 
---------------------------------------->    s{S{C'}} = C' (decodage)
                                               Generates short term keys 
S'/s'
c'{C'{S'}} = S'    <------------------------    cookie ? + C'{S'}    
--------------    WELCOME
Server is authenticated from the cookie ?                       Deletes 
S'/s' ?
INITIATE    ---------------    cookie ? + S'(C) 
---------------------------------->   check cookie ?
                                               s'{S'(C)} = C, compared 
to known C
                                               Client is authenticated
<------------------------------------------------------------------------- 
     READY

Question 1 : The server is authenticated by the client when it receives 
the WELCOME command (RFC26), if and only if C' was encoded with S in the 
HELLO command. Then, only the right server which has s can know C', but 
this works only if the cookie is data known by the Client and encoded 
with C'. So the cookie should be f(C, C') like C'{C}? Is it what means 
"and encodes this new private key in a "cookie"" and "the client long 
term key is not sent in clear-text" ?

Question 2 : From the "High-level Grammar", C' is sent in clear in the 
HELLO command. This seems enough from the point of view that "if the 
public client key is stolen, nothing can be done with it if the private 
key is not stolen also". But why send it in clear when it can be crypted 
? If many S{C'} are stolen, it does not breach S since the C' are 
unknown from the attacker. Using S{C'} in the HELLO looks like a better 
server authentication from the client since it guarranties also that the 
server has s (not only knows C).

Question 3 : The notation "Box [X](C->S)" is  explained but the "actual 
steps for creating and opening a box" are not clear to me, even after 
having read the CurveCP pages. Could you please detail what it means and 
what mechanisms are behind ? Is "Box [X](C->S)" and "Box [X](C'->S)" the 
same ? For "Box [X](C->S)", I understand from "Create the box using S's 
public key, and C's secret key and a well-chosen nonce." that X is 
crypted with S' and the box contains a nonce crypted with c' (the client 
short time secret key). It uses the commutativity property where 
C'{c'{X}} = c'{C'{X}} = X. "Open the box using C's public key, and S's 
secret key, and the same nonce." means that on the other side, X is 
decrypted with s' and the nonce with C'. Is it correct ? "Box [C' + 
s'](K)" remains very mysterious to me ?

Question 4 : Server throw away the generated key pair, thus S'/s', but 
needs s' to decode the INITIATE. Could you precise what happens here 
please ?

Question 5 : I know a nonce is a one single usage data, but the 
mechanism behind is not explained also. Could you please add some 
explanations ? Idem for the "vouch" ?

Question 6 : Messages (payloads or application data), are encrypted with 
short term keys, correct ?

Question 7 : In the "HELLO Command" details, the last field is "The 
signature box (80 octets). This SHALL contain 64 zero octets, encrypted 
from the client's connection key C' to the server's long-term key S.". 
The clear text is known as "zeros", enabling attacks from known clear 
text ? Same remark for nonce prefixes like "WELCOME-" ?

Question 8 : The nonces shall be known by both the server and the 
client. So I assume they are generated from a pseudo random generator 
seeded with a function of C' and S' ? This re-enforces the idea of 
encrypting C' in the HELLO command.

Question 9 : The link "https://github.com/zeromq/rfc/src/spec_27.c" in 
"http://rfc.zeromq.org/spec:27" is dead. Is ZAP included in CurveZMQ, or 
is it elsewhere ? Where ? A Client/Server minimal example with both 
CurveZMQ and ZAP for both sides client/server authentication would be 
great please.

>
>> In RFC26, § Overall Operation of CurveZMQ, it looks like the server actually
>> authenticate the client from its long term public key from the INITIATE
>> command, but there is no point where the client authenticate the server from
>> its long term public key.
> If the client uses the wrong server key, it cannot send a valid HELLO
> command, and it cannot read the WELCOME command. The server does not
> send its long term public key - the client MUST already have this.
>
>> Can the same server long term public key be used for many clients (I assume
>> yes from my understanding) ?
> Yes.
>
>> That's the long term public keys which are used for authentication and
>> therefore shall be known by the other end-point, so transmitted by other
>> means.
> Yes.
>
>> How does this CurveZMQ authentication mechanism compares with https
>> certificates ?
> There's no certificate authority. Long terms keys are exchanged in
> advance. It means two peers can connect securely even if they don't
> have full Internet access.
>
> -Pieter
> _______________________________________________
> 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/20130808/62536589/attachment.htm>