全文搜索加密数据

假设我有一个存储加密文本的服务器(端到端:服务器永远不会看到纯文本).

我希望能够对该文本进行全文搜索.
我知道这很棘手,但我的想法是使用传统的全文设计("列表"和"匹配"表,其中单词存储并与内容表中的ID匹配).当用户提交加密文本时,他们还会发送单词和相应匹配的盐渍MD5.使用的盐对每个用户都是唯一的,并从密码中恢复.
(简而言之:唯一的区别是"list"表将包含散列词)

现在,这个系统有多脆弱？
请注意,我说"多么脆弱"而不是"多么安全",因为我承认它不是完全安全的.
我理解功能(全文搜索)和安全性(从单词索引中披露一些信息)之间的权衡.例如,据我所知,能够获取列表和匹配表的攻击者可以获得有关原始加密文本的信息,并且可能能够通过统计分析来解读某些单词(但是,对于每个用户来说,这是唯一的盐,这将需要为每个用户重复).

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

免责声明
我正在努力建立(并在密码学家的帮助下进行实际实施;现在我只是想了解这是否可行)是一种消费级产品,它将处理机密而不是完全保密数据.
我的目标只是提供足够安全的东西,以便攻击者更容易尝试窃取用户的密码(例如,破坏客户端 - 他们最终是消费者),而不是花费大量时间和计算能力尝试蛮力指数或运行复杂的统计分析.

回应@Matthew的评论

(可能与其他人回答相关)

如您所述,其他解决方案并不可行.将所有数据存储在客户端内意味着用户无法从其他客户端访问其数据.服务器端加密可以工作,但是我们将无法为用户提供额外的客户端加密安全性.
唯一的"真正替代方案"就是不实现搜索:虽然这不是必需的功能,但对我/我们来说非常重要.

盐将以与用户的解密密钥(用于解密存储的文本的密钥)完全相同的方式受到保护.因此,如果有人能够捕获盐,他或她可能也能够捕获关键,从而产生更大的问题.
确切地说,密钥和盐将以加密方式存储在服务器上.它们将由客户端使用用户的密码在本地解密并保存在内存中; 服务器永远不会看到解密的密钥和盐.用户可以更改密码,然后他们只需要重新加密密钥和盐,而不是所有存储的文本.据我所知,这是业界非常标准的方法.

实际上,数据库的设计如下(仅报告相关条目).这个设计就像你在评论中提出的那样.它不允许接近搜索(与我们不太相关)并且使频率不准确.

表content,包含所有加密文本.列是content.id和content.text.

表words,包含所有哈希的列表.列是words.id和words.hash.

表match,匹配带有哈希/单词的文本(以一对多的关系).列是match.content_id和match.word_id.

我们必须实现删除停用词等功能.当然.这不是一个大问题(当然,将在客户端完成).最终,这些列表对于国际(即非英语用户)用户来说一直有限.
我们希望查找/插入比率非常高(即很多查找,但很少有插入,主要是批量).

解密整个哈希数据库肯定是可能的,但需要强力攻击.
假设盐是安全的(按照上面的第2点).如果盐足够长(你引用32位......但为什么不是320？ - 只是一个例子)需要花费很多时间.

总结......你证实了我对频率分析可能存在风险的疑虑.但是,我觉得这种风险并不是那么高.你能证实吗？
实际上,首先,每个用户的盐都是唯一的.这意味着一个用户必须及时受到攻击.
其次,通过每个文本仅报告一次单词(无论它们出现多少次),频率分析变得不太可靠.
第三......例如,散列词的频率分析听起来不像凯撒移位的频率分析那么好.仅英语就有250,000个单词(并且,并非所有用户都会说英语),即使某些单词比其他单词更常见,我相信无论如何都很难做到这种攻击.

PS:我们要存储的数据是消息,如即时消息.这些都很简短,包含很多缩写,俚语等.每个人在撰写文本时都有不同的风格,进一步降低了频率攻击的风险(在我看来).