SQL + PGP = head aching

Question

SQL + PGP = head aching

Viewing 4 posts - 16 through 19 (of 19 total)

You must be logged in to reply to this topic. Login to reply

TheSQLGuru SSC Guru Points: 134017 More actions · Answer 1

weevil (7/5/2012)
Some great suggestions here guys, its a great help. I have a workshop with the client in a few days. It seems there is indeed more than one way to skin this particular cat. I'm sure the SQL people will want the .NET people to do it, the .NET people will want the SQL people to do it, and the client will want me to do it, so we'll see who wins 🙂

The people who want encryption/decryption to be done out in the .NET layer somewhere are ABSOLUTELY correct (or at least best practice). Anything you tell SQL Server to do MUST BE DONE ON THAT SINGLE SERVER. That single box is a limited collection of resources (primarily RAM, CPU and IO) that once exhausted things start to get slow in a HURRY. If encrypting/decrypting documents is done elsewhere, that elsewhere can almost certainly be scaled out - think web farm, middle tier farm, even on thick-client desktops potentially.

Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service

Nadrek SSC-Insane Points: 20039 More actions · Answer 2

TheSQLGuru (7/5/2012)
The people who want encryption/decryption to be done out in the .NET layer somewhere are ABSOLUTELY correct (or at least best practice). Anything you tell SQL Server to do MUST BE DONE ON THAT SINGLE SERVER. That single box is a limited collection of resources (primarily RAM, CPU and IO) that once exhausted things start to get slow in a HURRY. If encrypting/decrypting documents is done elsewhere, that elsewhere can almost certainly be scaled out - think web farm, middle tier farm, even on thick-client desktops potentially.

+1 - do you really want your SQL Server box to be spending the CPU required to encrypt and decrypt (arbitrarily) large amounts of data? SQL is the wrong tool for this. Also, if it's encrypted first, then it's encrypted on the network between SQL and the client, which is a bonus (or a requirement?).

Note that for FIPS compliance, you can't just use PGP, you need to insure that all the PGP keys and/or configurations are set to only use FIPS compliant algorithms. Ideally, you'll also be following the NIST SP800-131A transition guidelines for cryptographic algorithms and key lengths (which, just like FIPS 140-2, blatantly forbids most older default PGP keys).

Note also that FIPS certification is a whole different ball of wax.

weevil SSC Veteran Points: 234 More actions · Answer 3

Note that for FIPS compliance, you can't just use PGP, you need to insure that all the PGP keys and/or configurations are set to only use FIPS compliant algorithms. Ideally, you'll also be following the NIST SP800-131A transition guidelines for cryptographic algorithms and key lengths (which, just like FIPS 140-2, blatantly forbids most older default PGP keys).
Note also that FIPS certification is a whole different ball of wax.

Yea I'm familiar with FIPS compliance, I have the encryption bit under control it was just how to have it retrofitted into this current scenario, everything will be AES-256.

Nadrek SSC-Insane Points: 20039 More actions · Answer 4

weevil (7/6/2012)
Yea I'm familiar with FIPS compliance, I have the encryption bit under control it was just how to have it retrofitted into this current scenario, everything will be AES-256.

For those not as familar as weevil, hashing algorithm matters as well as the encryption algorithm (i.e. SHA-512, SHA-256, etc. for any application, or SHA-1 for non-digital signature applications only, per the aforereferenced NIST SP800-131A).