[zeromq-dev] CurveZMQ availability plan ?
Pieter Hintjens
ph at imatix.com
Thu Aug 8 14:50:45 CEST 2013
The cookie
On Thu, Aug 8, 2013 at 12:42 PM, Laurent Alebarde <l.alebarde at free.fr> wrote:
1. The server generates a private/public keypair S' and s' for each
new connection, sends these back in the WELCOME, then discards them.
If/when the client replies with an INITIATE, the server unpacks this
keypair again, so it can decrypt and encrypt data. It provides the
public key S' to the client and encodes the private key s' as the
cookie. These two fields are encrypted from the server public key S to
the client short term public key C'.
2. The client never sends its public long term key C in the clear. It
sends the short term connection key C' in the HELLO command.
3. Box [X](C->S) means a box signed by C and readable only by S. To
create the box we always use our secret key to sign it, and the
recipient's public key to encrypt it. To open a box we always use the
sender's public key to authenticate it, and our secret key to decrypt
it. If the box cannot be opened, we discard it. So to create a Box
[X](C->S) we sign using c' and encrypt using S. To open the box we
authenticate using C and open using s'.
4. The server decodes the INITIATE cookie using the temporary cookie
key, which gives it C' and s'. It doesn't ever need S' after sending
that to the client.
5. I've added some explanations of nonces and the vouch.
Elliptic curve encryption depends on mixing a unique number into
each encryption operation. This "number used once", or "nonce", is
chosen by the sender, stops replay attacks, and protects the keys from
cryptoanalysis. We use two kinds of nonces in CurveZMQ. A long nonce
protects long-term keys, and is 16 octets from a good random number
generator. A short nonce protects short-term connection keys and is an
8-octet sequential number.
6. Messages are encrypted using the short term keys, yes.
7. If a client does not place zeros in signature box, the server will
discard the HELLO command. If a sender uses the wrong nonce prefix,
the box cannot be unpacked, and the command will be discarded.
8. The sender choses the nonce, and places it in the message in clear.
Nonces are not secret. They must only be unique. The sender can use
any algorithm to choose a unique nonce. We use random numbers for long
nonces, sequential integers for short ones.
9. I fixed the link to
https://github.com/zeromq/rfc/blob/master/src/spec_27.c, thanks. The
reference implementation for CurveZMQ is
https://github.com/zeromq/curvezmq, in the curvezmq_codec class.
Hope this helps. Thanks for the feedback on the specs.
-Pieter
More information about the zeromq-dev
mailing list