I've been tech editing Michael Cole's new book on Encryption in SQL Server, which is due out in August or September of this year. It's an exciting project for me because I was very disappointed in the extreme dearth of information in Books Online for encryption. I totally understand why people struggle with this or don't use it, but the vendor skimping on details is inexcusable.

In any case, I noticed early on that there was no facility for backing up symmetric keys. I got a few comments from Microsoft about "why would you since they're in the database backup" that did not make me feel better. Lots of things are in the database backup, but that doesn't mean we don't need to transfer them to other systems or other databases. Or that we just want a back up.

In answering a post for someone on encryption, I mentioned to the poster that they needed to look at a database backup to get a copy of their symmetric key, which they had deleted. Then Michael chimed in that this wasn't necessarily true, and I'm betting that thread lead this this blog post: "Cloning" Symmetric Keys. I haven't asked Michael about it since he's a busy guy, and I know he's been traveling, but that's my guess.

In the blog, Michael says that with the same seed values, SQL Server will create the same symmetric key. If you have the same key source and identity values, you get the same key. Which is good and bad. It's good in that you can reproduce the key if you have issues or corruption.

Bad because someone else can do this as well if they know what seed values you used. That means they can decrypt your data.

So apparently the seed values are just as important to protect as the keys themselves.