CurveCP: Usable security for the Internet

A CurveCP connection begins with a Hello packet from the client, a Cookie packet from the server, and an Initiate packet from the client. The server is free to send any number of Message packets after it sees the Initiate packet. The client is free to send any number of Message packets after it sees the server's first Message packet.

If the client does not see a Cookie packet then it will send another Hello packet. The server sends a Cookie packet in response to each Hello packet, rather than limiting the client to one Hello packet. Similarly, the client can send several Initiate packets.

The following diagram indicates how these packets are encrypted and summarizes the contents of the packets. Important notation: Box[X](C->S) is a cryptographic box, encrypting and authenticating X from the client's public key C to the server's public key S. The only people who can create or decipher Box[X](C->S) are the people who know the secret key corresponding to C and the people who know the secret key corresponding to S. (Note to readers familiar with BAN logic etc.: Box[X](C->S) should not be confused with the traditional concept {X}_K of something encrypted under secret key K without authentication.)

Client to server Server to client

Hello packet:
(C',0,Box[0'](C'->S))
where C' is the client's short-term public key
and S is the server's long-term public key
and 0 is zero-padding
and 0' is zero-padding

Cookie packet:
(Box[S',K](S->C'))
where S' is the server's short-term public key
and K is a cookie

Initiate packet with Vouch subpacket:
(C',K,Box[C,V,N,...](C'->S'))
where C is the client's long-term public key
and V=Box[C'](C->S)
and N is the server's domain name
and ... is a message

Message packet:
(Box[...](S'->C'))
where ... is a message

Message packet:
(C',Box[...](C'->S'))
where ... is a message

Message packet:
(Box[...](S'->C'))
where ... is a message

Message packet:
(C',Box[...](C'->S'))
where ... is a message

The cookie K is Box[C',s'](t), where s' is the secret key corresponding to S', and t is a secret "minute key" maintained by the server. This is a cryptographic box that can be created and understood only by t.

Summary of the packet format

Each packet begins with an 8-byte identifier of the type of packet. If the packet happens to be delivered to some non-CurveCP application then these bytes will prevent the non-CurveCP application from being confused. A secondary function of this identifier is to allow, e.g., the server to quickly distinguish Hello packets from Initiate packets.

Each packet continues with a 16-byte receiver extension and a 16-byte sender extension. Gateways can process these extensions without parsing the rest of the packet.

Each packet from the client continues with the client's short-term public key C'. The server reuses this key as an identifier to index active connections.

Each packet continues with a cryptographic box (preceded by padding for Hello packets, and preceded by the server's cookie K for Initiate packets), as summarized in the diagram above. A nonce is attached to each cryptographic box, preventing replays and preventing confusion between the boxes in different types of packets; the nonces are not shown in the diagram above. A packet with an unopenable box (i.e., a box that fails cryptographic verification) is discarded by the receiver.

Client Hello packet details

A Hello packet is a 224-byte packet with the following contents:

8 bytes: the ASCII bytes "QvnQ5XlH".
16 bytes: the server's extension.
16 bytes: the client's extension.
32 bytes: the client's short-term public key C'.
64 bytes: all zero.
8 bytes: a client-selected compressed nonce in little-endian form. This compressed nonce is implicitly prefixed by "CurveCP-client-H" to form a 24-byte nonce.
80 bytes: a cryptographic box encrypted and authenticated to the server's long-term public key S from the client's short-term public key C' using this 24-byte nonce. The 64-byte plaintext inside the box has the following contents:
- 64 bytes: all zero.

Current servers enforce the 64-byte length requirement but do not enforce the all-zero requirement. The all-zero bytes in this packet are an anti-amplification mechanism, ensuring that Hello packets are as long as Cookie packets; this is why the 64-byte length requirement is enforced. They are also an extension mechanism, allowing future protocol extensions such as hashcash; this is why the all-zero requirement is not enforced. Clients must nevertheless be careful to follow the all-zero requirement to avoid confusing future servers that support extensions.

Server Cookie packet details

A Cookie packet is a 200-byte packet with the following format:

8 bytes: the ASCII bytes "RL3aNMXK".
16 bytes: the client's extension.
16 bytes: the server's extension.
16 bytes: a server-selected compressed nonce in little-endian form. This compressed nonce is implicitly prefixed by "CurveCPK" to form a 24-byte nonce.
144 bytes: a cryptographic box encrypted and authenticated to the client's short-term public key C' from the server's long-term public key S using this 24-byte nonce. The 128-byte plaintext inside the box has the following contents:
- 32 bytes: the server's short-term public key S'.
- 96 bytes: the server's cookie.

Client Initiate packet details

An Initiate packet is a (544+M)-byte packet with the following contents, where M is a multiple of 16 between 16 and 640:

8 bytes: the ASCII bytes "QvnQ5XlI".
16 bytes: the server's extension.
16 bytes: the client's extension.
32 bytes: the client's short-term public key C'.
96 bytes: the server's cookie.
8 bytes: a client-selected compressed nonce in little-endian form. This compressed nonce is implicitly prefixed by "CurveCP-client-I" to form a 24-byte nonce.
368+M bytes: a cryptographic box encrypted and authenticated to the server's short-term public key S' from the client's short-term public key C' using this 24-byte nonce. The (352+M)-byte plaintext inside the box has the following contents:
- 32 bytes: the client's long-term public key C.
- 16 bytes: a client-selected compressed nonce in little-endian form. This compressed nonce is implicitly prefixed by "CurveCPV" to form a 24-byte nonce.
- 48 bytes: a cryptographic box encrypted and authenticated to the server's long-term public key S from the client's long-term public key C using this 24-byte nonce. The 32-byte plaintext inside the box has the following contents:
  - 32 bytes: the client's short-term public key C'.
- 256 bytes: the server's domain name, in DNS format (between 1 and 255 bytes), zero-padded to 256 bytes.
- M bytes: a message.

Server Message packet details

A Message packet from the server is a (64+M)-byte packet with the following contents, where M is a multiple of 16 between 16 and 1088:

8 bytes: the ASCII bytes "RL3aNMXM".
16 bytes: the client's extension.
16 bytes: the server's extension.
8 bytes: a server-selected compressed nonce in little-endian form. This compressed nonce is implicitly prefixed by "CurveCP-server-M" to form a 24-byte nonce.
16+M bytes: a cryptographic box encrypted and authenticated to the client's short-term public key C' from the server's short-term public key S' using this 24-byte nonce. The M-byte plaintext inside the box has the following contents:
- M bytes: a message.

Client Message packet details

A Message packet from the client is a (96+M)-byte packet with the following contents, where M is a multiple of 16 between 16 and 1088:

8 bytes: the ASCII bytes "QvnQ5XlM".
16 bytes: the server's extension.
16 bytes: the client's extension.
32 bytes: the client's short-term public key C'.
8 bytes: a client-selected compressed nonce in little-endian form. This compressed nonce is implicitly prefixed by "CurveCP-client-M" to form a 24-byte nonce.
16+M bytes: a cryptographic box encrypted and authenticated to the server's short-term public key S' from the client's short-term public key C' using this 24-byte nonce. The M-byte plaintext inside the box has the following contents:
- M bytes: a message.

Version

This is version 2011.02.11 of the packets.html web page.