您正在寻找的是确定性加密：加密两次的相同值给出相同的输出。给定使用密钥 K 的确定性加密，攻击者将需要该密钥来确定哪个 SSN 映射到哪个加密值。您仍然可以对确定性加密的数据执行搜索，但只能进行等效比较 (==, !=)。

可行的确定性加密示例：

• ECB模式下的分组密码，如果数据小于 1 个分组长
• CBC模式下的分组密码，带有静态IV。
• CBC模式下的分组密码，带有从明文派生的IV 。（请注意，此时您不想存储 IV，因此无法在没有明文的情况下进行解密，因此这是仅搜索选项。）

什么不起作用：

• 具有静态 IV 的CTR模式（然后攻击者可以使用多个密文来恢复密钥流和明文）
• 带有随机 IV 的 CBC 模式（无法搜索）
• 任何流密码（与 CTR 模式相同）

请注意，在所有情况下，您都放弃了密文不可区分性，但这是能够搜索密文的核心要求。

您确实需要一种机制来与需要访问明文的其他系统共享密钥，但是获得对数据库备份、SQL 注入或任何其他仅授予对数据库访问权限的攻击的访问权限的攻击者将无法辨别明文。

正如您所指出的，PKI在这里没有用，因为如果您使用的是确定性 PKI 密码系统（例如普通、未填充、RSA），则拥有公钥允许枚举值并恢复它们。使用非确定性 PKI（填充 RSA）将不允许您搜索密文。

我会审查您是否真的需要加密小的、容易暴力破解的明文。你的威胁模型是什么？您能否以其他方式防范这些威胁？

请记住，有两个独立的部分来保护这些数据，当它处于静止状态和在传输中时。

您不应直接以明文形式存储（静态数据）任何类型的敏感数据。密码和社会保障以及信用卡号码等内容在存储到磁盘之前应进行加密。我同意 lorenzog 关于解耦您的解决方案，但我建议稍微不同的设置：

1. 数据库服务器。该服务器将敏感的加密字段存储在数据库 (SQL/MySQL/Oracle) 中，但从来没有明文数据。它将在存储在数据库表/字段中之前被加密。它也没有解密数据的私钥，只有加密的 blob。

2. 加密应用服务器。此服务器存储用于加密和解密经过身份验证的授权用户的字段的私钥。这是存储在数据库服务器中的数据唯一可以加密和解密的地方。显然，这将是一个高资产目标，应该通过政策来加强和控制。例如，类似于域控制器并审核对其的所有访问和查询。

3. 网络服务器。负载平衡来自用户的请求以及服务器和服务之间的安全通信。作为与外部用户通信的端点。

与客户和您的合作伙伴团队的沟通（传输中的数据）在这里也非常重要，不要忽视这一点。确保您使用 SSL 并尽可能使用最高级别的密码和加密。

设置起来并不容易（肯定比没有基本安全更难，但无论如何也不是不可能），如果你违反了客户的信任，你的状态将比正确保护个人数据所需的时间更糟糕. :)

祝你好运！

实际上，您在问题中暗示了三个问题。

• 标题谈论的是静态数据。
• 在问题中，您也谈到了访问控制。
• 此外，您还会遇到传输中的数据问题。

如果您已经在使用数据库系统并在现有系统中引入加密，那么这个问题可能会有不同的答案。许多数据库系统现在支持这样的安全特性（见下文）。

访问控制和传输中的数据

大多数数据库系统从第一天起就支持访问控制（这几乎是最低要求）。但是，当您说某某系统需要能够读取它时，这实际上是一个访问控制问题。

同样，传输中的数据也是所使用协议的问题，其中许多由现有的数据库系统支持。例如，SQL Server支持 SSL进行连接，MySQL也是如此。（搜索其他人，他们可能也会支持。）

静态加密

第三个是静态加密，它解决了如果未经授权的人或系统要获取实际的数据库文件，他们会看到什么的问题。它还涉及密钥管理的相关问题，即为什么获得您的数据库文件的人不能获得密钥？

在设最终转移到AES）。即使它不能是 0 成本，也必须有一条路径，尤其是。如果您的数据库将成为分布式数据库，请更改算法或密钥。

许多数据库现在确实提供静态加密以及一些密钥管理解决方案。例如 SQL Server自 2008 年以来就支持加密。此外，SQL Server 也发布了一个密钥生命周期管理故事，显然支持对称和非对称密钥（通过证书）。我相信 SQL 还支持完整的数据库加密与通过查询选择的字段（例如您的 SSN 情况）。

同样，MySQL 也支持通过查询函数进行加密，您可以将其用于您的 SSN 场景。您也可以使用其他可能已经支持加密的数据库系统并使用它们。

如果您使用支持内置加密的系统，您可能会避免许多与自己操作相关的陷阱，并获得受支持的系统。

研究数据库

CryptDB是麻省理工学院开发的数据库系统，它对静态数据进行加密，还支持对加密数据运行查询。如果您查看该系统的页面，它会列出实际使用它的组织。

编写自己的加密逻辑

这可能更耗时且更具挑战性，但根据您的问题，您似乎正在考虑这是一个问题。如果我处于类似情况，我肯定会避免使用现有的数据库系统之一。

有很多问题。例如，当您加密数据时，输出有些随机化，因此使用相同密钥加密相同数据通常不会产生相同的密文。这可能有点挑战性，您可能必须降低熵（例如，通过使用相同的 IV 或盐），这可能会影响系统的安全性。通过存储哈希（甚至是使用单个密钥的 HMAC）之类的简单操作，如果有人获得了数据库文件，他们可以在数周甚至数天内使用蛮力恢复数据。对于 SSN 之类的字段尤其如此，除非您要花时间并且总是需要多个字段进行查询（例如 SSN 和 DOB 以及姓氏的前三个字母，或此类组合），并且仅将这些字段存储为散列但两者都不是这些分开。

除此之外，还必须弄清楚关键的生命周期管理问题。

编辑：这实际上是一个常见问题，我曾经评估过加密数据，当我写最初的回复时，我没有在这里包括。此后，我更新了我的回复以包括这一点，并阐明了访问控制、安全连接和静态数据问题。

How to safely store sensitive data like a social security number?
...
Must be able to search (i.e. to look up an existing piece of data) but not view
...

同态加密将允许对加密数据进行排序和搜索。微软和 IBM 都有系统。但我还没有在主流生产中看到它们（还）。例如，参见（标准）LWE 的高效全同态加密。它还满足您的其他两个要求 - 可逆性和性能。

如果您不需要PRP 的安全概念，请使用分组密码。您甚至可以使用格式保留加密 (FPE) 方案。例如，请参阅Order-Preserving Encryption Revisited - 改进的安全分析和替代解决方案，甚至是格式保留加密的概要，以了解一些想法。

我不确定如何理解“其他系统必须能够恢复实际价值”（可逆性除外）。你能解释一下数据流吗？天真地，我会说对加密数据执行选择，解密数据，在远程系统的公钥下加密数据，然后将加密数据发送到远程系统。

但是我认为攻击者可以将加密过程用作预言机并由于其低熵而恢复数据。

如果它缺乏 PRP 的安全概念，它就会泄露信息；不是因为像 SSN 这样的低熵数据。例如，RSA/OAEP 可以有效地屏蔽 SSN。坏人没有比猜测更多的优势（放弃一些手）。

您还需要一个存储私钥的策略。也许是 HSM 或 KMIP。Guttman 在他的《工程安全》一书中对 HSM 和其他存储设备（例如支持 KMIP 协议的硬件）提出了一些有趣的想法。