这是一个创建于 1283 天前的主题，其中的信息可能已经有所发展或是发生改变。
我想设计一个文件格式，需要满足以下特点：
1. 加密，能多安全有多安全。
2. 可以对整个文件搜索。
3. 数据一直是增量的，但不会增长太块，假设每天增长 100kb 好了。
4. 这个文件可以同步放到公有云上面。
5. 用户可以使用弱密码，因为频繁使用强密码很难记得住，输入也麻烦。
现在我认为自己可能有几个逻辑上的悖论：
1. 加密和搜索是冲突的，如果我要做搜索功能，需要解密所有数据，然后临时放到磁盘或内存，这一步就很难保证安全。
2. 弱密码和绝对安全是冲突的，我设计的是加密文件格式，理论上拿到这个文件后暴力穷举就可以了。否则只能做到像 bitcoin 那样使用复杂的密码增加暴力破解的难度。
3. 如果数据是增量的，数据越大，搜索就会越耗时间。写入和读取可分区块来做。
1. 加密，能多安全有多安全。
2. 可以对整个文件搜索。
3. 数据一直是增量的，但不会增长太块，假设每天增长 100kb 好了。
4. 这个文件可以同步放到公有云上面。
5. 用户可以使用弱密码，因为频繁使用强密码很难记得住，输入也麻烦。
现在我认为自己可能有几个逻辑上的悖论：
1. 加密和搜索是冲突的，如果我要做搜索功能，需要解密所有数据，然后临时放到磁盘或内存，这一步就很难保证安全。
2. 弱密码和绝对安全是冲突的，我设计的是加密文件格式，理论上拿到这个文件后暴力穷举就可以了。否则只能做到像 bitcoin 那样使用复杂的密码增加暴力破解的难度。
3. 如果数据是增量的，数据越大，搜索就会越耗时间。写入和读取可分区块来做。
 |
1
cmdOptionKana 2021-05-20 11:35:51 +08:00
- 如果一个文件加密了，就必须先解密，才能搜索。
- 可以用一个文件来当作密码，这个文件你可以放在 U 盘里，或者只要没有人知道哪个文件是密钥即可。这样你就不用记住密码，只需要记住文件名（这个好记）。 - 如果你使用的设备不安全，那么你总是不安全的，比如，你加密之前总得在屏幕上看到加密前的内容吧，如果你担心安全性，你的屏幕可能被暗中录屏。 - 绝大多数情况下，不需要担心到这个程度，如果需要这么高的保密性，你应该使用一台永不联网的设备。 |
 |
2
bertonzh 2021-05-20 11:38:02 +08:00
如果认为用户本地安全的话，强密码可以放在本地，用弱密码加密
|
 |
3
Mitt 2021-05-20 11:42:34 +08:00
文件加密这一块应该交给文件系统而不是自己造，对于上传到云盘本身就不会对内容检索的话可以在同步的时候进行加密处理，如果一定要做文件格式的话，我觉得搜索方面就只能建立索引公开了，但是这样又会暴露部分内容而且会让文件大小骤增，至于暴力破解这个没办法，只能加强算法减缓暴力破解速度，总的来说对于加密文件格式的需求不常见，大多数还是更需要通用方案，比如磁盘加密+同步加密 就足够了
|
 |
4
vk42 2021-05-20 11:45:44 +08:00
先分析清楚你的威胁模型，划分清楚哪些是可信的，哪些是不可信的。比如按你描述本地磁盘和内存都不可信的话，只能上 TEE 环境了，甚至可能还没法满足你的要求……
|
 |
5
dallaslu 2021-05-20 11:48:16 +08:00
如果既能加密，又能全文搜索，既然放到了公有云上，那么能如果被人（比如平台管理员）用某个词搜到了，那么他是不是可以暴力尝试搜索关键字来猜测文件内容呢？
既然加密，理论上就不能全文搜索。但是可以制作一些索引来辅助。当然这个索引仍然会泄漏关键词。再进一步，对全文分词后，逐个加盐做 hash，勉强能做到可以搜索的同时又不那么容易地泄露内容。 |
 |
6
join OP @vk42 假设磁盘和内存都是可信的。那么按照楼上 @cmdOptionKana 的做法使用一整个文件做为 key 防止暴力暴力破解。 那么我的文件格式是不是可以直接用 sqlite 这种嵌入式数据库？我直接对整个 sqlite 文件进行加密，解密，问题就非常简单了。我也不用关心搜索的问题了。
|
|
7
join OP @dallaslu 搜索笨一点，用线性搜索好了，不加索引。按照我这个数据增长量
100k * 365 * 100 = 3.6G 即使 100 年后用 grep 搜索 3.6 G 的文件也可以做到秒级返回。我这样算有逻辑问题吗？ |
|
9
join OP 按照上面的讨论，我现在的问题是不是可以过渡到直接对 sqlite 进行加密？或者我自己写一个更简单的数据结构，再对这个数据结构进行加密？
|
 |
10
summerwar 2021-05-20 11:56:32 +08:00
讨论请限定场景和条件，包括但不限于操作系统、用途等，不然讨论了也没有意义，不存在的、假设的事情，讨论到 3021 年也不会出结果。
有时候不是一定要求最优解，只是要求在一定条件下能够实现就好了 |
|
11
join OP @summerwar 其实这个场景限制得很简单了，每天最多产生 100kb 的数据，然后在个人电脑上。用户可以把一个加密的文件放到任意的公有云上而不被破解。
|
|
12
vk42 2021-05-20 11:59:42 +08:00
@join 那就太简单了，也不存在弱密码问题，直接上密钥加密，本地直接明文，离开本地的时候加密就行了。但你这个模型其实已经不现实了，现在比较实际的威胁模型会认为本地环境是部分可信。常规认为外存（文件系统）不能存明文，内存在不考虑冷启动攻击和侧信道的情况下可以认为是大致可靠的，然后关键数据如加密密钥存在 TEE 或 TPM 里面……
|
 |
13
momocraft 2021-05-20 12:00:32 +08:00
不限于搜索, 如果某个地方需要原数据则总归要在某台机器解密, 如果解密是"不安全"那基于加密的东西都不安全
如果永远不需要解密, 比如只要搜索有无结论不需要使用, 可以存个无法还原的 hash |
 |
14
JerryCha 2021-05-20 12:01:22 +08:00
加密和搜索好像不冲突，但是当心被人猜出明文
|
 |
15
sillydaddy 2021-05-20 12:02:33 +08:00  1
|
 |
16
codehz 2021-05-20 12:05:53 +08:00
|
|
17
summerwar 2021-05-20 12:06:06 +08:00
sqlite 支持加密 然后加密就好了
|
|
18
sillydaddy 2021-05-20 12:06:07 +08:00
@sillydaddy #15
如果仅仅是“完全匹配”式的搜索的话，甚至都不用“全同态”，只要部分同态就可以了，这样速度会提高很多。但实际用起来还是很慢。可以看一下上面链接里面，IBM 的演示视频，就是拿搜索做的演示。 |
|
19
vk42 2021-05-20 12:08:00 +08:00
@sillydaddy 同态加密现在还主要在学术圏灌水阶段，应用有限。而且和 lz 需求并不太符合，lz 是要本地搜索。
|
 |
20
ktblack 2021-05-20 12:09:08 +08:00 via Android
参考论文的摘要，放出一部分内容用来搜索，正文加密保存
|
|
21
sillydaddy 2021-05-20 12:13:14 +08:00
@vk42 >“而且和 lz 需求并不太符合，lz 是要本地搜索”
楼主说的是“加密和搜索是冲突的，如果我要做搜索功能，需要解密所有数据，然后临时放到磁盘或内存，这一步就很难保证安全。” 意思就是，楼主想在不解密的情况下，实现一些操作，这样尽量减少暴露明文数据的风险。如果这样理解的话，全同态加密就是为了做这个事情的。本地或者云，差别不大——因为它们都不被楼主信任。 |
|
22
join OP @sillydaddy 其实也不用做到你说的这样。从用户的角度考虑，我需要在搜索的同时保证数据安全，只要能保证解密后的数据临时存放的那个地方安全就可以了。
|
|
23
vk42 2021-05-20 12:18:06 +08:00
按 lz 后面#6 的补充来看他并没有需要本地不可信。本地完全不可信那这个问题就没有意义了，你要在哪里做明文加密呢？另外本地环境比同态方便得多的 TEE 方案很多，真没怎么见过在本地用同态的……
|
 |
24
0TSH60F7J2rVkg8t 2021-05-20 12:26:39 +08:00
楼主可参考 Cryptomator 的安全方案：
https://docs.cryptomator.org/en/latest/security/architecture/ |
 |
25
swulling 2021-05-20 12:37:20 +08:00
如果条件是
> 本地绝对可信，只需要保证用户可以把一个加密的文件放到任意的公有云上而不被破解 那干脆本地放弃加密，在上传的时候对称加密即可，密钥保存到本地。 |
|
26
join OP |
 |
27
chinvo 2021-05-20 13:36:46 +08:00 via iPhone
同态加密可以对密文进行运算和检索.
|
 |
28
way2explore2 2021-05-20 13:50:42 +08:00 via Android
同态加密了解一下，如果题主能实现高性能同态加密，我一定投你
|
 |
29
no1xsyzy 2021-05-20 14:08:46 +08:00
KeePass 就是单文件加密，只在本地解密
可以用密钥文件来防止暴破数据库，需要分开存储（比如把密钥文件放在随身的 U 盘里，要暴破还需要同时去暴破这些比特比如 1024 bit ）。 远端搜索的话只能靠同态加密了。但是再怎么同态，总会粗略暴露「搜索的命中次数」（通过搜索结果的大小） 那样的话用户追踪仍然是有迹可循的。 |
 |
30
ochatokori 2021-05-20 15:01:10 +08:00
如果加密方法不和内容位置相关的话是不是可以做到加密搜索？
比如 明文: abcdef 加密方法: (a,密钥)=>1,(b,密钥)=>2... 密文：123456 那搜索的时候只要(关键词,秘钥)=>密文关键词 在密文里面搜索 密文关键词 然后再解出来这样 |
Select Language