Letting SQL 2005 do they heavy work of encrypting data

Many of the developers I work with go through the pain of trying to figure out how to encrypt data before passing it on to the database tier.

What encryption algorithms do I use? What key length? How do I create an operational infrastructure to manage my keys, and what happens if they are compromised. Where should I store the keys in memory, and can they be compromised in a "fully trusted" .NET environment

TheServerSide.NET makes reference to the new data security capabilities of SQL Server 2005 which include the ability to set column level encryption for sensitive data.

SQL Server 2005 includes many security-related features that help protect the data in an organization. SQL Server 2005 includes password policy enforcement, a strong authentication functionality, and a granular hierarchical permissions model. SQL Server 2005 also includes a built-in data encryption capability. This column-level encryption capability is enhanced by an integrated and hierarchical infrastructure for managing encryption keys. Built-in encryption functions and application programming interfaces (APIs) make it easier for an organization to create an encryption security framework.

This is great news - as a Developer, now I can just "outsource" all of this work to the database tier, and don't need to worry about all of those nasty encryption and key management issues.