我的问题与以下两个实例的实验有关:
SQL Server 2017 Express 实例 (Microsoft SQL Server 2017 (RTM-CU16))
SQL Server 2014 Express 实例 (Microsoft SQL Server 2014 (SP2-CU18))
我使用函数ENCRYPTBYPASSPHRASE加密文本并将结果用作 DECRYPTBYPASSPHRASE 的@ciphertext。我的测试结果如下:
根据这个微软修复,
[...] SQL Server 2017 使用 SHA2 散列算法来散列密码。SQL Server 2016 和更早版本的 SQL Server 使用不再被视为安全的 SHA1 算法。
但是,如果函数 DECRYPTBYPASSPHRASE 上没有与该算法相关的参数,它怎么知道用于加密数据的算法是什么?它是加密数据的一部分吗?
根据我的测试结果,我猜 SQL Server 总是使用实例上可用的较新版本的算法来加密数据,但会尝试所有算法来解密数据,直到找到适合的算法或在找不到相应算法时返回 NULL . 这只是一个猜测,因为我找不到任何方法来检查 SQL Server 用来解密加密数据的散列算法。
是的,没错。
我将使用以下输出:
如果我在我的 2014 实例上运行它,我将得到 Encrypted_Data 的以下内容:
0x01000000E565142762F62...
如果我在我的 2017 实例上运行它,我将得到 Encrypted_Data 的以下内容:
0x020000004D261C666204F...
应该弹出的是序言,您可以在其中看到 2014 实例以 . 开头,
0x01
而 2017 实例以0x02
. 这是使用的加密类型的版本控制。请注意,不仅如此,但出于此答案的目的,无需深入了解该细节,也不需要成为公众知识。SQL Server 2017 理解
0x01
并且0x02
因为它是新的并且知道新事物。SQL Server 2014 理解只是0x01
因为它较旧并且不知道任何新事物,因为新事物没有向后移植。这不是一回事,但通常与在两个版本中使用相同的初始化向量创建的对称密钥有关。我在 2017 年发布时写了一篇关于此的博客,稍后使用必须使用的跟踪标志对其进行了修复,而在您的问题中,2017 年不需要跟踪标志来读取 2014 年的数据,如图所示。