Symmetric Keys part 2

This is a continuation of the discussion on Symmetric Keys and its use in encrypting data. The algorithm and its output were brought up in the previous article but not the operational engineering considerations. This article completes that discussion.

The result of generating a key is a 16-character Identity Vector and a 32-character Key. When an encrypted data is written to a file, the identity vector must be included.  Symmetric key encryption is fast, efficient and can work on block and streams for large data. Asymmetric encryption can be used for small sized data such as a password or a symmetric key.

A key is useful only to the point that it is not compromised. One of the most difficult things to do is guard a secret indefinitely. That is why secrets are often changed routinely. A symmetric key is just like a password but instead of allowing the system to carry it forward, it must be overwritten with a new one. A history can be maintained for all the keys generated. Data once encrypted with a key must be decrypted with that key before it can be re-encrypted with another key. This poses a few questions.

What happens when a new key must be generated? Will any part of the old key come useful?  The answer is yes, we need to know the source and identity of the key without which a key cannot be copied or scripted.  When we have this information, we can create a new key and re-encrypt locally. Then we can move the encrypted data and recreate the key in the new location. We have all the important seed data available for that new key at destination. This is how symmetric key encrypted data is moved from a source to destination independent of whether the data resides in a filesystem or a SQL Database.

This was about restore. One of the incorrect myths about symmetric keys is about backup. It goes something like this: You do not need to back up your symmetric key if it was created from a certificate, because you can just recreate it. This is not only incorrect it is also risky for the data that is being encrypted. The assumption for this myth is that two symmetric keys that are created with the encryption by certificate clause using the same certificate will be identical.  Since the certificate can be backed up, the keys don’t need a backup. Here the cause-and-effect argument is incorrect.

When symmetric keys are generated in SQL server with the same certificate, they will have different key_guids. This is the first indicator but not the conclusive one. The certificate_id from the certificate and the crypt_property attribute of the symmetric key will also be different which is the conclusive proof that the symmetric keys are not the same.

An asymmetric key can also not be backed up. Two symmetric keys created with the same asymmetric key will also be different.

Those myths debunked; it should become clear from the approach in restore that backup is not necessary.

There is, however, a solution used in many commercial ventures that involves the use of an external key management system that eliminates the maintenance overhead of using symmetric keys.