Symmetric vs Assymmetric Keys with Cell-Level Encryption

Mark Sanchez 61 Reputation points
2022-02-14T22:45:30.333+00:00

We are trying to make up our minds about using cell-level encryption in SQL Server but do not yet know if we should utilize symmetric cryptography or asymmetric cryptography. From what we understand, symmetric cryptography is secure and fast, while asymmetric cryptography is more secure but can potentially experience performance issues.

While more security sounds good to us, what we’d like to know is if our simple use case will lead to performance issues with our custom applications?

Our use case is as follows: Our custom applications will query for a small amount of secure data needed by the application at startup (usually 2-4 fields/values), then make calls to select other secure data during runtime if necessary (usually 1-2 more fields/values). Would something this minimal cause any noticeable performance hit to our applications’ end-user experience?

SQL Server | Other
{count} votes

1 answer

Sort by: Most helpful
  1. Erland Sommarskog 121.4K Reputation points MVP Volunteer Moderator
    2022-02-15T22:33:07.13+00:00

    If you ask me, none of them are very safe. Yes, one encryption is stronger than the other, but that does that matter if you leave the key under the doormat? Which is what you do if you protect the keys with the database master key.

    Then again, there are decryption functions that works with password. That's a little better, as they can be sent from the client. Not that this is very safe, because they can still be retrieved, even if it requires some work.

    Did you consider Always Encrypted, or are you on SQL 2014 or earlier where this feature is not available? AE is better, since decryption occurs outside SQL Server, and the encryption key does not have to be available on the SQL machine at all.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.