Author: way0utwest

  • Using a Symmetric Key

    In my Encryption Primer talk, I do demo on symmetric key use, and wanted to document it here. Encryption is a serious subject, and please do your research and education, as well as testing, before you implement it.

    This post will look at some simple encryption and decryption using symmetric keys. I showed how to create a symmetric key before, so I won’t talk about that here, but I’ll just show the code.

    Let’s set up a test table. In this case, I’m showing salary in a table, which isn’t something you want to do, but you might have this in an existing application: data you need to encrypt, but it’s stored unencrypted.

    -- create a table 
    create table Employees ( 
     id int identity(1,1)
     , firstname varchar(200)
     ,lastname varchar(200)
     ,title varchar(200)
     ,salary numeric(10, 4) );
    go
    insert Employees 
    values
      ('Steve','Jones','CEO', 5000)
     , ('Delaney','Jones','Manure Shoveler', 10)
     , ('Kendall','Jones','Window Washer', 5)
    ;
    go 

    Here I have three employees and salaries. Now I want to encrypt the salary. However I cannot just encrypt this value. Encryption creates a binary representation of the data, and that won’t fit in a varchar field. So I need to add a column.

    alter table Employees 
     add EnryptedSalary varbinary(max);
    go 

    Now I have a placeholder, so let’s create a key and then update the new binary column with the encrypted value.

    -- create a symmetric key
    create symmetric key MySalaryProtector
     WITH ALGORITHM=AES_256
     , IDENTITY_VALUE = 'Salary Protection Key'
     , Key_SOURCE = N'Keep this phrase a secr#t' 
     ENCRYPTION BY PASSWORD = 'Us#aStrongP2ssword'
    ;
    go 
    -- open the key 
    open symmetric key MySalaryProtector
     decryption by password='Us#aStrongP2ssword'
    ;
    
    -- encrypt the data 
    update Employees 
     set EnryptedSalary = ENCRYPTBYKEY(key_guid('MySalaryProtector'),cast(salary as nvarchar))
    ; 
    go 
    -- remove the old data 
    update employees
     set salary = 0
    ; 
    go 

    Note that I open the key, which is needed. I can close it at the end, or it will close when my session ends. I don’t close it here as I usually run this demo in the course of one session.

    The encryption takes place with the ENCRYPTBYKEY function, which requires the GUID of the key. Why the GUID and not the name I don’t know, but it seems like a PIA, halfway implementation. In any case, the KEY_GUID function is used as the first parameter.

    The number needs to be cast as a character, so I do that first, and then it’s the next parameter in the function. If I look at the data, it looks like this:

    select id , firstname , lastname , title , salary , EnryptedSalary
     from Employees; go 

    encryptsymm

    If you use the same identity_value and key_source, you should get the same encryption.

    To decrypt it, I do this:

    -- decrypt the data, with the casting  select id  , firstname  , lastname  , title  , Salary = cast(cast(DecryptByKey(EnryptedSalary) as nvarchar) as numeric(10,4))  , EnryptedSalary  from Employees go 

    The encrypted value has a header that tells it what key is used, so as long as it’s open, this works.

  • Last Week to Enter the Exceptional DBA Contest

    Just a reminder: you have until this Friday to enter the 2012 Exceptional DBA awards. I’m judging, and looking forward to reading the entries next week, so get them in.

    A hint: communication skills matter. Take some time and think about what you want to write for each question.

  • Down and Dark

    I came back from vacation to find the home DSL line bouncing up and down a bit. I wasn’t overly worried, and the kids knew to restart the router when it went down, crossing their fingers for a good connection. I suspected the router might be dying, and was getting mentally prepared to go hardware shopping. I figured I’d enjoy the downtime and stay unwired for the last few days before going back to work.

    On Sunday night, our connection was down for good, with a red light on the router. I called Monday morning into the Century Link tech support line, and they informed me they knew there was an outage. Good, I thought, they’ll have it fixed soon. I packed up and spent Monday in town working at the library to not fall any further behind.

    Tuesday morning had the line still down, despite complaints to Century Link. The people answering the phone apparently are not any more informed by their engineers than I am. I find that hard to believe, but there wasn’t much I could do. I packed up again, and am in town working again.

    Broadband access has almost become a commodity, and I’d argue that for many of us, it’s a utility. We pay bills online, get sent all sorts of information online, many of us not even getting newspapers anymore. It’s not longer a luxury, but a necessity for us to make do in the modern world. For me, it’s part of my job, and the lack of a line is a huge impact to me getting work done.

    Fingers are crossed that this gets fixed soon as work is piling up.

  • Documenting the Undocumented

    Evolution of Documentation
    Documentation is important, especially for the platform. Things that are used often, like xp_file_delete, need to be documented.

    There are any number of functions in SQL Server that are undocumented. I have no idea how many there are because, well, they’re undocumented. I can’t see the source code, so I’m not sure what’s actually encoded in the platform.

    I’ve heard arguments that everything should be documented, and while I appreciate the sentiment that complete documentation is a good thing, I also understand the other side. Each item that is documented must be supporter, or at least supported in the lawsuit happy US. That means it must also be tested extensively and this means an increased load on the resources available for SQL Server. While I don’t want to see testing limited, or quicker releases of the platform, I do want everything well tested.

    There are some functions in the platform, such as some DBCC commands, that are added to help support. I can understand that testing, enhancing, and documenting these functions might not make sense. However I think there are some functions, which are used on a regular basis by millions of instances, and should be documented. For example, xp_delete_file is undocumented in Books Online, and a Connect item to provide documentation was closed as “by design”. However this function is called in maintenance plans, and has various bugs filed on cleanup issues and a lack of error reporting.

    Paul Randal has a good blog on why DBCC commands aren’t documented and it makes sense to me. I agree with the overall philosophy, but I would like to see those features that are used in normal operation of the platform completely documented.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.