加密数据库查询

Question

我刚刚发现了 Stack Overflow，我只是在检查我和一些朋友在一个项目中是否有关于约束的想法，尽管这更多是我一直试图找到的理论问题一段时间的答案。

我对密码学不太了解，但如果我不够清楚，我会尝试编辑/评论以澄清任何问题。

尽量简短，环境是这样的：

• 前端用于访问加密/解密密钥而后端仅用于存储和查询的应用程序。

• 拥有一个您无法访问几个字段的数据库，例如让我们说“地址”，它像往常一样是 text/varchar 。

• 您无权访问用于解密信息的密钥，所有信息都已加密到达数据库。

主要问题是这样的，如何始终如一地对数据库进行查询，不可能做“where address like '%F§YU/´~#JKSks23%'”之类的事情。（如果有人对此有答案，请随意拍摄）。

但是可以where address='±!NNsj3~^º-:'吗？或者它也会完全吃掉数据库？

另一个可能适用的限制是前端没有太多可用的处理能力，因此加密/解密信息已经开始将其推向极限。（这样说只是为了避免诸如“将表的连接导出到前端并在那里查询”之类的回复。）

有人可以指出我继续思考的方向吗？

---

嗯，感谢凌晨 4 点这么快回复，第一次使用我真的对这个社区印象深刻。（或者也许我只是针对不同的时区）

只是提供一些信息：

主要问题在于部分匹配。大多数数据库的强制性要求是允许部分匹配。主要的限制实际上是不允许数据库所有者查看数据库内部的信息。在过去的 10 分钟里，我想出了一个可能的解决方案，它再次扩展到可能的数据库问题，我将在这里添加：

允许半部分匹配的可能解决方案：

• 密码+用户的几个公共字段实际上是加密的密钥。对于身份验证，想法是加密一个静态值并在数据库中进行比较。
• 创建一组以解析方式存储信息的新表，这意味着：“第 4 街”将成为 2 个加密行（一个用于“第 4”行，另一个用于“街”）。这已经允许半部分匹配，因为已经可以在单独的表上执行搜索。

新问题：

• 这可能会再次占用数据库服务器，还是有人认为这是部分匹配问题的可行解决方案？

Post Scriptum：我没有接受 Cade Roux 的回答，只是为了进一步讨论，特别是对新问题的可能答案。

Answer 1

你可以按照你描述的方式来做——比如有效地查询散列，但是没有多少系统有这个要求，因为在这一点上，安全要求会干扰系统可用的其他要求——即没有部分匹配，因为加密规则排除了这一点。压缩也是同样的问题。多年前，在一个非常小的环境中，我不得不在将数据放入数据格式之前对其进行压缩。当然，这些字段不容易被搜索到。

在更典型的应用程序中，最终，密钥将可供链中的某个人使用——可能是 Web 服务器。

对于最终用户流量，SSL 保护该管道。一些网络交换机可以在 Web 服务器和数据库之间保护它，并且将加密数据存储在数据库中是可以的，但是您不会像那样查询加密数据。

一旦数据被显示出来，它就会出现在机器上，因此此时可以绕过任何通用计算设备，并且您在应用程序之外拥有真正发挥作用的外围防御。