加密数据库查询答案

【问题标题】：Encrypted database query加密数据库查询
【发布时间】：2010-09-15 22:02:51
【问题描述】：

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

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

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

前端用于访问加密/解密密钥而后端仅用于存储和查询的应用程序。
拥有一个您无法访问的几个字段的数据库，例如，让我们说“地址”，它通常是 text/varchar。
您无权访问解密信息的密钥，所有信息到达数据库时都已加密。

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

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

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

有人能给我指出一个继续思考的方向吗？

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

只是提供一些信息：

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

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

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

新问题：

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

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

【问题讨论】：

当我说“什么”时，我想我代表了这里的每个人
是的，我不明白这个问题。您是否在问是否需要更多计算来搜索加密字符串而不是纯文本字符串？
大声笑我的第一个问题：p

标签： sql database encryption theory

【解决方案1】：

您可以按照您描述的方式进行操作 - 例如，有效地查询哈希，但具有该要求的系统并不多，因为此时安全要求会干扰系统可用的其他要求 - 即没有部分匹配，因为加密规则。压缩也是同样的问题。多年前，在一个非常小的环境中，我必须先压缩数据，然后才能将其放入数据格式中。当然，这些字段不容易被搜索到。

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

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

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

【讨论】：

【解决方案2】：

你想使用 md5 散列。基本上，它会将您的字符串转换为无法复制的哈希值。然后，您可以稍后使用它来验证事物。例如：

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "INSERT INTO addresses (address) VALUES ('" . md5($salt . $address) . "')";
mysql_query($sql);

然后，在将来验证地址：

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "SELECT address FROM addresses WHERE address = '" . md5($salt . $address) . "'";
$res = mysql_query($sql);
if (mysql_fetch_row($res))
    // exists
else
    // does not

现在它已在数据库端加密，因此没有人可以找到它 - 即使他们查看了您的源代码。但是，找到盐会帮助他们解密它。

http://en.wikipedia.org/wiki/MD5

【讨论】：

仅供参考，MD5 不是一个非常安全的哈希。您可能想使用类似 SHA-256 的东西，但想法是一样的。

【解决方案3】：

如果您需要存储稍后要查询的敏感数据，我建议您以纯文本形式存储，尽可能限制对这些表的访问。

如果您不能这样做，并且您不想在前端产生开销，您可以在后端制作一个组件，在服务器中运行，以处理加密数据。

查询加密数据？如果您使用的是良好的加密算法，我无法想象如何做到这一点。

【讨论】：

【解决方案4】：

为什么不加密保存数据库表的磁盘，加密数据库连接，让数据库正常运行？

[我不太了解需要这种偏执程度的背景/限制]

编辑：“法律约束”是吗？我希望你没有参与任何违法的事情，我不想成为一个不经意的附属品...... ;-)

如果 - 咳咳 - 法律限制 - 强制使用此解决方案，那么要做的就是这些 - 没有 LIKE 匹配，并且如果客户端机器无法处理它，则响应缓慢。

【讨论】：

【解决方案5】：

几个月前我遇到了同样的问题：整个数据库（索引除外）都被加密了，并且出现了部分匹配的问题。

我在互联网上搜索了一个解决方案，但似乎对此没有什么可做的，而是一个“解决方法”。

我最终采用的解决方案是：

创建一个临时表，其中包含正在执行查询、解密的字段的数据以及作为表的主键的另一个字段（显然，该字段不必按原样解密纯文本）。
对该临时表执行部分匹配并检索标识符。
在真实表中查询这些标识符并返回结果。
删除临时表。

我知道这会带来不小的开销，但是当数据库必须完全加密时，我还没有找到另一种方法来执行此任务。

根据每个特定情况，您可以过滤插入临时表的行数，而不会丢失结果数据（仅考虑那些属于执行查询的用户的行，等等。 ..)。

【讨论】：