对单个文件加密是不是无法做到绝对安全?

2021-05-20 11:23:34 +08:00
 join
我想设计一个文件格式,需要满足以下特点:
1. 加密,能多安全有多安全。
2. 可以对整个文件搜索。
3. 数据一直是增量的,但不会增长太块,假设每天增长 100kb 好了。
4. 这个文件可以同步放到公有云上面。
5. 用户可以使用弱密码,因为频繁使用强密码很难记得住,输入也麻烦。

现在我认为自己可能有几个逻辑上的悖论:
1. 加密和搜索是冲突的,如果我要做搜索功能,需要解密所有数据,然后临时放到磁盘或内存,这一步就很难保证安全。
2. 弱密码和绝对安全是冲突的,我设计的是加密文件格式,理论上拿到这个文件后暴力穷举就可以了。否则只能做到像 bitcoin 那样使用复杂的密码增加暴力破解的难度。
3. 如果数据是增量的,数据越大,搜索就会越耗时间。写入和读取可分区块来做。
3931 次点击
所在节点    信息安全
30 条回复
cmdOptionKana
2021-05-20 11:35:51 +08:00
- 如果一个文件加密了,就必须先解密,才能搜索。
- 可以用一个文件来当作密码,这个文件你可以放在 U 盘里,或者只要没有人知道哪个文件是密钥即可。这样你就不用记住密码,只需要记住文件名(这个好记)。
- 如果你使用的设备不安全,那么你总是不安全的,比如,你加密之前总得在屏幕上看到加密前的内容吧,如果你担心安全性,你的屏幕可能被暗中录屏。
- 绝大多数情况下,不需要担心到这个程度,如果需要这么高的保密性,你应该使用一台永不联网的设备。
bertonzh
2021-05-20 11:38:02 +08:00
如果认为用户本地安全的话,强密码可以放在本地,用弱密码加密
Mitt
2021-05-20 11:42:34 +08:00
文件加密这一块应该交给文件系统而不是自己造,对于上传到云盘本身就不会对内容检索的话可以在同步的时候进行加密处理,如果一定要做文件格式的话,我觉得搜索方面就只能建立索引公开了,但是这样又会暴露部分内容而且会让文件大小骤增,至于暴力破解这个没办法,只能加强算法减缓暴力破解速度,总的来说对于加密文件格式的需求不常见,大多数还是更需要通用方案,比如磁盘加密+同步加密 就足够了
vk42
2021-05-20 11:45:44 +08:00
先分析清楚你的威胁模型,划分清楚哪些是可信的,哪些是不可信的。比如按你描述本地磁盘和内存都不可信的话,只能上 TEE 环境了,甚至可能还没法满足你的要求……
dallaslu
2021-05-20 11:48:16 +08:00
如果既能加密,又能全文搜索,既然放到了公有云上,那么能如果被人(比如平台管理员)用某个词搜到了,那么他是不是可以暴力尝试搜索关键字来猜测文件内容呢?

既然加密,理论上就不能全文搜索。但是可以制作一些索引来辅助。当然这个索引仍然会泄漏关键词。再进一步,对全文分词后,逐个加盐做 hash,勉强能做到可以搜索的同时又不那么容易地泄露内容。
join
2021-05-20 11:49:51 +08:00
@vk42 假设磁盘和内存都是可信的。那么按照楼上 @cmdOptionKana 的做法使用一整个文件做为 key 防止暴力暴力破解。 那么我的文件格式是不是可以直接用 sqlite 这种嵌入式数据库?我直接对整个 sqlite 文件进行加密,解密,问题就非常简单了。我也不用关心搜索的问题了。
join
2021-05-20 11:53:07 +08:00
@dallaslu 搜索笨一点,用线性搜索好了,不加索引。按照我这个数据增长量
100k * 365 * 100 = 3.6G
即使 100 年后用 grep 搜索 3.6 G 的文件也可以做到秒级返回。我这样算有逻辑问题吗?
dallaslu
2021-05-20 11:54:51 +08:00
@join #6 甚至加密都不用做了,有现成的 PGP 。
join
2021-05-20 11:56:03 +08:00
按照上面的讨论,我现在的问题是不是可以过渡到直接对 sqlite 进行加密?或者我自己写一个更简单的数据结构,再对这个数据结构进行加密?
summerwar
2021-05-20 11:56:32 +08:00
讨论请限定场景和条件,包括但不限于操作系统、用途等,不然讨论了也没有意义,不存在的、假设的事情,讨论到 3021 年也不会出结果。

有时候不是一定要求最优解,只是要求在一定条件下能够实现就好了
join
2021-05-20 11:58:18 +08:00
@summerwar 其实这个场景限制得很简单了,每天最多产生 100kb 的数据,然后在个人电脑上。用户可以把一个加密的文件放到任意的公有云上而不被破解。
vk42
2021-05-20 11:59:42 +08:00
@join 那就太简单了,也不存在弱密码问题,直接上密钥加密,本地直接明文,离开本地的时候加密就行了。但你这个模型其实已经不现实了,现在比较实际的威胁模型会认为本地环境是部分可信。常规认为外存(文件系统)不能存明文,内存在不考虑冷启动攻击和侧信道的情况下可以认为是大致可靠的,然后关键数据如加密密钥存在 TEE 或 TPM 里面……
momocraft
2021-05-20 12:00:32 +08:00
不限于搜索, 如果某个地方需要原数据则总归要在某台机器解密, 如果解密是"不安全"那基于加密的东西都不安全

如果永远不需要解密, 比如只要搜索有无结论不需要使用, 可以存个无法还原的 hash
JerryCha
2021-05-20 12:01:22 +08:00
加密和搜索好像不冲突,但是当心被人猜出明文
sillydaddy
2021-05-20 12:02:33 +08:00
@join
加密的数据,是可以搜索的。并且搜索过程不会泄漏任何信息。
——所谓的“全同态加密”(Fully Homomorphic Encryption)。

/t/700927

不过现在速度和开销很大。基本上 1Byte 数据加密后就变成了 KByte~MByte 的级别,运算速度下降千百万倍??瞎猜的。 只能期待后续算法的改进和突破了。
codehz
2021-05-20 12:05:53 +08:00
summerwar
2021-05-20 12:06:06 +08:00
sqlite 支持加密 然后加密就好了
sillydaddy
2021-05-20 12:06:07 +08:00
@sillydaddy #15
如果仅仅是“完全匹配”式的搜索的话,甚至都不用“全同态”,只要部分同态就可以了,这样速度会提高很多。但实际用起来还是很慢。可以看一下上面链接里面,IBM 的演示视频,就是拿搜索做的演示。
vk42
2021-05-20 12:08:00 +08:00
@sillydaddy 同态加密现在还主要在学术圏灌水阶段,应用有限。而且和 lz 需求并不太符合,lz 是要本地搜索。
ktblack
2021-05-20 12:09:08 +08:00
参考论文的摘要,放出一部分内容用来搜索,正文加密保存

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/778090

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX