假设我有一个存储加密文本的服务器（端到端：服务器永远不会看到纯文本）。
我希望能够对该文本进行全文搜索 我知道这很棘手，但我的想法是使用传统的全文设计（＆＃34;列表＆＃34;和＃34;匹配＆＃34;表格中存储单词并与内容表中的ID匹配）。当用户提交加密文本时，他们还会发送单词和相应匹配的盐渍MD5。使用的盐对每个用户都是唯一的，并从密码中恢复 （简而言之：唯一的区别是＆＃34; list＆＃34;表将包含散列词）
现在，这个系统将如何易受攻击？
请注意，我说＆＃34;多么脆弱＆＃34;而不是＆＃34;多么安全＆＃34;，因为我承认它不是完全安全的。
我理解功能（全文搜索）和安全性（从单词索引中披露一些信息）之间的权衡。例如，据我所知，能够获取列表和匹配表的攻击者可以获取有关原始加密文本的信息，可能能够通过统计分析来解读某些单词（但是，盐是唯一的对于每个用户，这需要为每个用户重复。）
这种威胁有多严重？还会有其他严重的威胁吗？
声明
我正在尝试构建（并且在密码学家的帮助下进行实际实施;现在我只是想了解这是否可行）是一种消费级产品，它将处理机密不是完全秘密的数据
我的目标只是提供足够安全的内容，以便攻击者更容易尝试窃取用户＆＃39;密码（例如，破坏客户端 - 他们最终消费者），而不是花费大量时间和计算能力来试图强制索引或运行复杂的统计分析。
（可能与其他任何回答者有关）
如您所述，其他解决方案并不可行。将所有数据存储在客户端内意味着用户无法从其他客户端访问其数据。服务器端加密可行，但随后我们无法为用户提供额外的客户端加密安全性。
唯一的真正替代方案＆＃34;只是为了不实现搜索：虽然这不是必需的功能，但对我/我们来说非常重要。
盐将以与用户完全相同的方式受到保护。解密密钥（用于解密存储文本的密钥）。因此，如果某人能够捕获盐，他或她可能也能够捕获密钥，从而产生更大的问题。
确切地说，密钥和盐将被加密存储在服务器上。它们将由客户端使用用户密码在本地解密并保存在内存中;服务器永远不会看到解密的密钥和盐。用户可以更改密码，然后他们只需要重新加密密钥和盐，而不是所有存储的文本。据我所知，这是业界非常标准的方法。
实际上，数据库的设计如下（仅报告相关条目）。这个设计就像你在评论中提出的那样。它不允许接近搜索（与我们不太相关）并且使频率不准确。
content，包含所有加密文本。列为content.id和content.text。words，包含所有哈希的列表。列为words.id和words.hash。match，匹配带有哈希/单词的文本（以一对多的关系）。列为match.content_id和match.word_id。我们必须实现删除停用词等功能。当然。这不是一个大问题（当然，将在客户端完成）。最终，这些列表对于国际（即非英语用户）用户来说一直有限 我们希望查找/插入比率非常高（即很多查找，但很少有插入，主要是批量插入）。
解密整个哈希数据库肯定是可能的，但需要强力攻击 假设盐是安全的（按照上面的第2点）。如果盐足够长（你引用32位......但为什么不是320？ - 只是一个例子）需要花费很多时间。
总结......你证实了我对频率分析可能存在风险的疑虑。但是，我觉得这种风险不是那么高。你能证实吗？
实际上，首先，每个用户的盐都是独一无二的。这意味着一个用户必须及时受到攻击
其次，通过每个文本仅报告一次单词（无论它们出现多少次），频率分析变得不太可靠
第三......例如，对散列词的频率分析并不像凯撒移位中的频率分析那样好。仅英语就有250,000个单词（而且，并非所有用户都会说英语），即使某些单词比其他单词更常见，我相信无论如何都很难做到这种攻击。 / p>
PS：我们要存储的数据是消息，如即时消息。这些都很简短，包含很多缩写，俚语等。每个人在撰写文本时都有不同的风格，进一步降低了（在我看来）频率攻击的风险。
答案 0 :(得分：9)
TL; DR：如果这需要足够安全，需要每个用户进行端到端加密：不要这样做。 < / p>
评论太长了，所以这里 - 如果我理解正确的话：
所以数据记录如下：
然后搜索你只是散列搜索词并将散列词视为单词来搜索＆＃34; text＆＃34;的段落。在第2列中。这肯定有用 - 只考虑用无意义的搜索词搜索无意义的文本。您甚至可以使用此方法对术语进行一些接近排名。
关注：
您暗示的其他方法不可接受/可行：
我理解的观点是，您的方法为用户提供了对其数据的唯一访问权限（即您无法查看/解密它）。我认为这种散列方法会充分削弱数据，以便您可以合理地计算出用户数据（也就是说，您已经降低了所需的工作量，以至于您可以在没有任何数据的情况下解密用户的信息是非常合理的。他们的钥匙/盐的知识）。我不会低估将其描述为混淆，但你应该仔细考虑这是多么重要。
如果您确定弱化系统以实现这样的搜索是有意义的，而另一种方法是不够的，那么可以帮助的一件事就是将文本中的单词的哈希存储为仅有唯一出现的单词列表（即没有频率或接近度信息可用）。这会稍微减少实现的攻击面积，但是通过将方法描述为FTS也会失去您所暗示的所需的好处。你可以获得非常快速的结果，尽管散列的单词基本上成为附加到包含它们的所有记录的标签。然后搜索查找可能变得非常快（以插入为代价）。
* 为了清楚起见 - 我希望在实施之前确保我的业务需求需要这样的东西......
修改
问题的快速示例 - 说我知道你使用的是32位盐，并且正在使用＃34;＆＃34;等常用词。 2 ^ 32种可能的盐= 40亿种可能的盐（也就是说，如果你只需要为初始攻击散列一些单词，那就不是很多了）。假设盐被附加或预先附加，这仍然只有80亿条预先计算。即使它不常见，你也不需要创建太多的列表来确保你会得到命中（如果不是这种情况，你的数据就不值得搜索）。
然后在我们每个预先计算的盐表中查找给定文本块的最高频率盐，并使用匹配来查看它是否正确解密文本中的其他单词。一旦你有一个合理的候选人为这个盐生成250,000字的英语彩虹表并解密文本。
我猜你可以在几小时到几天内解密系统中的散列数据并访问数据库。
答案 1 :(得分：2)
首先，您拥有基于密码的加密的所有常见漏洞，这些漏洞源于用户选择可预测的密码。在桌面计算时间不到两小时的情况下，在离线攻击中破解实际应用程序中超过50％的密码是很常见的。
我认为全文加密密钥是从密码派生的，或者是由密码派生密钥加密的。因此，攻击者可以针对选择的散列索引键测试猜测，一旦找到密码，就会解密所有文档。
但是，即使用户选择了高熵密码，对索引的频率分析也可能会显示很多关于纯文本的信息。虽然索引中的单词顺序丢失（如果您不支持邻近搜索），您实际上是为每个用户创建一个电子代码簿。这个指数很容易受到几个世纪以来发展良好的密码分析技术的影响。现代加密协议避免使用ECB，并提供“密文不可区分” - 每次加密时，相同的纯文本都会生成不同的密文。但这不适用于索引。
一种不太容易受到攻击的方法是在客户端上进行索引和搜索。必要的表将捆绑为单个消息并在客户端上加密，然后传输到服务器进行存储。显而易见的权衡是每次会话上该捆绑的传输成本。客户端缓存索引片段可以在一定程度上降低此成本。
最后，只有您可以权衡违规的安全成本与客户端索引的性能成本。但是，索引启用的统计分析是一个重大漏洞。
答案 2 :(得分：0)
当您设置整个数据库加密时，MSSQL Enterprise TDE会加密全文索引以及其他索引（自2008年起）。在实践中，它运行良好，没有巨大的性能损失。无法评论它是如何成为专有算法的，但是对于文档而言。
它不会覆盖你的数据库以外的任何应用程序堆栈，但是你的FTS索引将像普通文本一样工作，并且不像MySQL或PostGres那样以纯文本形式存在。从我记忆中来看，MariaDB和Oracle当然也有自己的实现。 MySQL和PGSQL没有。
至于密码，所有实现的TDE都使用AES密钥，可以轮换（虽然并不总是很容易） - 因此密码漏洞落在DBA上。
问题是您需要为MSSQL TDE的完整企业许可付费（即＆＃34;标准＆＃34;或＆＃34;基本＆＃34;云和内部部署版本中没有的功能），你做的是可能对于Oracle中的TDE也是如此。但是，如果你需要的是一个快速的解决方案并拥有企业许可的现金（可能比开发自己的实现更便宜），那么实现就在那里。