请教一下，油猴插件，可以做到流量劫持吗？我需要对流量进行加密和解密的操作。或者说浏览器插件支持这种操作吗？

参考下 微信 小程序的做法吧，用户会话的的 session_key 就是作为对称密匙，每次加密就是用这个 session_key 进行加密的，这算是比较常见做法。 客户端是每次在 用户登录后 得到这个加密钥匙。

好像上次就曝光了，在 git 仓库就有说明。

@lyc8503 chacha20 我搞了一套，用不了，它速度很慢，如果用 js 来实现，那么它的速度很不行，巨慢。

但是用 nodejs 自带的加密库 crypto 中的 chacha20 就很快，比 crypto 的 RC4 还快一点点，时间比是 5：7 （从代码层面分析，chacha20 应该复杂不少，不知道为何会比 RC4 快一些。。。尤其是大数据流的加密）。

自己代码实现的 RC4 速度也是巨快，当然比不上自带 库 crypto 的 RC4 速度， 时间比（ 1: 2.5 ）。但是跳转视频播放的时候，自己实现 RC4 支持在任意位置初始化，速度跟自带库的略慢时间比（ 7: 9 ）。如果换成 chacha20 来实现视频跳转，那么速度是更快一些，但是没有质的提升。而且不好实现，因为无法拿到底层的数据状态。自己实现的代码又巨慢。

而且 RC4 适合大数据的加密，理论比 chacha 好很多，但是不知道为啥跑不过 chacha20 ，可能是 C 语言的对 2 者的实现 有其他的黑魔法加成吧，不然我实在想不通。。。

@levenwindy 额，这没啥必要吧。。文件名也是可以做到加密的，只是这样的业务 入侵性有点大。。

考虑云盘吗？ 云盘的一个新方案，https://www.v2ex.com/t/925236 《 Alist-encrypt 再也不用担心网盘资源被封啦，可在线播放加密视频》应该可以满足你的需求，直接买云盘的会员，阿里云或百度云的。配合这个加密插件，你会发现新大陆，nas 我都扔了。。

@lyc8503 我改成了 RC4 算法实现了，也可以正常的在线 播放视频，下载文件等操作。RC4 算法简单，而且安全性几乎是没问题的。据了解有一定的概率 出现 LSB ，会出现几个字节的明文，完全可以接受，安全性基本没啥大问题。加密 key ，多 MD5 几次，弄长一点就可以了

@lyc8503 嗯实时的，目前可以说就是使用密匙 混淆文件，具备一定的保密性，比裸奔强一些。单个字节的加密，思路有限，提高密匙长度可以加强下破解的难度。而流式算法 一般需要当前知道当前字节的位置，才能支持进行分片下载文件，这个倒有 http 头支持 range 可以获取到，又得增加工作量😄

确实没必要整那么复杂，还是根据实际场景 解决痛点就好。

@lyc8503 目前的算法有源文件是可以得到加密的钥匙，那么整个文件夹文件都是识别，当然这个得网盘它有源文件才行，所以说网盘是可以有对抗的可能性。但是我们可以通过文件长度加盐 salt ，让每个文件单独一个密匙。

当前加密算法确实很简单太弱了，针对一些格式化文件特征（比如某些文件头是常见的格式，比如 class 文件，mp4 文件头） 是比较容易碰撞破解。不过即便暴力破解只要 10 亿次数，也不会有网盘会去做破解的事情，成本太高，会倒闭。如果没有文件特征的话，单纯暴力破解，那么有生之年应该是破解不了的，1.8 x 10^(19 + n) ，这个 N 保守大于 8 。再想想怎么优化下算法，提高破解的难度，避免用这个源文件 得到密码。当然我觉得能找回密匙也是挺好的

你说的混淆的方案也是一种思路，但是我这个是加密方案，所以当然也是达到混淆的效果了。

chacha20 回头去了解下，感觉这些流算法，伪随机，实现实时播放还是比较难搞。后面搞不定就先搁置了

@bfdh 刚才想了一下，再加密一次 没啥用，想错了。。找个时间了解 RC4 算法，这个方向才是比较合适的。

@lyc8503 我昨晚研究了一下 rc4 算法，还有 AES 。我的这个算法缺点就是不安全😄，很容易被破解，当然也是相对而言，即便它在不安全，也是要一定的成本去破解的 。后面看看是否要 改成 RC4 类型的吧（ R4C 据说也有一定的安全问题），所以还是要权衡 加解密性能和代码复杂度，业务实现复杂度的等。改成 RC4 或者 AES 都对业务的调整比较大，比如楼上的说的大文件切片，在线播放视频，需要处理的东西就多了一些，RC4 当然是比较好可以解决的。但是 AES 要解决的东西就比较多了。。。

@ungrown 切片是客户端的行为，这个算法可以直接支持，😄

@NouveauNom 哈哈好像没啥人关注，我先把界面弄好，然后再好好推广一下。主要是要把 这个算法要推广起来，这样大家用同样的算法 就可以做到加解互通了。

@bfdh 就是把加密后密文，再加密一次😄，我觉得有点多余。但是它有它的好处，即使拿到原文件，也没法找回密码，更安全一些。作为一个可选项吧，不是很喜欢。

@bfdh 嗯 因为原理很简单的啊，我刚升级了算法，安全上是彻底稳了，之前还担心会有暴力破解的可能。

@tisswb 多谢支持，能不能火 就靠大家了😁

@xieren58 多谢支持，我更新了 新的算法，在安全上是没问题了
@947 多谢支持😄，还要加把劲，把页面搞一下，这周应该会有比较完整的体验了

@lioi 嗯，rclone 是可以配置缓存的，我看了 rclone 方案也 还可以。理论上对称加密也是可以做到实时预览文件流的，实现稍微麻烦一点

@alyssa0326rr 我看了 alist 它设计的时候就支持 webdav 访问是 302 还是跳转，所以理论上它很容易把我的这个方案 加到他们的项目中的，这个东西本来就是在 alist 那边去实现更好的，回头联系一下他们看看。主要是看要尽早确定加密的算法实现😄，统一算法实现后，不管是谁去实现都行，国内的云盘就可以尽情使用了，分享也完全没问题。

@alyssa0326rr 是的进行中转，看看 github 的 alist-encrypt ，已经有实现了，做了基本测试可用。

@tisswb 阿里云盘有 open 方案了，所以用官方的接口是更稳了 关于这个想法的项目的已经落地了，在 github 的搜一下 alist-encrypt ，目前可以做到在网页中 在线播放加密视频，查看加密图片等。

@bfdh https://github.com/traceless/alist-encrypt 可以试试看 ，已经验证可行性了，至于你说的性能，跑满 100Mbps 肯定是没问题的。用的还是 nodejs ，如果有性能瓶颈，那就换 go 语言或者 nodejs 的多线程 都可以的，晚上测试下性能，因为加密算法比压缩算法还简单，不应该会出现性能瓶颈的。

@lioi 对了 rclone ，是不是要占用本地的磁盘的？