Alist-encrypt 再也不用担心网盘资源被封啦，可在线播放加密视频

[byte10]

Alist-encrypt

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

代码仓库地址： https://github.com/traceless/alist-encrypt

一、需求背景

AList 是一个支持多种存储、云网盘，支持网页浏览和提供 WebDAV 服务的应用程序。最近的阿里云盘很火，因为不限速，所以不少人使用阿里云盘配合 alist 当做个人的影院，随时在线观看视频。

国内的云盘有很多，除了阿里云盘还有天翼云盘也是不限速的，但是几乎都存在一个问题，敏感资源会被删除，相信很多人经历文件被删除掉的噩梦。那么有没有什么办法可以避免这样的问题呢，最简单的方案就是加密后上传。那么就有大局限性，不能实时在线播放视频，当然也有一些方案可以做到。加密后的文件分享也存在一定的不方便（密码不方便对外提供）。

Alist-encrypt 就是为了解决这个问题，它可以结合 webdav 服务器进行使用，在文件上传的时候进行加密，文件下载的时候进行解密，由于使用的是流加密方案，所以可以很轻松实现在线播放视频，浏览图片、文件等。目前主流的方案都是使用 alist 来实现网盘 webdav 的服务，所以 Alist-encrypt 支持 alist 服务，并且优先支持它的适配，支持网页版在线播放视频等功能。

关于这个项目的使用场景，对文件安全隐私有一定的需求，防止云盘扫描删除，有实时播放视频和下载的需求。

三、实现原理

项目的实现比较简单，原始孵化的项目地址在这里：flow-encryption 它有描述算法的实现，代理服务的实现思路，也有基础版本的代码实现，可以学习参考。

二、安装使用

1 、下载运行

需要先安装 nodejs 的环境，具体安装方法，请参考网上的教程

1 、下载此项目，进入 node-proxy 目录执行

npm i

2 、修改 conf/config.js 配置文件，添加 alist 服务地址端口，添加 alist 的网盘中需要进行加密的文件夹路径。

3 、然后执行启动命令

node app.js

最后就打开代理服务器地址 http://127.0.0.1:5344 ，即可完全代理访问 alist 服务。

2 、docker 安装

运行拉取镜像命令

docker pull prophet310/alist-encrypt:beta

执行启动容器即可

docker run -d -p 5344:5344 -v /etc/conf:/node-proxy/conf --name=alist-encrypt prophet310/alist-encrypt:beta

启动后打开 /ect/conf/config.json 文件，可以修改默认配置，然后再重启 docker 即可。

{
    port: 5344,  // 代理服务器的端口
    alistServer : {
        path: '/*', // 默认就是代理全部，不建议修改这里
        serverHost: '127.0.0.1',
        serverPort: 5244,
        flowPassword: '123456', // 加密的密码
        encPath: ['/aliy/test/*', '/aliy/test/*', '/tianyi/*'], // 注意不需要添加 /dav 前缀了，程序会自己处理 alist 的逻辑
    }

    /** 支持其他普通的 webdav ，当然也可以挂载 alist 的 webdav ，如果你想不同目录不同密码，那么就可以使用这个方式扩展 */
    webdavServer : [
    {
        name: 'aliyun',
        path: '/dav/*', // 代理全部路径，不能是"/proxy/*"，系统已占用。如果设置 "/*"，那么上面的 alist 的配置就不会生效哦
        enable: false, // 是否启动代理
        serverHost: '127.0.0.1',
        serverPort: 5244,
        flowPassword: '123456', // 加密的密码
        encPath: ['/dav/aliyun/*', '/dav/189cloud/*'], // 要加密的目录，不能是 "/*" 和 "/proxy/*"，因为已经占用
    },
    ]
}

3 、操作使用

1 、alist 原本网页上的所有的操作都可以正常使用，因为 Alist-encrypt 它是透明代理，所以你所有的操作请求都是透传到 alist 上的，除了某些需要加密上传的操作和在线解密播放的操作。

2 、你可以在 webdav 客户端上进行文件上传，如果设置了加密的文件夹目录，那么上传的文件就会被加密，在云盘上下载后会无法打开。但是你使用 Alist-encrypt 代理的 alist 服务还是一样可以正常下载查看，在线播放视频，查看图片等，不管是在 webdav 还是网页上都是正常使用。

3 、除了可配置 alist 服务，也可以配置其他的 webdav 服务，同样也是在 conf/config.js 中。注意的是它的配置优先级高于 alist ，会覆盖 alist 的代理路径，注意错开路径。如果无法避免和 alist 冲突，那么建议再运行多一个代理服务。

四、已支持&待完善

已支持的功能

1. 支持 alist 网页在线播放加密的视频，查看图片，在线下载等。
2. 支持 alist 网页跳转到 IINA ，VLC ，Infuse 等播放器上进行播放。
3. 在 webdav 客户端上的所有操作不会受到影响，自动加解密，可播放视频、查看图片。

待实现功能

1. 提供界面配置 alist 和 webdav 的信息。
2. 提供 cli 程序进行文件解密\加密，用于分享对方在下载后解密。
3. 提供原文件和加密文件找回加密钥匙 encode 。
4. 可以把未加密(或已加密)的文件夹 A （或文件） -> 转存到加密文件夹 B 中，用于转存别人分享的文件。
5. 设置不同目录不同密码，后续会支持，当前可以使用配置多个 webdav 服务来支持。

已知问题

• 加密文本还不能在线看，当前建议直接下载看，后续会支持。
• 阿里云盘无法使用 Aliyun Video Previewer 进行播放，请选择 Video 方式播放、

局限性

• 目前的实现还很基础，判断文件是否云盘资源是通过 https 来判断，所以你的 Alist-encrypt 本身就不能挂载到 https 上，后续可以根据 response 的 header 来分析。

• 由于解密是代理了云盘下载的流量，所以如果你是使用穿透内网的方式访问 Alist-encrypt 服务，那么很明显你的穿透带宽会影响你的文件的访问速度。

五、FAQ

1 、为何不使用 ASE 对称加密算法，R4C 算法。

• 因为对称加密是块加密，理论上对齐数据块是能实现的流加密的，但是需要知道文件的长度。在线播放的时候，跳转播放位置时，也需要对齐字节才能正常播放，加密和解密的业务实现比较复杂一些，实现起来头大。如果你对文件安全性要求很高，那么并不推荐这项目来加密你的数据，R4C 也差不多。

• 对称加密不方便分享密匙给对方，而此算法的加解密钥匙 encode （ decode ） 是可以对外提供的，用于分享文件给对方。

设计这个项目的初衷本身就是为了躲避云盘的扫描的，文件是可以分享给对方查阅的。AES 加密或非对称加密更适合私人资料使用。对文件的安全要求不高的情况下，推荐使用这项目，它可以让你轻松躲过网盘的文件审核，也可以让你轻松找回密码（有一个原文件即可）。

还有基于这个算法的升级版，可以根据文件长度实现不同文件加密的钥匙不一样，这个后续再考虑是否有实现的必要。因为会导致无法找回文件夹密码了，同样也不方便分享整个文件夹了，得不偿失，还要考虑是否有其他使用的影响。

最后

目前还只是体验版，验证项目的可行性，代码实现很简单，后续会继续维护下去。这项目的实用性很强，目测能火😄。

当前的内容已经过时，项目新增了 RC4 算法，安全性基本没啥问题了。每个文件都是不同密匙流，是根据文件 size 作为加密的 salt 。目前项目已经加大马力 去整了，后续会有更多的功能支持。

[zephyr1]

挺厉害，试试

[byte10]

@zephyr1 😄 可以测试下，我觉得这个需求还是很大的，我自己就挺喜欢这个 加密方式，也不怕忘记密码， 又能防止网盘扫描。

[lioi]

这个看起来不错，我自己是用 rclone 自带的透明加密功能，但是他加密不支持流式传输，所以遇到较大的视频就很难在线预览。但是一些小文件还不错。有空试试这个。

[byte10]

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

[lioi]

@byte10 我是把网盘挂载到 alist 上，alist 通过 rclone 挂载到服务器，然后套上 rclone 的透明加密。再用 alist 把挂载的加密文件夹套出来。在解密预览的过程中，文件会占用本地的磁盘。

[byte10]

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

[947]

牛，已 star

[xieren58]

牛，已 star

[byte10]

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

[NouveauNom]

👍🏻，实现了我一直想要的功能

[byte10]

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

[ungrown]

有些网盘限制体积，大文件最好做个切片

[lyc8503]

感觉在加密强度上和主流加密算法强度还是有距离的, 看应用场景感觉更像是一种带密钥的混淆?

[byte10]

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

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

[lyc8503]

@byte10 如果从加密强度角度考虑的话, chacha20 也是仍被认为安全的流加密, 但你刚开始提出的"需求背景"就是"避免敏感资源被删除", 可能要更多地考虑使用的便捷性、实现的难易和加解密性能?

要看这个项目的定位是确保强加密的同时提供实时访问的功能还是单纯的使用密钥混淆文件内容防止被屏蔽. 如果单纯是混淆的话, 其实不太需要注重保密性, 更应该想办法抹除容易检测的特征. 包括你提到的"有一个原文件即可找回密码", 这显然是达不到现代密码学"加密"的要求的.

至于项目的实用性, 主要还是看各个网盘屏蔽的力度和是否能够便捷到让足够多人以这种格式分享文件吧, 之前有的网盘工具也提供视频上传时"洗码"(在结尾添加若干随机字节)的功能就能绕过很多网盘的屏蔽了.

[byte10]

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

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

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

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

[lyc8503]

@byte10 因为感觉既要流式传输又要强加密的场景不常见, 用 alist 挂载网盘存储个人常用重要文件的应该不多吧? 加密备份文件的话 rclone / duplicati 已经很好用了, chacha20 之类的加密算法对路由器之类的设备还是有一定压力的.

[byte10]

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

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

[byte10]

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

[levenwindy]

有没可能实现，文件名也加密

[byte10]

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

[byte10]

@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 者的实现 有其他的黑魔法加成吧，不然我实在想不通。。。

[TheRealKamisama]

感觉有点进去的风险, 最近跟别的开发者讨论了一下, 顺便我又想起来 pandownload 作者的遭遇, 所以我觉得这个项目还是不要声张为好.
解决不了加密我还解决不了你?
望作者保护好自己

[byte10]

@TheRealKamisama 嗯 目前低调推广。 实用性还是很强，而且思路很清晰，任何人都可以根据这个的思路，开发一个加密工具出来。目前用的算法也是公开的 AES-CTR ,RC4 ，并不是私有的算法，即使我的跑路了，还能轻松的写个脚本把数据找回来。

[wlane1213]

又要低调，又要推广，不好搞，特定人群内吧

[byte10]

@wlane1213 嗯小范围 推广下，这个需求应该还是比较强烈的，但是实现这个项目并不是难。我看市面上真的没啥相关的产品，都很少能做到在线播放加密视频的。

[levenwindy]

已✨
期待 文件加密 早日上线
一堆文件时刻准备着，打包加密解密太麻烦了

[byte10]

@levenwindy 嗯 目前都差不多了，算法都确定下来了，RC4 和 AES CTR ，文件名字的加密 也做了。就剩下 webdav 的名字加密还没处理完。你可以先体验下 ， 有教程 https://www.zhihu.com/zvideo/1627064703548657664 也可以加群关注最新的进展 422035582

[guanzhangzhang]

搞这个最好还是别国内实名宣传吧，不然进去了

[byte10]

@guanzhangzhang 没事啦，随便搞啦，生死看淡。你试试呗，还是很不错哦。

[levenwindy]

一直都在关注，加密文本能在线看了，明天就试试

[byte10]

@levenwindy 额 迭代了很多了，文件名加密 也可以了哦。但是目前还有一个小 bug ，需要修复下。你可以多体验下，真不错