TLS

1. Rules for the Handshake Protocol - Rules in this set govern the initial steps in the TLS saraband.
2. Rules for Message Exchange - Rules in this set govern the exchange of pleasantries after the client-suitor and server-suited have dispatched with the initial courtly contact dictated by the handshake protocol.

Each of these rule sets is in and of itself a complicated beast. So, to keep your and my head from exploding with the details of these courtly prescripts we'll break them down and anatomize them one by one.

First let us take the knife to the handshake protocol. The steps in this dance lead the client and server from the restiveness of a first-sight to the shared knowledge of a pair of secret keys. The steps in the handshake protocol are as follows:

1. Client Hello - In this dance step the client sends a ``Hello'' message to the server. The most important portion of this salutation, as far as we are concerned, is the random number contained within.
2. Server Hello - In this step of the saraband, the server responds to the client's hail with its own ``Hello'' message. This ``Hello'' includes, among other things, a random number.
3. Server Certificate - In this next step in the pavan, the server sends its certificate to the client.
4. Server Hello Done - Finally the server ends the beginning with a message indicating it is done with the ``Hello'' portion of the proceedings.
5. Client Key Exchange Message - The client in this phase creates yet another random number, encrypts it with the server's public key, and sends it to the server.
6. Client Finished - This step is a simple dance step; the client informs the server it is done with the formalities of the handshake protocol.
7. Server Finished - Convinced with the veracity of the client's last message, the server informs the client it is also done with perfunctories of the handshake protocol.
8. Key Generation - In this final dance step the client and server generate two keys from the three random numbers exchanged. The first key is used for creating digests. The second key is used for a symmetric cipher.

As this is all rather abstract warbling, I think a diagram will set the concrete of this process more solidly in the mold of your mind, see figure . From the diagram, or that matter from the above list, one can ascertain that the harvest of this process is a pair of two keys. In the client's clutch is one pair and the server's grip also holds a pair. These pairs of keys are exactly the same. For any given pair one key in the pair is used to create digests and one key is used to for a symmetric cipher. These keys are the hub about which the message exchange rule set of TLS rotates.

The message exchange rule set is a far more simple rule set than the handshake protocol. It allows for client-suitor and server-suited to exchange missives surreptitiously, far from the evil eyes of the likes of Pope Leo X, for example. To launch letters using the message exchange protocols all the client or server need do is to create a digest for the missive using the digest key, encrypt the missive and its digest using the symmetric cipher key, and send the encrypted bundle along the wire to the waiting lover. The waiting lover receiving this letter of love need only decrypt it using the symmetric key, compute the digest of the of the plaintext using the digest key, and compare the received digest to the computed digest to guarantee message integrity. Simple. With these TLS tricks we, as stunt-double Leonardo, and the courtly lovers, as courtly lovers, are free from the evil eye of Pope Leo X.