Security 加密数据的全文搜索

假设我有一个存储加密文本的服务器（端到端：服务器从不看到纯文本）

我希望能够对该文本进行全文搜索。
我知道这很棘手，但我的想法是使用传统的全文设计（“列表”和“匹配”表，其中存储单词并与内容表中的ID匹配）。当用户提交加密文本时，他们还会发送单词和相应匹配项的附加MD5。所使用的salt对于每个用户都是唯一的，并且可以从他们的密码中恢复。
（简而言之：唯一的区别是“list”表将包含散列字）

现在，这个系统会有多脆弱？
请注意，我说的是“多么脆弱”，而不是“多么安全”，因为我承认它不可能完全安全。
我确实理解功能（全文搜索）和安全性（从单词索引中披露一些信息）之间的权衡。例如，据我所知，能够获取列表和匹配表的攻击者可以获取有关原始加密文本的信息，并可能能够通过统计分析破译某些单词（但是，由于salt对于每个用户都是唯一的，因此需要对每个用户重复此操作）

这种威胁有多严重？还有其他严重的威胁吗

免责声明
我试图构建的是一款消费级产品，它将处理机密但并非完全机密的数据。
我的目标只是提供足够安全的东西，以便攻击者更容易尝试窃取用户的密码（例如，侵入客户机-最终他们是消费者），而不是花费大量时间和计算能力试图强制索引或运行复杂的统计分析

回应@Matthew的评论 （可能与任何其他回答相关）

正如你所指出的，其他解决办法是不可行的。将所有数据存储在客户端内意味着用户无法从其他客户端访问其数据。服务器端加密可以工作，但是我们无法为用户提供客户端加密的附加安全性。
唯一的“真正的替代方案”就是不实施搜索：虽然这不是必需的功能，但对我/我们来说非常重要

salt的保护方式与用户的解密密钥（用于解密存储文本的密钥）完全相同。因此，如果有人能够捕获盐，他或她很可能也能够捕获密钥，从而产生更大的问题。
准确地说，密钥和盐将加密存储在服务器上。它们将由客户端使用用户密码在本地解密并保存在内存中；服务器从未看到解密的密钥和salt。用户可以更改密码，然后，他们只需要重新加密密钥和salt，而不是所有存储的文本。据我所知，这是行业中相当标准的方法

实际上，数据库的设计如下（仅报告相关条目）。这个设计就像你在评论中提出的那样。它不允许近距离搜索（与我们无关），并降低了频率的准确性

• 表

  内容

  ，包含所有加密文本。列为

  content.id

  和

  content.text

• 表

  words

  ，包含所有哈希的列表。列为

  words.id

  和

  words.hash

• 表

  match

  ，用于将文本与哈希/单词进行匹配（一对多关系）。列为

  match.content\u id

  和

  match.word\u id

我们必须实现一些功能，比如删除stopwords等。这不是一个大问题（当然，将在客户机上完成）。最终，这些列表对国际（即非英语国家）用户的效用总是有限的。
我们预计查找/插入比率将相当高（即许多查找，但很少插入，而且大部分是批量）

解密整个哈希数据库当然是可能的，但需要暴力攻击。
假设盐是安全的（根据上面第2点）。如果盐足够长（你引用了32位，但为什么不是320位？——只是一个例子），那将需要很多时间

总之。。。你证实了我对频率分析可能存在的风险的怀疑。然而，我觉得这种风险并没有那么高。你能确认一下吗？
事实上，首先，每个用户的盐都是唯一的。这意味着一次必须攻击一个用户。
其次，由于每篇文章只报告一次单词（无论出现多少次），频率分析变得不那么可靠。
第三例如，对散列词的频率分析听起来不如对凯撒移位的频率分析好。光是英语就有250000个单词（再说一次，不是所有的用户都会说英语），即使有些单词比其他单词更常见，我相信还是很难进行这种攻击

PS：我们将存储的数据是消息，就像即时消息一样。它们很短，包含很多缩写、俚语等，每个人在书写文本时都有不同的风格，进一步降低了（我认为）频率攻击的风险。

TL；DR：如果这需要足够安全，需要每个用户端到端加密：不要这样做。

评论太长了，所以这里是-如果我理解正确的话：

您已经对用户提交的数据进行了加密（客户端加密，因此不使用DB来处理）

您希望用户能够搜索到这些内容（您对此一无所知，因此加密的文本块是无用的）

您建议的解决方案是还存储一个列表（或者