Example: If the block length is 8 bytes, the content length
          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
          bytes, the length before padding is 82 bytes. Thus, the
          padding length modulo 8 must be equal to 6 in order to make
          the total length an even multiple of 8 bytes (the block
          length). The padding length can be 6, 14, 22, and so on,
          through 254. If the padding length were the minimum necessary,
          6, the padding would be 6 bytes, each containing the value 6.
          Thus, the last 8 octets of the GenericBlockCipher before block
          encryption would be xx 06 06 06 06 06 06 06, where xx is the
          last octet of the MAC.

 Note: With block ciphers in CBC mode (Cipher Block Chaining) the
       initialization vector (IV) for the first record is generated with
       the other keys and secrets when the security parameters are set.
       The IV for subsequent records is the last ciphertext block from
       the previous record.





 
RFC 2246              The TLS Protocol Version 1.0          January 1999


6.3. Key calculation

   The Record Protocol requires an algorithm to generate keys, IVs, and
   MAC secrets from the security parameters provided by the handshake
   protocol.

   The master secret is hashed into a sequence of secure bytes, which
   are assigned to the MAC secrets, keys, and non-export IVs required by
   the current connection state (see Appendix A.6). CipherSpecs require
   a client write MAC secret, a server write MAC secret, a client write
   key, a server write key, a client write IV, and a server write IV,
   which are generated from the master secret in that order. Unused
   values are empty.

   When generating keys and MAC secrets, the master secret is used as an
   entropy source, and the random values provide unencrypted salt
   material and IVs for exportable ciphers.

   To generate the key material, compute

       key_block = PRF(SecurityParameters.master_secret,
                          "key expansion",
                          SecurityParameters.server_random +
                          SecurityParameters.client_random);

   until enough output has been generated. Then the key_block is
   partitioned as follows:

       client_write_MAC_secret[SecurityParameters.hash_size]
       server_write_MAC_secret[SecurityParameters.hash_size]
       client_write_key[SecurityParameters.key_material_length]
       server_write_key[SecurityParameters.key_material_length]
       client_write_IV[SecurityParameters.IV_size]
       server_write_IV[SecurityParameters.IV_size]

   The client_write_IV and server_write_IV are only generated for non-
   export block ciphers. For exportable block ciphers, the
   initialization vectors are generated later, as described below. Any
   extra key_block material is discarded.

   Implementation note:
       The cipher spec which is defined in this document which requires
       the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte
       keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of
       104 bytes of key material.







 
RFC 2246              The TLS Protocol Version 1.0          January 1999


   Exportable encryption algorithms (for which CipherSpec.is_exportable
   is true) require additional processing as follows to derive their
   final write keys:

       final_client_write_key =
       PRF(SecurityParameters.client_write_key,
                                  "client write key",
                                  SecurityParameters.client_random +
                                  SecurityParameters.server_random);
       final_server_write_key =
       PRF(SecurityParameters.server_write_key,
                                  "server write key",
                                  SecurityParameters.client_random +
                                  SecurityParameters.server_random);

   Exportable encryption algorithms derive their IVs solely from the
   random values from the hello messages: