安全与威胁模型

最后更新: 2026-08-02

Relayium 的设计宗旨是：掌握密钥的是传输文件或临时文本的双方，而不是服务器。本页说明究竟保护了什么、如何保护，以及这份保护的边界。

一句话概括：同一网络中的实时文件与消息在设备间直接传输；跨网络浏览器会话使用只承载端到端加密密文且不持有内容密钥的中继。每次会话都会使用新密钥；此外还有一个可选的校验码，双方带外核对它就能发现信令拦截。以下是细节。

浏览器实时文件加密（X25519 + AES-256-GCM）

浏览器进行实时文件传输时，每次传输都会在各自设备上重新生成一对临时的 X25519 密钥。两个浏览器通过密钥交换协商出共享的 AES-256-GCM 密钥。每个文件数据块都用该密钥配合唯一的随机数加密，因此信令服务器和任何中继看到的都是密文，而非文件明文。CLI 传输使用下文所述的另一套 TLS 1.3 直连协议。

• 密钥是临时的、每次传输独立——不会跨会话复用。
• 共享密钥在两台设备上协商得出，绝不发送到或存储于任何服务器。
• 加密施加在应用层，位于 WebRTC 自身传输层安全之上，因此即便传输层被攻破也依然有效。

校验码（SAS）——识破恶意服务器

WebRTC 自带的加密（DTLS）会通过信令服务器交换密钥指纹，因此不诚实的服务器可能居中调包密钥。为识破这种攻击，Relayium 从双方公钥推导出一段 6 位短校验码（SAS），并可以把它显示在两端屏幕上。只有双方通过带外渠道核对一致时，相同的校验码才提供最强的拦截检测保证。 是否显示这段码、是否停下来核对，是一个偏好设置——网页端叫「高级验证」，默认关闭；CLI 里是 `--verify`。关掉它改变的只是屏幕上显示什么、哪些步骤会停下来等你确认，不改变加密：下面的「先承诺后揭示」握手在每条连接上照常运行，揭示对不上就直接拒绝连接；密钥仍在你的设备上生成、从不发给我们；中继仍然只承载密文；在浏览器里，接收文件在写入任何内容之前仍会先询问你——原生 macOS 应用则直接写入它配置的保存位置（默认是「下载」文件夹）。这道询问防的是未经请求的写盘，而不是「对面是谁」；后者只有核对校验码才能确认。

单纯的 6 位数字（约 20 比特）理论上可能被中继抢先暴力凑出一个相同的码。Relayium 用「先承诺后揭示」握手堵住这个缺口：双方先各自发送密钥的哈希作为承诺，收到对方的承诺后才揭示真正的密钥。CLI 传输使用另一套 SAS，它通过「先承诺后揭示」交换固定 TLS 证书指纹来推导；同样只有真的有人带外核对了才起作用，而 `--verify` 就是那个停下来核对的开关。

• 为获得最强的保证，请先打开高级验证，再通过带外渠道核对校验码——当面或语音通话。
• 如果两边的码不一致，请立即停止传输：可能有人正在拦截连接。

服务器无法看到或解密的明文

本服务的设计确保服务器无法看到或解密以下明文：

浏览器实时模式下，同一网络中的文件和消息字节在两台设备之间直接流动；跨网络时则以密文经过 TURN，中继不持有内容密钥。信令服务仍会处理建立连接所需的数据，并能看到公网 IP、房间归属、时间、你自选的设备昵称和在线状态等元数据。

• 你的文件内容。
• 你的文件名。
• 你的文本消息明文。
• 你的加密密钥。

浏览器文件与文本何时会经中继转发（TURN）

浏览器的跨网络文件和文本传输——即配对码会话（含其生成的加入链接）——按设计经 TURN 服务器中继，而不是作为兜底手段。受限的 NAT 与防火墙让真正的直连希望渺茫，因此应用直接强制走中继路径。同一网络的浏览器会话不会获发中继凭证，走的是直连。CLI 文件和文本传输都不使用 TURN：它们只走直连，找不到直连路径就失败。

• 中继只转发密文——它无法读取你的文件或消息，内容始终保持端到端加密。
• 我们按账号记录中继字节数，用于执行每月中继额度限制并防止滥用——我们绝不检查中继的内容，只记录字节数。
• 我们绝不检查中继内容。

临时文本传输

浏览器文本会话使用 Web 协议：双方执行临时 X25519 密钥交换，并在独立于文件传输密钥的域中派生按方向隔离的 AES-256-GCM 子密钥。每条有效 UTF-8 消息都作为独立帧进行认证和加密。跨网络时，浏览器会话按设计使用 TURN；中继只承载密文，不持有消息密钥。打开高级验证后，再通过带外渠道核对 SAS，还能发现对信令的拦截。

CLI 文本使用另一套经固定证书校验的 TLS 1.3 直连协议。它不使用浏览器的 X25519/AES 消息帧或 TURN，无法建立直连时就会失败。Relayium 不存储消息正文，但任一端点在收到文本后都可以复制、记录、截图或以其他方式留存。

• 双方必须同时在线；Relayium 不提供离线文本投递，也不保留服务器端消息历史。
• 服务器必然会处理连接元数据，例如 IP 地址、房间归属、时间，浏览器会话的设备昵称与在线状态，以及适用时用于创建配对码的账号关联。
• 对于 TURN 会话，Relayium 可能记录中继字节数以执行额度并防止滥用，但不会检查消息明文。

暂存下载链接——密钥绝不离开你的浏览器

可选的下载链接模式用于对方不在线的场景。你的浏览器在任何内容上传之前先用 AES-256-GCM 加密文件，而解密密钥只放在 URL 片段中——也就是 # 之后的部分——浏览器绝不会把它发送给服务器。

• 服务器只存储密文，外加用于配额与清理的密文大小和时间戳——绝不存明文、文件名或密钥。
• 任何拿到完整链接的人都能解密，因此请把链接本身当作文件对待，通过可信渠道分享。
• 链接可设置有效期（1 小时起，最长 14 天，取决于你的套餐），或设为首次完整下载后即焚。

文件完整性（SHA-256）

除了保密性，每个文件的完整性也会被校验。每个数据块都带有 AES-GCM 认证标签，接收端还会端到端校验每个文件的 SHA-256 哈希，因此损坏或被篡改的文件会被检出，而不会被悄悄接受。

Relayium 不能防范什么

端到端加密保护的是数据在两个诚实端点之间的传输过程。就设计而言，它无法防范：

• 任一端设备或浏览器被攻陷——恶意软件、恶意浏览器扩展，或有人偷看屏幕。
• 服务器必然会接触到的元数据：会话时间、中继字节数，以及（若为暂存下载链接或配对码会话）创建链接或配对码的账号。
• 接收方在收到文件或消息后选择留存、复制或转发。
• 通过不可信渠道分享下载链接，因为解密密钥就在链接里。

浏览器支持及其限制

Relayium 可在任何支持 WebRTC 且经 HTTPS 访问的现代浏览器中运行。少数能力因浏览器而异：

• 桌面版 Chrome 与 Edge 具备 File System Access API，会把大文件直接流式写入磁盘，几乎没有内存上限。
• Firefox、Safari 以及所有手机浏览器（iOS 上的浏览器全都是 WebKit）没有这个 API，在实时接收路径上只能把文件攒在内存里，因此超过约 256 MB 时应用会先给出提示——这是一个刻意保守的估计值，而不是实测出来的硬上限。这个量级的文件建议改用桌面版 Chrome/Edge，或改走下载链接模式，其下载页还可以通过 service worker 流式落盘。
• WebRTC 需要安全上下文（HTTPS）；应用不会在纯 HTTP 下建立连接。

开源与问题上报

协议设计与全部前后端代码都在 GitHub 公开，任何人都能审查其密码学实现、自行运行服务器或参与贡献。如果你发现安全问题，请通过仓库上 GitHub 的私密漏洞上报渠道私下报告，而不要公开提交 issue。