少数派发了一篇文章，偶遇“大神” fastQ

我前段时间在少数派上写了一篇文章，里面提到了文件端到端加密，我自己设计了文件加密格式，就因为里面用到了 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 上面，都是做程序的，大家来评评理。