Problem - Kevin Tafuro

we might have the client and server send messages in lockstep, or we might have
them send messages asynchronously. If they send messages asynchronously, we can
use a separate key for each direction or, if using a nonced encryption mode, manage
two nonces, while ensuring that the client and server nonces never collide (we’ll use
this trick in the code below).
If you do need multiple keys for your setup, you can take the exchanged key and use
it to derive those keys, as discussed in Recipe 4.11. If you do that, use the exchanged
key only for derivation. Do not use it for anything else.
At this point, on each end of the connection, we should be left with an open file
descriptor and whatever keys we need. Let’s assume at this point that we’re using
CWC mode (using the API discussed in Recipe 5.10), our communication is synchronous,
the file descriptor is in blocking mode, and the client sends the first message.
We are using a random session key, so we don’t have to make a derived key, as happens
in Recipe 5.16.
The first thing we have to do is figure out how we’re going to lay out the 11-byte
nonce CWC mode gives us. We’ll use the first byte to distinguish who is doing the
sending, just in case we want to switch to asynchronous communication at a future
point. The client will send with the high byte set to 0x80, and the server will send
with that byte set to 0x00. We will then have a session-specific 40-bit (5-byte) random
value chosen by the client, followed by a 5-byte message counter.
The message elements will be a status byte followed by the fixed-size nonce, followed
by the length of the ciphertext encoded as a 32-bit big-endian value, followed
finally by the CWC ciphertext (which includes the authentication value). The byte,
the nonce, and the length field will be sent in the clear.
The status byte will always be 0x00, unless we’re closing the connection, in which
case we’ll send 0xff. (If there is an error on the sender’s end, we simply drop the
connection instead of sending back an error status.) If we receive any nonzero value,
we will terminate the connection. If the value is not 0x00 or 0xff, there was probably
some sort of tampering.
When MAC’ing, we do not need to consider the nonce, because it is an integral element
when the CWC message is validated. Similarly, the length field is implicitly
authenticated during CWC decryption. The status byte should be authenticated, and
we can pass it as associated data to CWC.
Now we have all the tools we need to complete our authenticated secure channel.
First, let’s create an abstraction for the connection, which will consist of a CWC
encryption context, state information about the nonce, and the file descriptor over
which we are communicating:
#include
#include
#include
494 | Chapter 9: Networking
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.