Прежде всего, это можно очень легко проверить.Вы можете просто зашифровать одно и то же значение два раза и проверить, совпадают ли выходные данные.Используйте следующий код:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '23987hxJ#KL95234nl0zBe';
CREATE CERTIFICATE [CERT_StackOverflow]
WITH SUBJECT = 'example';
CREATE SYMMETRIC KEY [SK_StackOverflow]
WITH ALGORITHM = AES_256
ENCRYPTION BY CERTIFICATE [CERT_StackOverflow];
GO
OPEN SYMMETRIC KEY [SK_StackOverflow] DECRYPTION BY CERTIFICATE [CERT_StackOverflow];
SELECT EncryptByKey(Key_GUID('SK_StackOverflow'), 'stackoverflow');
SELECT EncryptByKey(Key_GUID('SK_StackOverflow'), 'stackoverflow');
DROP SYMMETRIC KEY [SK_StackOverflow];
DROP CERTIFICATE [CERT_StackOverflow];
DROP MASTER KEY;
Таким образом, в результате функция ENCRYPTBYKEY не является детерминированной.
Почему?Это будет очень легко грубой силой, если бы не было.И если вам интересно, что происходит за кулисами, вы можете проверить следующую статью .Как правило, выходной текст рассчитывается следующим образом:
CipherTextMessage: = KeyGUID + EncryptionHeader + EncryptedMessage
где:
И ключом является InitializationVector
, который:
InitializationVector: = {1block} длина этого поля зависит от используемого алгоритма.Все ключи семейства AES будут иметь размер 16 байт на блок, а ключи семейства DES - 8 байт на блок.Векторы инициализации используются для инициализации алгоритма блока.Он не предназначен для того, чтобы быть секретом, но должен быть уникальным для каждого вызова функции шифрования во избежание выявления шаблонов.
Если вас интересует функция детерминированного шифрования из-за создания индекса, например, для оптимизации поиска, и вы не хотите использовать Always Encrypted из-за всех его ограничений, я могурассказать, как вы можете создать / смоделировать детерминированное шифрование с помощью SQL Server иерархия безопасности .