最后更新: 2026-07-01
Relayium 的设计宗旨是：掌握密钥的是传输文件的双方，而不是服务器。本页说明究竟保护了什么、如何保护，以及这份保护的边界。
一句话概括：实时模式下你的文件绝不经过我们的服务器；加密密钥在每台设备上重新生成、绝不离开设备；一段简短的校验码让双方能识破恶意服务器。以下是细节。
每次传输都会在各自设备上重新生成一对临时的 X25519 密钥。两台设备通过密钥交换协商出一个共享的 AES-256-GCM 密钥，它只存在于两端浏览器中。每个数据块都用该密钥配合唯一的随机数加密，因此信令服务器——以及任何中继——只能看到密文。
WebRTC 自带的加密（DTLS）会通过信令服务器交换密钥指纹，因此不诚实的服务器可能居中调包密钥。为识破这种攻击，Relayium 从双方公钥推导出一段 6 位短校验码（SAS）并显示在两端屏幕上。两边的码一致，就说明没有人居中。
单纯的 6 位数字（约 20 比特）理论上可能被中继抢先暴力凑出一个相同的码。Relayium 用「先承诺后揭示」握手堵住这个缺口：双方先各自发送密钥的哈希作为承诺，收到对方的承诺后才揭示真正的密钥。这样服务器就无法事后挑选一个能撞上的密钥，短校验码因此依然可信。
本服务的设计确保以下内容在任何模式下都绝不会到达我们的服务器：
实时模式下文件字节根本不经过服务器——它们在两台设备之间直接流动。信令服务器只转发建立连接所需的消息，能看到的仅有房间归属（你的公网 IP）、你自选的设备昵称以及在线状态。
当两台设备无法跨网络直接建立连接（受限的 NAT 或防火墙）时，加密流会经由 TURN 服务器中继，让传输仍能完成。系统始终优先尝试点对点直连；中继只是兜底，且只有配对码与分享链接的会话才会获发中继凭证。
可选的下载链接模式用于对方不在线的场景。你的浏览器在任何内容上传之前先用 AES-256-GCM 加密文件，而解密密钥只放在 URL 片段中——也就是 # 之后的部分——浏览器绝不会把它发送给服务器。
除了保密性，每个文件的完整性也会被校验。每个数据块都带有 AES-GCM 认证标签，接收端还会端到端校验每个文件的 SHA-256 哈希，因此损坏或被篡改的文件会被检出，而不会被悄悄接受。
端到端加密保护的是数据在两个诚实端点之间的传输过程。就设计而言，它无法防范：
Relayium 可在任何支持 WebRTC 且经 HTTPS 访问的现代浏览器中运行。少数能力因浏览器而异：
协议设计与全部前后端代码都在 GitHub 公开，任何人都能审查其密码学实现、自行运行服务器或参与贡献。如果你发现安全问题，请通过仓库上 GitHub 的私密漏洞上报渠道私下报告，而不要公开提交 issue。