SQL Server保格式加密
本文关键字：加密 格式 Server SQL | 更新日期: 2023-09-27 17:49:25
我有一个旧的系统，数据库中有一个列类型为char(20)的表，客户决定对该列进行加密，以满足某些业务需求，但对于某些系统集成，需要输出列的长度与输入列的长度相似，为20，我读过关于保持格式加密
我的问题是，保存格式的加密是否像AES方法一样强大，是否有任何SQL Server实现可以用于数百万的大量记录?
您可以构建基于AES的安全的保持格式的加密。下面是我对另一个问题的回答，其中我展示了使用AES作为构建块实现保持格式加密的代码。请参阅斯坦福大学Boneh教授关于保持格式加密的讲座，详细了解如何做到这一点。
FPE的问题是您无法告诉字段是否已加密。它通常用于信用卡号码，但FPE版本的信用卡号码，如果它是被盗的，即使它不是原来的号码，它仍然可以是一个有效的信用卡号码，被恶意的人使用。
FPE是否和AES一样强?答案是肯定的和否定的。FPE在3个字符的字符串上是一个非常糟糕的加密，相反，如果你在300个字符的字符串上使用它，那么它可能会超过AES 256。但这比AES的生成速度要慢。AES在加密时几乎有稳定的速度，您可以根据字符串长度估计所需的时间，输出将NOT是人类可读/可用的。
示例并没有实际运行加密，只是为了说明它们之间的区别如下:
名称:Frank Stall
使用FPE加密
名称:Steve Moore
即使名称已经成功加密，它仍然是一个想要窃取身份的人可用的有效值(记住这只是为了说明区别)。从结果中，你可以直观地看出该值是一个名称，但是你自己，即使你知道它，你也无法判断它是否加密。
使用AES加密
名称:WOa8+6KskFZ7IdNYgZ3+9BGDJrVfSVd61dDcX1JcVK8=
正如您所看到的，如果您查看基本AES加密的结果，字符串长度不一定匹配，值是不可能人类猜测它是什么。你怎么知道是不是我的生日呢?我只是把名字放在了那里。