确定性加密：贼确定，就是安全不了一点er！

了解了确定性加密的应用场景以后，不得不说这种加密方式还是很“优秀”的，身怀多种技能，能满足很多场景的应用需求。但这种“优秀”仅限于以上这些应用，要是说起密文的安全性，那确实没有什么正经的安全性可言。

为什么呢，其实正因为确定性加密算法的输出是确定的，即使用相同的密钥和明文多次加密，输出的密文始终相同，就会面临以下3种安全风险。

下面我们举个例子，让大家直观地看看为什么确定性加密不安全。

相信眼尖的小伙伴已经看出来了，我们可以很容易地推测出，密文a4d0ff302b9c91a433c4a9d93f6845bc最可能代表职称“教授”，f2d7d11b0d7904db8a7cb1b2c76b345f最可能代表职称“副教授”，8239cd455a7cc94b9f869ee38b413e7c最可能代表职称“讲师”。还没看出来其中玄机的朋友且听我慢慢道来。

在这一列数据中，尽管密文全都是一堆晦涩难懂的十六进制编码（没错，这比起FPE加密而言，已经“肉眼可见”地安全了不少），但因为密文空间只有{a4d0ff302b9c91a433c4a9d93f6845bc，f2d7d11b0d7904db8a7cb1b2c76b345f，8239cd455a7cc94b9f869ee38b413e7c}的3个元素，且其比例是3：13：8，和我们已知的该学院的教师职称比例1:5:3基本一致。因此在掌握一定的信息后，我们很容易能够推测出这些密文所代表的含义。

为什么这么说呢？首先我们分析一下在确定性加密的思路下，密文模糊索引的实现原理。

以上面的职称为例，如果我们要模糊查询“教”，期望结果同时命中“教授”、“副教授”相关记录；如果我们要模糊查询“副”，期望结果只命中“副教授”的相关记录。也就意味着“教授”的密文中需要保留“教”的密文特征，也需要保留“授”的密文特征，那我们很容易想到，“教授”的明文一定是“教”的密文与“授”的密文通过某种方式拼接而成。简单举例来说，假设“教”的密文是A，“授”的密文是B，“副”的密文是C，那么“副教授”就一定是CAB三个明文的某种组合，教授也一定是AB这样的简单组合。

大家可以通过分析下面这个表格中的内容，猜一猜“讲授”这个词语在数据库中呈现出的密文是怎样的，是不是很容易就能想到呢？这样的DB能安全到哪里去呢！

也就是说，用确定性加密来实现密文模糊索引，本质上是“字符”级的确定性加密，而非字段级，攻击者很容易先通过密文的统计分析，逐个识别每个密文所代表的“字符”，最后汇集成一本“字符字典”，咱们的数据库密文也就很容易被逐字符破解，那真的是相当危险！

综上所述，确定性加密，以及基于该加密思路衍生出的密文索引技术，密文模糊查询技术，在数据库加密场景中真的是一点er也不安全！

因此，对于需要高安全性的数据库加密场景，我们建议使用非确定性加密的方式（如在加密过程中加入随机salt），使得同样的明文和密钥，密文也不相同。与此同时，我们还应该尽可能增大我们加密时分组的明文空间，并避免在索引中暴露明文特征。

以我们常用的SM4、AES等分组加密算法为例，我们应该尽可能避免对数据项、列数据使用同一密钥进行单独加密，因为这些数据在编码、分组后，形成的明文分组集合，规模往往较小，其密文集合也就非常小。所以我们应该根据实际的应用场景，至少采用记录级、表级甚至数据库级的加密粒度，因为这样我们的明文分组可以尽可能地保证随机性，从而最大化我们的明文空间，进而增加密文空间，尽可能地保证加密数据的安全性。