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