这是一个创建于 51 天前的主题，其中的信息可能已经有所发展或是发生改变。
我前段时间在少数派上写了一篇文章，里面提到了文件端到端加密，我自己设计了文件加密格式，就因为里面用到了 RSA 算法，然后某“大神”不干了。原文的链接： https://sspai.com/post/100448
大神开始的评论：
端到端加密乱入了个 RSA 非对称加密，不知道你怎么设计的总觉得很业余…
说我“业余”，然后我就很不爽。于是我写了一篇文章专门分析了我的设计逻辑： https://juejin.cn/post/7524978296394350655
跟“大神”的其他讨论在评论区可以看到。
我 TM 就不明白了，我用 RSA 只是为了把用户的密钥记录到文件里，这本身是可选项，用来帮助用户忘记密码的时候还原密码，除外，我又没有用户的文件，根本不可能获取到用户数据。
使用 RSA 就是为了防止被破解，因为 Android 应用别人可以使用调试、Hook 和反编译等方式获取加密用的密钥，并不安全。
然后这“大神”依然不依不饶。说，
其二，端到端加密从来是在可信设备上，和你 Android 反破解无关。端到端加密是保护不被中间人攻击，而不是保护数据不被客户端读取，当你说出 Android 安全显然你连端到端加密是干什么的都不知道。
我赶紧我根本看不懂他的逻辑，有种驴头不对马嘴的感觉...
最后对于我的文章和设计方案，“大神”又发表了如下高见：
我最终还是点击了你这个掘金链接，看看你的文章，然后我发现了更多离谱的问题。
1. 你用了用户密码直接拷贝来加长……
你肯定不知道什么是密钥派生函数。一般来说用户输入密码，然后程序使用特定密钥派生函数派生出 master key ，然后再用 master key 来对文件加密。
如果考虑到在用户更改密码时不重新加密解密全部文件，那 master key 还要随机生成，然后使用上述密钥派生函数派生出的 key 去加密 master key 。
我觉得你可以去了解下 bitlocker 为什么改密码不用重新解密再加密整个盘。
而且密码派生函数可以增加暴力破解时间，你自己实现的这个 while (passcode. Length < 48) ，难评。
2. 按照 aes 标准，iv 应该随机生成，至于你这个 iv 生成方式不予置评；
3. 我终于看到了你奇怪的非对称加密的用途：
「这里的实现思路是，当写入加密文件的时候将用户设置的密钥通过 RSA 算法的公钥进行加密，并将加密的结果写入到文件。当用户忘记密钥的时候，可以读取加密文件的这部分区块，然后将这部分区块经过 Base64 编码之后上传到我们的服务器。然后，在我们的服务器上面，经过 Base64 解码成字节数组之后再使用私钥解密出用户的加密密钥。」
这个奇怪的算法不是只要拿到这个被加密的文件，谁都能解密吗？加密的意义是不认识这个软件的人没法解密？
但如果只要这点要求，完全可以软件内置密钥，甚至不用用户密码不是吗？
这部分在服务器上有意义？如果是服务器还要靠用户登录来验证用户，并且每个用户有各自独立的密钥对，确实有意义。但是这又多了一个要记的登录密码——e2ee 会忘记密码，这个就不会？
4. 拼接出 passcode 也就算了，还要从服务器把这拆回去？就不能直接返回 48 字符的 passcode 吗？反正加密解密时又会拼接回 48 字符……确实“很有意思”，我惊呆了。
5. 除了塞进一个魔术头外，真没必要设计一个文件格式，除了自己坑自己，容易因为缺乏足够多的单元测试导致丢数据以外没啥意义。想要紧凑的二进制格式，完全可以用 msgpack bson cbor 之类的序列化格式，甚至 protobuf 之流。
除了只能看出开发者知道的少，没看出什么……
看到这评论，我都不知道说什么好了……
- 他最终还是没输出使用拼接 48 位有什么问题
- “谁”都能破解，我不知道他怎么得出的结论；
- 他始终没明白为什么密钥放在客户端不安全；对于用户忘记密码，这和忘记文件加密密钥是两回事。
- 从 48 位解析出原本简单的密码只因为那是用户自己输出的密码……
- 对于文件格式，谁 TM 想要紧凑二进制了，他完全没搞懂我为什么要分区块。而 protobuf 这种……它能用来设计文件格式吗？这种格式虽然紧凑，但是不好维护。
在少数派里面，他的评论的点赞还比我多，看来很多人认可他的观点。
我就不明白了，这是真“大神”还是假“大神”。
因为少数派不是技术社区，开发者还要维护个人形象，本身处于弱势地位。 所以，我想在 v2 上面，都是做程序的，大家来评评理。
第 1 条附言 · 51 天前
对于派生密钥的问题，这点我认。对于 RSA 的使用问题补充一些其他信息：
只所以加 RSA 是为了把用户加密用的密钥写入到文件，这样当用户忘记密码的时候，可以帮助他解密。这是一个可选项，如果用户不信任我们，那么他可以取消勾选，那么此时仅对文件使用 AES 进行加密。
用户的文件只存储在自己的手机上和自己的云盘上，我们不存储用户的任何信息。
服务器记录的用户信息只和会员身份有关，和用户的笔记文件没有任何联系。
我增加这个选项只是担心用户因为忘记密码导致数据丢失，所以提供了这个可选项，如果用户取消勾选，只需要用户自己保证记住自己的密码。
只所以加 RSA 是为了把用户加密用的密钥写入到文件，这样当用户忘记密码的时候，可以帮助他解密。这是一个可选项，如果用户不信任我们，那么他可以取消勾选，那么此时仅对文件使用 AES 进行加密。
用户的文件只存储在自己的手机上和自己的云盘上，我们不存储用户的任何信息。
服务器记录的用户信息只和会员身份有关，和用户的笔记文件没有任何联系。
我增加这个选项只是担心用户因为忘记密码导致数据丢失，所以提供了这个可选项，如果用户取消勾选，只需要用户自己保证记住自己的密码。
第 2 条附言 · 51 天前
感谢诸位，让我学到很多，如果我再设计的一个类似的功能的话。
那么我会采用如下方案，算是对这个帖子的总结，感兴趣的可以看一下。
对用户输入的密码使用密钥派生生成 32 位密钥用于 AES 。
同时使用 RSA 生成公钥和私钥，依然使用公钥将密钥写入到文件（如果用户勾选了的话）。
然后，私钥提醒用户保存，以文本或者文件形式保存。
当用户忘记密钥的时候，让用户提供私钥对文件解析出派生之后的密钥。
然后让用户输入新的密钥，再使用新的密钥对文件修改密码。
这可能是一个更妥帖的方案。
那么我会采用如下方案，算是对这个帖子的总结，感兴趣的可以看一下。
对用户输入的密码使用密钥派生生成 32 位密钥用于 AES 。
同时使用 RSA 生成公钥和私钥，依然使用公钥将密钥写入到文件（如果用户勾选了的话）。
然后，私钥提醒用户保存，以文本或者文件形式保存。
当用户忘记密钥的时候，让用户提供私钥对文件解析出派生之后的密钥。
然后让用户输入新的密钥，再使用新的密钥对文件修改密码。
这可能是一个更妥帖的方案。
第 3 条附言 · 50 天前
我已经在新的回复中向大神致歉，对于安全这块我的确欠缺一些知识。
我的习惯是先做再学，有时候确实想当然了。
不过我最近确实戾气很重，各位的回复也让我学到很多。
这是一个沉痛的教训，感谢诸位。
我的习惯是先做再学，有时候确实想当然了。
不过我最近确实戾气很重，各位的回复也让我学到很多。
这是一个沉痛的教训，感谢诸位。
 |
101
Promtheus 50 天前
哈哈哈 换个地方被喷 好惨。
|
 |
104
PersueYan 50 天前
你随便玩玩无所谓
严肃做加密不是这样的 |
 |
105
codcrafts 50 天前
---“因为少数派不是技术社区，开发者还要维护个人形象，本身处于弱势地位。 所以，我想在 v2 上面，都是做程序的，大家来评评理”
---评评理就是，你完全没有任何密码的基础，也不懂产品，沟通逻辑也很差，别人给你指出了很多方法，还一直在那说：“我这个功能只是可选的“ |
 |
108
ersic 50 天前
如果觉得他语气不好可以直接点出来。
有问题讨论是好事。 发这么个阴阳怪气的帖子，不太好。 |
 |
110
windyboy 50 天前
哥，端到端加密，你来个帮用户解密，你这个端到端有什么意义？
|
 |
111
liuidetmks 50 天前
"如果用户不信任我们，那么他可以取消勾选，那么此时仅对文件使用 AES 进行加密。"
--------------- 既然用户信任你，没必要端到端了吧 😂 Don't roll your own crypto ~ |
 |
113
realpg PRO 简单扫了眼
我对加密没啥研究 我很反感各种大神 很多都是伪高手 但是简单看了下 我觉得这大神没啥毛病... |
 |
114
ExplodingFKL 50 天前
建议 po 去看看密码学相关的概念
https://thiscute.world/posts/practical-cryptography-basics-1/ ----- Anyone can design a cipher that he himself cannot break. |
 |
115
xinzhanghello 50 天前
简单了解了下，你这个项目就像公司内部为了做 xx 项目，强行用 yy ，然后魔改下 yy ，大概就是这个感觉吧。
|
 |
116
YsHaNg 50 天前
@WngShhng https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack 你先说一下你的思路是如何 cca/cca2 完全
|
 |
117
Chicagoake 50 天前
不知道是不是因为这条帖子，这篇文章的阅读量有明显提高。
|
 |
118
WngShhng OP @Chicagoake 我宁愿删了它…
|
|
119
WngShhng OP @YsHaNg 老哥，说白了这只是一个个人项目，用过这个功能的根本不多。我开发这个功能更多的是出于个人的需求。我最大的需求就是躲避 ZF 审查，也就是网络提供商和云盘的扫描，所以对于安全性我并没有这么高的要求。所以，对于我来说使用 AES 加密文本以及自己管理文档就能满足需求了。对安全性有很高的要求的用户，一般也不会选择一个个人开发的产品。至于上面还有提到 review 之类的问题，这类开放的问题本来就有讨论的空间，如果在团队内部一般会拉上安全团队审核方案，这些疑惑也会在方案评审的过程中解决。
|
 |
120
charles0 49 天前
楼主这样的基于现有且可靠的加密算法(AES, RSA)之上自己再设计一个协议或者方案也是很不安全的，强烈不建议这样做，因为协议层和具体实现细节往往会出现各种各样的安全漏洞。实际上，不建议自己设计和实现与密码学相关的任何算法、协议或方案。前面有人提到的 Don't roll your own crypto 和 Schneier 定律 "任何人都可以发明一个非常巧妙，以至于他们自己想不出如何破解的安全系统" 是非常有道理的，这背后的原因可以参考 https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own 的回答。
|
|
121
charles0 49 天前
关于笔记软件如何实现端到端加密，我的建议是使用一个非常简单以至于不容易弄错的方案，比如：使用 libsodium 库，使用它的 crypto_pwhash 从盐和用户输入的密码中得到密钥，每一次都生成完全随机的 nonce ，然后用 crypto_secretbox 加密笔记元数据和内容，把盐、密文和 nonce 存到云端。先暂时放弃更高级的方式（如设备间同步主密钥并针对文件派生密钥、为忘记密码提供可以打印出来的恢复代码等等）而把最基础安全措施做好。
|
|
122
WngShhng OP @charles0 不认同“不建议自己设计和实现与密码学相关的任何算法、协议或方案”。如果你说不要发明任何加密算法，那么我认同；但是，如果说任何基于成熟加密算法的组合也不要发明，我不认同。从成长和学习的角度讲，这也是固步自封。
|
 |
123
way2create 49 天前
OP 是不是觉得那个人语气不太好。。。不过前端跟后端是两个领域，不是搞一搞就算会了，密码学又是另外一个领域，无关紧要的我也很喜欢瞎折腾，但实际很多时候没必要自己造轮子
|
|
124
WngShhng OP @way2create 差不多是觉得语气不好，因为本来写篇文章是做产品推广的…还真不能全怪我应急，有的人说法方式是有问题。我比较后悔的是带着火气发了这个帖子，也可能没睡好头脑不清醒～😂
我上面说了，我的主要目的是躲避 ZF 审查，因为我会有些跟 ZZ 和经济相关的观点，如果纯文本的话担心被扫描，所以，我所谓“端到端”只要保证不被网络和网盘扫描就够了，并没有对安全要求特别高，因为文件也在用户自己那里。唉，反正，越描越黑～ 造轮子这件事情，个人的项目就比较激进一些 |
Select Language