alist-encrypt ，可以在上传的时候直接加密视频，播放的时候直接解密视频，新增了 AES-CTR 算法，性能超强无损。 演示视频在这里，低调使用哈，https://www.zhihu.com/zvideo/1627064703548657664

@tony1016
@jfdnet
@op351
@lycpang
@stuartofmine
@Ambition95
@bigtan
@cyningxu

可以关注一下 alist-encrypt ，直接加密上传视频和图片，又能直接在线观看视频和图片，使用的 AES-CTR 流加密，很不错。支持 webdav 播放加密视频。可以满足大家的需求哦、再也不不怕被封了哦

@Al0rid4l 我现在有一个需求，就是上传的视频文件进行加密，这个好像 JS 就可以实现。但是对播放的视频进行实时解密，可能要下载后进行解密了，然后再给回播放器 解密后文件的 src ，貌似有点复杂。

或者换一个思路，猴油可以创建 http 服务器吗？这样就可以代理所有的流量啦

我从小以前认为数学比语文重要多了。这几年的工作遇到的问题，让我越来越觉得，语文教育得加大力度，满分 300 分才行😄。头大，，，表达能力真的是重要的生产力。

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

参考下 微信 小程序的做法吧，用户会话的的 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 多谢支持，能不能火 就靠大家了😁