SQL Server格式保留加密

Question

我有一个带有数据库的旧系统，该数据库的表具有char（20）类型的列，客户决定为某些业务需要对该列进行加密，但是对于某些系统集成，输出列的长度必须与输入的长度相似，即20，我已经读过Format-Preserving encryption

我的问题是，保留格式的加密是否像AES方法一样强大，并且是否存在任何可用于数百万条记录的SQL Server实现？

Answer 1

您可以建立基于AES的安全保留格式的加密。 Here是我对另一个问题的回答，在该示例中，我展示了使用AES作为构建块来实现格式保留加密的代码。有关如何完成加密的详细信息，请参见斯坦福大学Boneh教授关于格式保留加密的this lecture。

Answer 2

FPE的问题是您

无法告知该字段是否已加密。它通常用于信用卡号，但是即使不是原始号码，它的FPE版本的信用卡号也被盗了，即使它不是原始号码，它仍然可以是有效的信用卡号，并被恶意人员使用。

FPE是否像AES一样强，答案是肯定的。与在300字符串上使用FPE相比，在3字符串上使用AES 256加密效果很差。但这将比AES生成速度慢。 AES加密时几乎具有稳定的速度，您可以估计所需的时间取决于字符串的长度，并且输出

NOT

将为人类可读/可用。没有真正通过加密运行但仅为了说明区别的示例如下：

名称：Frank Stall

使用FPE加密

名称：Steve Moore

即使名称已成功加密，但仍是想要窃取身份的人可以使用的有效值（请记住，这只是为了说明区别）。从结果中您可以直观地看出该值是一个名称，但是您自己也可以，即使您知道它也无法知道它是否已加密。

使用AES加密

名称：WOa8+6KskFZ7IdNYgZ3+9BGDJrVfSVd61dDcX1JcVK8=

正如您所看到的，如果您看的是基本AES加密的结果，则字符串长度不一定匹配，因此该值不可能人为地猜测是什么。你怎么能知道这不是我的生日，我只是放在那儿而不是名字。

Answer 3

我将对该声明表示严重的例外：“即使它不是原始号码，它仍然可以是有效的信用卡号码，并且可以被恶意用户使用。”作为使用FPE的“弱点”而提供的这一说法完全没有价值。尽管使用FPE加密的信用卡号看起来仍然像是有效的信用卡号，但它比其他任何随机生成的16位数字都不再是有效的信用卡号。说FPE加密的信用卡号的语料库仍然可以被“恶意人员使用”，就是说任何16位随机数的集合也都具有“危险性”，因为它们

might恰好对应于一些真实的信用卡号。

[FPE结果名称史蒂夫·摩尔（Steve Moore）的观点也是如此，“仍然是想要窃取身份的人可以使用的有效值。”同样，请确保身份窃贼可以出于某种邪恶目的尝试使用该名称。但是，他们使用完全随机的虚构名字的风险并不比身份反派分子只是随机虚构名字本身的风险高。窃取FPE加密的（因此是完全随机的）名称，出生日期，邮政编码，信用卡号等语料库，对于身份盗窃者而言，比起他们只是首先构成数据而言，没有更多的价值。

但是，我同意FPE的一个棘手方面是，就数据本身是否被加密而言，它在数据本身中并不是固有的明显特征。这可能会带来一些问题，即管理数据的人员可能会错误地使用数据，就好像它是真实数据一样，或者相反，如果丢失了加密步骤，则可能不会意识到并因此暴露了未加密的数据。但是，解决方案是更好地管理相关的元数据，以获取信息的加密状态。