Relayium 如何对文件端到端加密

最近更新: 2026-08-06

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

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

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

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

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

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

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

要做这次比对，你需要什么

两台设备都在你面前，或者对方此刻正坐在他那台前面。
一条不属于这次传输的通道——一通电话，或者你们同处的房间。把校验码粘进你正担心的那个聊天里，什么也证明不了。
十秒钟。这就是唯一能抓住不诚实服务器的那道检查的全部成本。

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

Relayium 用一段简短的校验码堵上这个缺口。两台设备都从各自的公钥推导出同一段 6 位短校验码（SAS），并可以把它显示在屏幕上。是否显示、是否停下来核对属于「高级验证」，默认关闭——所以默认的传输并不会显示任何校验码。这里描述的其余部分对每一次传输都照常生效：每次新生成的密钥、加密、「先承诺后揭示」握手，以及逐块的认证。默认传输缺少的正是这道核对本身——要发现密钥被调包，或者对面根本是陌生人，需要打开高级验证，并且两个人真的通过其他渠道核对这段码。如果两边的码一致，说明公钥没有被调包：信令服务器或中继服务器没有冒充任一端点，也没有终止应用层端到端加密。这并不意味着传输路径上没有服务器——跨网络传输的密文仍可能按设计经过 TURN。一段普通的 6 位数字码只有约 20 比特，一个位置合适的攻击者理论上可以在看到双方真实密钥后暴力凑出一个匹配的码。为防止这一点，Relayium 采用「先承诺后揭示」的握手方式：双方先各自发送一段对自己密钥的哈希承诺，收到对方的承诺之后才揭示真正的密钥。这个顺序意味着恶意服务器必须在还没见到真实密钥的情况下盲目地承诺一个伪造密钥——它无法事后再挑一个能撞上的密钥，短校验码因此依然可信。

在两台设备之间发起一次传输，等两边屏幕上都出现校验码。
```
https://relayium.com/
```
通过带外通道把其中一个逐位念出来——不要复制进应用里，也不要发进同一个聊天串。
六位全部比对。只对上一部分，就等于没对上。
只有完全一致才接受。如果不一致，拒绝，并先弄清楚对方到底在哪台机器上，再重试。
在 CLI 上把这次比对从可选改成阻塞：--verify 会让传输停在这一步等你确认，在有人真的看过之前，一个字节都不会动。
```
relayium send --verify ./report.pdf
```

比对一致证明了什么、又没证明什么

两块屏幕显示同样的六位数字，说明两端各自钉住的证书指纹是一致的，也就意味着会合服务器没有替换端点、没有冒充任何一方。这正是本节所讲的那种攻击。

它认证的是两个端点。它不能证明中间每一跳网络的任何事情，而且如果没有人真的去比对，它什么都证明不了——这正是 --verify 存在的理由。

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

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

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

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

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

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

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

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

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

跨网络传输的加密数据流经 TURN 中继服务器转发——在受限的 NAT 或防火墙之后，直连往往根本无从建立。中继只转发密文；它没有密钥，无法解密经过它的任何内容。它会做的是把中继的字节数计入发送方账号的每月中继额度，纯粹用于计量和防止滥用——从不检查里面的内容。

当比对出问题时

三种结果，只有第一种是紧急情况。能分清自己正面对哪一种，就已经拿到了大半价值。

你看到什么、检查什么、它意味着什么

两块屏幕显示的校验码不同。

https://relayium.com/   # the two screens show different verification codes

停下，不要发这个文件。校验码不同意味着两端钉住的证书指纹不一致，也就是说对面那台并不是你以为的机器。先带外确认对方在哪台设备上，然后重新开始。再跑一次时加上 --verify，传输会停在那次比对上等你，而不是把它交给你的注意力。

一直没有出现校验码。

https://relayium.com/   # no verification code on screen yet

校验码是从一条连接推导出来的，所以它在两端连上之后才存在。在那之前没有什么可比，而「始终连不上」和「两边校验码不一致」是两个不同的问题。

你把其中一个校验码粘进了你们正在用的那个聊天里来做比对。

relayium send --verify ./report.pdf   # holds the transfer at the comparison

这样并没有检验到你想检验的东西。如果你担心的正是那条通道，那么能改动传输的攻击者同样能改动被粘进去的那个码。请念出来，或者换一条与你正在核查的那条失效方式不同的通道。

常见问题

Relayium 能读到我的文件吗？

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

服务器到底能看到什么？

同一网络的实时模式下，只能看到用来撮合两台设备的连接建立信息——从不涉及文件字节。跨网络时 TURN 中继确实会经手文件字节，但那只是它没有密钥的密文。对于存储链接，它能看到密文以及大小、过期时间等记账信息——从不涉及明文、文件名或解密密钥。

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

在浏览器里，它承载所有跨网络传输，这是刻意如此，而不只是直连失败时的兜底方案——但它始终只处理密文，且没有密钥，无法读取经它中继的内容。Relayium 会把中继的字节数计入你账号的每月额度，但从不检查内容本身。

Relayium 是开源的吗？

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

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

立即停止传输。两边的码不一致，说明两台设备看到的不是同一条连接——这正是密钥被调包或存在中间人时会出现的结果，而不是一次无害的小故障。（「先承诺后揭示」握手失败是另一回事，也发生得更早：它会让连接直接中止，根本不会显示任何校验码。）在弄清楚原因之前不要继续。

想亲眼看看实际效果？在开始新连接之前打开高级验证，这样校验码比对和各处确认步骤从一开始就生效。

立即试用 Relayium