search

traceless / alist-encrypt

这个项目主要是对 alist 的服务进行代理，提供 webdav 的加解密功能。支持 alist 网页在线播放加密的视频，查看加密的图片等功能，同时在 webdav 下的操作透明，自动实现文件资源的加解密。
1.26k stars 116 forks source link

说说算法 #6

Closed Cyl18 closed 1 year ago

Cyl18 commented 1 year ago

我倒是学艺不精，但是还是有的想说说自己知道的点❤️（（

因为对称加密是块加密

当前项目已添加RC4算法，安全性基本是无可挑剔了 RC4早就爆出不安全了😥… 2015 年 2 月发布的 RFC 7465 禁止在 TLS 中使用 RC4。

虽然对于这样的项目说，我觉得能某种意义上混淆明文就已经能达到目的了，但是还是可以采用更安全的算法😘 就这点的话，安全性来说ChaCha20-Poly1305可能更好，当然AES和chacha20是可以互换的

另外对于极致安全性来说，不要自己实现算法（我说的不是RC4，而是之前的mix混淆prototype，当然实现算法也是蛮有意思的嘛，“设计这个项目的初衷本身就是为了躲避云盘的扫描的”，我也很赞同这一点😄，我之前甚至想过直接把整个文件头部一段字节加密就行了，能抵御大部分扫描），而是参照已有实现会比较好，而且要了解如何正确实现（比如AES的ECB绝对不能用，CBC使用padding不当会有点问题）…

对称加密不方便分享密匙给对方

我没有看RC4是怎么实现的，但是感觉可以另外存密钥或者用文件名派生密钥来解决这个问题？

当然还是很感谢你有时间来维护和创造这个项目❤️

traceless commented 1 year ago

很赞同这一点😄，我之前甚至想过直接把整个文件头部一段字节加密就行了，能抵御大部分扫描），而是参照已有实现会比较好，而且要了解如何正确实现（比如AES的ECB绝对不能用，CBC使用padding不当会有点问题）…

嗯，谢谢你的意见😁。我对密码了解也不多， AES-CTR和AES-XTS 我刚去了解下，还没细看它是怎么做到随机字节的加解密的。视频播放的时候是随机取 Range: bytes=1234-5678 ，我不知道这些算法要怎么对这样的数据进行解密，我回头研究下。但是AES还有一个问题在低端的ARM cpu性能很差（不过大多armv8 应该都没啥问题），目前RC4在低端的arm盒子（R2S）也有点吃力。。应该是js效率的问题

RC4是据说不安全，是因为出现弱密匙能到导致连续的十几个字节泄漏（不知道我理解对不对），但是在128位长度的密匙目前也没文献证明它是不安全的。请教下：RC4网上推荐key是128位，还是key的长度128？，一直没确认好这个key。ChaCha20-Poly1305 是比较好，据说速度更快，比RC4更快。我看了几个实现好像有点麻烦，如果是都是用PRGA伪随机的话，应该是一样的速度吧，目测速度不应该比RC4快。因为当时RC4正好有现成的代码，也比较简单就2个关键的函数，我就直接拿来用了。

至于密码分享，其实比较简单，就只是原密码直接MD5一下再继续使用。分享密码是业务上实现的，可以用原密码或者MD5后的密码兼容使用😄，只是兼容一下而已。文件名派生密码的实现也在进行，预计这2天可以实现。可以针对文件夹名字解密获取到整个文件夹的密码，这样就可以实现大规模的不同用户不同密码的分享，非常有用的功能。

Cyl18 commented 1 year ago

但是AES还有一个问题在低端的ARM cpu性能很差

chacha20就在没AES指令集的情况下比AES快一点

应该是js效率的问题

换个有wasm的加密库…？

因为当时RC4正好有现成的代码，也比较简单就2个关键的函数，我就直接拿来用了。

也挺好的😄 方便

RC4网上推荐key是128位，还是key的长度128？

没听太懂

traceless commented 1 year ago

但是AES还有一个问题在低端的ARM cpu性能很差

chacha20就在没AES指令集的情况下比AES快一点

应该是js效率的问题

换个有wasm的加密库…？

因为当时RC4正好有现成的代码，也比较简单就2个关键的函数，我就直接拿来用了。

也挺好的😄 方便

RC4网上推荐key是128位，还是key的长度128？

没听太懂

RC4 有一个key就是我们填的密码，用来初始化向量数组S，我看网上说它的长度不应该低于128位，我不知道是说16个字节128位，还是要求key 是 128长度的字节。。

Cyl18 commented 1 year ago

情理上+查了一下是128bit

但是还是感觉RC4有一些安全问题…md5也有一些… 另外key的派生不能直接md5，应该用PBKDF2之类的东西（ 看你吧，有精力可以选择安全性更高的方案，现在这样也还行👍

traceless commented 1 year ago

嗯好的。

情理上+查了一下是128bit

但是还是感觉RC4有一些安全问题…md5也有一些… 另外key的派生不能直接md5，应该用PBKDF2之类的东西（ 看你吧，有精力可以选择安全性更高的方案，现在这样也还行👍

嗯方便加个好友吗，我的q: 3121604

traceless commented 1 year ago

情理上+查了一下是128bit

但是还是感觉RC4有一些安全问题…md5也有一些… 另外key的派生不能直接md5，应该用PBKDF2之类的东西（ 看你吧，有精力可以选择安全性更高的方案，现在这样也还行👍

key我是先加盐进行sha256再进行MD5，代码公开的情况下，没啥多大的区别。另外我昨晚进行对chacha20和RC4实现，RC4明显快很多，我的测试方案是对1亿字节的数据进行加密，RC4快很多。不知道是哪里有问题，网上都说chacha20速度快，是不是测试的方案不一样呢，chacha20测试比这个RC4要快2倍多，不知道怎么搞的。。

OlsonStarling commented 1 year ago

我倒是学艺不精，但是还是有的想说说自己知道的点❤️（（

因为对称加密是块加密

  • AES是可以拿来流加密的，如AES-CTR
  • RC4也属于对称加密算法 硬盘上也经常使用AES-XTS，也是可以随机读取的，并不存在“块加密”的问题

当前项目已添加RC4算法，安全性基本是无可挑剔了 RC4早就爆出不安全了😥… 2015 年 2 月发布的 RFC 7465 禁止在 TLS 中使用 RC4。

虽然对于这样的项目说，我觉得能某种意义上混淆明文就已经能达到目的了，但是还是可以采用更安全的算法😘 就这点的话，安全性来说ChaCha20-Poly1305可能更好，当然AES和chacha20是可以互换的

另外对于极致安全性来说，不要自己实现算法（我说的不是RC4，而是之前的mix混淆prototype，当然实现算法也是蛮有意思的嘛，“设计这个项目的初衷本身就是为了躲避云盘的扫描的”，我也很赞同这一点😄，我之前甚至想过直接把整个文件头部一段字节加密就行了，能抵御大部分扫描），而是参照已有实现会比较好，而且要了解如何正确实现（比如AES的ECB绝对不能用，CBC使用padding不当会有点问题）…

对称加密不方便分享密匙给对方

我没有看RC4是怎么实现的，但是感觉可以另外存密钥或者用文件名派生密钥来解决这个问题？

当然还是很感谢你有时间来维护和创造这个项目❤️

如果目前的应用方向是对抗网盘审核，我觉得应该考虑占用过大的问题，考虑到家用nas甚至op硬路由的性能普遍比较弱小，尤其是需要频繁加解密的情况下，过度的追求加密安全性得不偿失，网盘公司不太可能针对性破解，与其破解不如一刀切，比如禁止上传压缩格式文件等，相比破解我更担心用户丢失密钥的的可能性。

traceless commented 1 year ago

公司不太可能针对性破解，与其破解不如一刀切，比如禁止上传压缩格式文件等，相比破解我更担心用户丢失密钥的的可能性。

用户丢失密匙的问题，没法解决的，任何加密软件都不好处理，不过MIX加密的方式可以找回密匙（我回头考虑是否要改回去。），而且MIX的混淆方案也是几乎没有性能消耗的一种方案，适合低性能的机器。

traceless commented 1 year ago

我倒是学艺不精，但是还是有的想说说自己知道的点❤️（（

因为对称加密是块加密

  • AES是可以拿来流加密的，如AES-CTR
  • RC4也属于对称加密算法 硬盘上也经常使用AES-XTS，也是可以随机读取的，并不存在“块加密”的问题

当前项目已添加RC4算法，安全性基本是无可挑剔了 RC4早就爆出不安全了😥… 2015 年 2 月发布的 RFC 7465 禁止在 TLS 中使用 RC4。

虽然对于这样的项目说，我觉得能某种意义上混淆明文就已经能达到目的了，但是还是可以采用更安全的算法😘 就这点的话，安全性来说ChaCha20-Poly1305可能更好，当然AES和chacha20是可以互换的

另外对于极致安全性来说，不要自己实现算法（我说的不是RC4，而是之前的mix混淆prototype，当然实现算法也是蛮有意思的嘛，“设计这个项目的初衷本身就是为了躲避云盘的扫描的”，我也很赞同这一点😄，我之前甚至想过直接把整个文件头部一段字节加密就行了，能抵御大部分扫描），而是参照已有实现会比较好，而且要了解如何正确实现（比如AES的ECB绝对不能用，CBC使用padding不当会有点问题）…

对称加密不方便分享密匙给对方

我没有看RC4是怎么实现的，但是感觉可以另外存密钥或者用文件名派生密钥来解决这个问题？

当然还是很感谢你有时间来维护和创造这个项目❤️

如果目前的应用方向是对抗网盘审核，我觉得应该考虑占用过大的问题，考虑到家用nas甚至op硬路由的性能普遍比较弱小，尤其是需要频繁加解密的情况下，过度的追求加密安全性得不偿失，网盘公司不太可能针对性破解，与其破解不如一刀切，比如禁止上传压缩格式文件等，相比破解我更担心用户丢失密钥的的可能性。

性能的问题不用担心，目前arm盒子，cpu：S905L3A，都可以跑满300Mbps带宽，足够一般的播放 带宽要求了

Cyl18 commented 1 year ago

@OlsonStarling

如果目前的应用方向是对抗网盘审核，我觉得应该考虑占用过大的问题，考虑到家用nas甚至op硬路由的性能普遍比较弱小，尤其是需要频繁加解密的情况下，过度的追求加密安全性得不偿失

是的，我之前有点被带偏走向，看到 alist-encrypt 的 encrypt 和主页就认为加密，而 alist-encrypt 的任务只是在能满足随机读取文件的情况下混淆文件。而这里其实可以走两个极端，一个追求极致速度（比特翻转/异或 甚至只加密文件头），一个追求极致安全（如 ChaCha20）。 对于安全性我个人不喜欢有漏洞的算法，就算 RC4/MD5/SHA1 的漏洞利用条件很苛刻，我个人是不太喜欢。 而 ChaCha20 在评测上可能比 RC4 更快同时安全性更好，所以我这里推荐了 ChaCha20。

而追求极致速度和安全性 完全是由用户来决定 的，虽然不同算法会增加开发时间/难度。对于性能来说，也许可以在页面写个测试不同算法速度的东西来让用户辅助选择； 所以，安全性和性能是由用户主动选择的，不需要过多考虑。

网盘公司不太可能针对性破解，与其破解不如一刀切，比如禁止上传压缩格式文件等

一年前我也考虑过这个事情，后来思考一刀切是不可能的，因为常见格式 docx 就是个 zip 文件，而可以压缩文件那就什么都可以干了；在信息里隐藏信息永远都是可以的，图片/视频也可以隐藏信息，如把文件编码传到 B 站视频（有人干过）。这同样是个矛与盾的问题，不用纠结未来怎么发展。

同时更应该考虑的是网盘乱删文件/乱判违规的问题，我极其担心这点发生，但是目前没有什么已知案例。

相比破解我更担心用户丢失密钥的的可能性

写个 password.txt 里面 123456 然后打印一百份贴家里墙上

我个人更担心的是 alist-encrypt 的实现能不能保证离线解密，也就是单独下载文件下来能不能单独用自己的密码解密。（alist-encrypt 目前有 cli 工具可以离线解密，但是我没测试过不知道好不好用 听说挺好用）

用户丢失密匙的问题，没法解决的，任何加密软件都不好处理，不过MIX加密的方式可以找回密匙（我回头考虑是否要改回去。），而且MIX的混淆方案也是几乎没有性能消耗的一种方案，适合低性能的机器。

如果真的担心密钥丢失可以采取类似 BitLocker 的办法，把密钥单独弄成一个文件存下来