Creating encryption keys

Each key must also have a timestamp that identifies which key to use for an image copy when multiple keys are present in the file. The API compares the timestamp from the image copy header record with the key timestamp and selects the key with the most recent timestamp that is earlier than (less than) or the same as (equal to) the image copy timestamp.

The following figure contains examples of encryption keys.

Creating encryption keys

When you create encryption keys, apply the following syntax rules:

• Precede each key with the literal X in column 1, and enclose the hexadecimal string in single quotation marks.
• The string can contain letters A through F and numbers 0 through 9. For a 128-bit key, specify 32 characters for the string. For a 64-bit key, specify 16 characters for the string.

• Specify the timestamp following the key (on the same line) in the following format:

  yyyy. ddd. hh. mm. ss. t

  In this format, yyyy is the year, ddd is the Julian day of the year (1 through 365), hh is the hour (00 through 23), mm is the minute (00 through 59), ss is the second (00 through 59), and t is the tenth of a second (0 through 9).

• If you specify multiple keys, specify each key on a separate line.
• To create a comment, specify an asterisk (*) in column 1.

Using multiple encryption keys

If you use multiple encryption keys, you must ensure that a key is retained as long as the image copy which was encrypted with that key is still valid for recovery.

For example, an organization takes an image copy of every database during the batch window every weekend. This organization retains four generations of image copy data sets. The organization decides to implement a new encryption key every Friday before the batch window begins. The following keys are created in the encryption key file:

The organization must retain Key 1 until all image copy generations that were created between December 29, 2006 and January 4, 2007 have been discarded.