| title | description | author | ms.author | ms.reviewer | ms.date | ms.service | ms.subservice | ms.topic | helpviewer_keywords | monikerRange | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Choose an encryption algorithm |
Use this guidance to choose an encryption algorithm to help secure an instance of SQL Server, which supports several common algorithms. |
rwestMSFT |
randolphwest |
vanto |
09/22/2023 |
sql |
security |
conceptual |
|
>=aps-pdw-2016 || =azuresqldb-current || =azure-sqldw-latest || >=sql-server-2016 || >=sql-server-linux-2017 || =azuresqldb-mi-current |
[!INCLUDE SQL Server]
Encryption is one of several defenses available to the administrator who wants to secure an instance of [!INCLUDE ssNoVersion].
Encryption algorithms define data transformations that can't be easily reversed by unauthorized users. Administrators and developers can choose from among several algorithms in [!INCLUDE ssNoVersion], including DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bit RC4, DESX, 128-bit AES, 192-bit AES, and 256-bit AES.
Beginning with [!INCLUDE sssql16-md], all algorithms other than AES_128, AES_192, and AES_256 are deprecated. To use older algorithms (not recommended), you must set the database to database compatibility level 120 or lower.
No single algorithm is ideal for all situations, and guidance on the merits of each is beyond the scope of this article. However, the following general principles apply:
-
Strong encryption generally consumes more CPU resources than weak encryption.
-
Long keys generally yield stronger encryption than short keys.
-
Asymmetric encryption is slower than symmetric encryption.
-
Long, complex passwords are stronger than short passwords.
-
Symmetric encryption is recommended when the key is only stored locally. Asymmetric encryption is recommended when keys need to be shared across the wire.
-
If you're encrypting lots of data, you should encrypt the data using a symmetric key, and encrypt the symmetric key with an asymmetric key.
-
Encrypted data can't be compressed, but compressed data can be encrypted. If you use compression, you should compress data before encrypting it.
For more information about encryption algorithms and encryption technology, see Key Security Concepts.
The RC4 algorithm is only supported for backward compatibility. New material can only be encrypted using RC4 or RC4_128 when the database is in compatibility level 90 or 100 (not recommended). Use a newer algorithm such as one of the AES algorithms instead. In [!INCLUDE ssSQL11] and later versions, material encrypted using RC4 or RC4_128 can be decrypted in any compatibility level.
Repeated use of the same RC4 or RC4_128 KEY_GUID on different blocks of data results in the same RC4 key because [!INCLUDE ssNoVersion] doesn't provide a salt automatically. Using the same RC4 key repeatedly is a well-known error that results in weak encryption. Therefore, we have deprecated the RC4 and RC4_128 keywords. [!INCLUDE ssNoteDepFutureAvoid]
DESX was incorrectly named. Symmetric keys created with ALGORITHM = DESX actually use the Triple DES cipher with a 192-bit key. The DESX algorithm isn't provided. [!INCLUDE ssNoteDepFutureAvoid]
Symmetric keys created with ALGORITHM = TRIPLE_DES_3KEY use Triple DES with a 192-bit key.
Symmetric keys created with ALGORITHM = TRIPLE_DES use Triple DES with a 128-bit key.