Relayium 如何对文件端到端加密

最近更新: 2026-07-09

「Relayium 安全吗？」是个合理的问题——每个文件传输工具都会说自己保护隐私。本文用大白话讲清 Relayium 到底如何保护文件隐私，让你能自己判断这个说法，而不是单凭信任。

这里其实有两套不同的加密方案，因为存在两种不同的场景：把文件实时发给一个此刻在线的人，或者留一个下载链接给对方稍后来取。两种方式都让服务器碰不到你的文件，但实现路径不同——搞清楚什么时候用哪种，是值得的。

实时传输：两台设备协商出一个服务器永远看不到的秘密

当你实时发送文件时——双方都在线，浏览器对浏览器——Relayium 会先让每台设备用 X25519 生成一对全新的密钥。这正是现代安全通讯普遍采用的椭圆曲线密钥交换算法（技术上是 libsodium 的 crypto_kx）。每台设备都把私钥留在自己手里，只把公钥发给对方。

凭这两把公钥，每台设备各自独立算出同一个共享密钥——这之所以行得通，是椭圆曲线密钥交换本身的数学特性决定的，而不是因为这个密钥被发送到了哪里。这个共享密钥会变成一把只存在于两端浏览器内的 AES-256-GCM 密钥。文件的每个数据块在离开发送方设备之前，都会用这把密钥配合唯一的随机数封装，因此任何经过网络的东西——包括帮两台浏览器互相找到对方的信令服务器——看到的都只是密文。

每次传输都会生成一对全新的密钥——不会跨会话复用。
共享的 AES-256-GCM 密钥在每台设备上独立推导得出；它从不会被发送到任何地方，包括 Relayium 自己的服务器。
加密发生在应用层，位于 WebRTC 自身传输层安全之上，因此即便传输层被攻破，加密依然有效。

识破不诚实服务器的六位校验码

这里有个值得坦白说明的细微之处。WebRTC 自带的加密（DTLS）会通过负责撮合两台设备的信令服务器交换密钥指纹。如果这个服务器不诚实，理论上它可以居中调包成自己的密钥——一次经典的中间人攻击——而两端浏览器不会立刻察觉。

Relayium 用一段简短的校验码堵上这个缺口。两台设备都从各自的公钥推导出同一段 6 位短校验码（SAS），并显示在屏幕上。如果两边的码一致，说明密钥没有被调包，中间没有人。但一段普通的 6 位数字码只有约 20 比特，一个位置合适的攻击者理论上可以在看到双方真实密钥后暴力凑出一个匹配的码。为防止这一点，Relayium 采用「先承诺后揭示」的握手方式：双方先各自发送一段对自己密钥的哈希承诺，收到对方的承诺之后才揭示真正的密钥。这个顺序意味着恶意服务器必须在还没见到真实密钥的情况下盲目地承诺一个伪造密钥——它无法事后再挑一个能撞上的密钥，短校验码因此依然可信。

为获得最强的保证，请通过通话读出校验码或当面核对，而不只是各自看屏幕上的数字。
如果两边的码不一致，请立即停止：这可能意味着有人正在拦截连接。

确认到手的和发出的分毫不差

加密保护的是保密性，但它并不能自动证明传输过程中什么都没有损坏或被篡改。Relayium 会单独检查这一点：每个数据块都带有自己的 AES-GCM 认证标签，被改动过的数据块会直接解密失败。除此之外，在发送每个文件的过程中，收发双方都会对明文内容持续计算一个 SHA-256 哈希；文件传完后，发送方的哈希会与接收方的做比对。如果一致，落到磁盘上的内容与发出的逐字节相同；如果不一致，这个文件会被标记出来，而不是被悄悄接受。

存储链接：一把只生成一次、只存在于链接里的不同密钥

实时传输需要双方同时在线。做不到这一点时，Relayium 提供存储下载链接作为替代——它采用的是一套确实不同的机制，不要和上面的实时方案混为一谈。

这里没有密钥交换，因为此刻还没有第二台设备可以交换。取而代之的是，你的浏览器会生成一把随机的 AES-256-GCM 密钥，在任何内容上传之前先用它加密文件。这把密钥完全不会发给服务器——它被附加在下载链接的 # 字符之后，也就是所谓的 URL 片段，这部分地址浏览器有意从不发送给服务器。服务器最终只存下它无法解密的密文，外加密文大小、过期时间等记账信息。任何拿到完整链接（包含片段）的人都能在自己浏览器本地解密文件；没有这个片段的人，在服务器上看到的只是一团不透明的数据。这就是零知识的部分：服务器持有加密后的文件，却从不掌握读懂它的手段。

创建存储链接需要发送方登录；打开链接下载则从不需要账号。
链接可设置 1 小时、1 天、3 天或 7 天后过期，也可以设为首次下载完成后即焚。
把完整链接当作文件本身对待——任何拿到它的人都能解密，因此请像分享文件一样谨慎分享它。

服务器能看到什么，又看不到什么

有必要把服务器在其中扮演的角色说清楚，因为「端到端加密」这句话说起来容易，说准确却没那么简单。在实时模式下，文件本身完全不经过 Relayium 的服务器——它直接在两端浏览器之间流动。信令服务器的职责仅限于转发建立连接所需的消息（WebRTC 建立直连所需的 SDP/ICE 技术信息），帮两台设备互相找到对方；它从不看到文件内容、文件名或密钥。

当无法建立直连时——双方都处在受限的 NAT 或防火墙之后——加密数据流会退回到 TURN 中继服务器，而不是直接失败。中继只转发密文；它没有密钥，无法解密经过它的任何内容。它会做的是把中继的字节数计入发送方账号的每月中继额度，纯粹用于计量和防止滥用——从不检查里面的内容。

常见问题

Relayium 能读到我的文件吗？

不能。实时模式下，加密密钥在两台设备上各自独立推导，从不离开设备——Relayium 的服务器从未见过这把密钥或文件内容。对于存储链接，密钥只存在于 URL 片段中，浏览器从不会把它发给任何服务器，因此服务器始终只持有它无法解密的密文。

服务器到底能看到什么？

实时模式下，只能看到用来撮合两台设备的连接建立信息——从不涉及文件字节。对于存储链接，它能看到密文以及大小、过期时间等记账信息——从不涉及明文、文件名或解密密钥。

TURN 中继是不是一个薄弱环节？

它只是在无法直连时才启用的兜底方案，且始终只处理密文——它没有密钥，无法读取经它中继的内容。Relayium 会把中继的字节数计入你账号的每月额度，但从不检查内容本身。

Relayium 是开源的吗？

是的。协议设计以及全部前后端代码都以 MIT 许可证公开在 GitHub 上，因此这里描述的加密方案可以被独立审查，而不必单凭信任。

如果屏幕上两边的校验码不一致怎么办？

立即停止传输。码不一致意味着「先承诺后揭示」的校验没有通过，这指向的是可能存在中间人，而不是一次无害的小故障——在弄清楚原因之前不要继续。

想亲眼看看实际效果？发起一次传输，亲自见证校验码的出现。

立即试用 Relayium