加密与协议

SecurQbit 使用构建于 TLS 1.3 之上的现代、行业标准密码学来保护你的流量——这正是为在线银行和遍布全网的 HTTPS 提供安全保障的同一套久经验证的协议。这意味着采用经认证的 AEAD 加密算法和具备前向保密性的密钥交换，且没有会削弱安全性的旧式模式。本页解释这些原语、握手过程，以及为何做出这些选择。

AEAD 加密算法

SecurQbit 使用由 TLS 1.3 定义的 AEAD（带关联数据的认证加密）加密算法来加密流量。AEAD 在单次操作中同时完成加密和认证，因此每个数据包既保密又能检测篡改——被修改的数据包会被检测出来并丢弃。

• ChaCha20-Poly1305 —— 在软件中快速且为恒定时间运算，非常适合没有专用 AES 硬件的移动 CPU。通常是手机上的默认选项。
• AES-256-GCM —— 在具备硬件 AES 加速的地方（大多数现代设备）极快，并使用 256 位密钥。

客户端和服务器会针对你设备的能力协商出最佳的加密算法。

前向保密性

SecurQbit 通过 基于 X25519（Curve25519）的临时椭圆曲线 Diffie-Hellman 密钥交换 来建立会话密钥。每个会话都从短暂存在的临时值派生出全新的密钥，这些值在会话结束时被丢弃。

这提供了 前向保密性：即使某个长期密钥在未来某时被泄露，过去的会话也无法被追溯解密，因为保护它们的密钥已不复存在于任何地方。结合 纯 RAM 服务器，没有任何被持久保存的内容可以回头解锁。

握手概述

连接运行于一个真正的 TCP 443 端口上的 TLS 1.3 会话——在线路上与普通网页流量无法区分。

1. 密钥交换 —— 客户端和服务器各自生成临时 X25519 密钥对，并在 TLS 1.3 握手期间交换公开值。
2. 共享密钥 —— 双方通过椭圆曲线 Diffie-Hellman 计算出相同的共享密钥；它从不被传输。
3. 密钥派生 —— 使用 HKDF 从共享密钥派生出会话密钥，每个方向使用各自独立的密钥。
4. 服务器认证 —— 在任何用户数据流动之前，服务器先证明其身份，从而击败中间人企图。
5. AEAD 隧道 —— 后续所有流量都使用协商好的 AEAD 加密算法进行加密和认证。

由于承载层是真正的 TLS 1.3 而非对它的模仿，会话会融入正常的 HTTPS 之中，而无需一个独立的、可被识别指纹的封装。关于这如何击败深度包检测，请参阅 防火墙突破与混淆。

Client ── ephemeral X25519 pubkey ──▶ Server   (TLS 1.3 / TCP 443)
Client ◀── ephemeral X25519 pubkey ── Server
both:  ECDH → shared secret → HKDF → per-direction AEAD keys
data:  AEAD(ChaCha20-Poly1305 | AES-256-GCM) over genuine TLS 1.3

原语一览

为何做出这些选择

• 构建于 TLS 1.3 之上 —— 全球受到最严格审视、部署最广泛的安全传输协议；不可能降级到脆弱的旧式加密算法。
• AEAD 优于旧式模式 —— 单遍认证加密消除了填充预言（padding-oracle）和篡改攻击的整类问题。
• 两种加密算法选项 —— ChaCha20-Poly1305 让没有 AES 硬件的手机保持快速；AES-256-GCM 在有硬件加速的地方加以利用。
• 临时 X25519 密钥交换 —— 快速、抗侧信道，并在设计上即具备前向保密性。
• 无冗余加密 —— 已加密的流量（例如你浏览的 HTTPS）会被高效承载，而不会附加浪费性的第二层批量加密，从而保持隧道快速。
• 标准的、经充分分析的原语 —— SecurQbit 倾向于采用经广泛审计的密码学，而非新颖、未经验证的方案。

注意： 加密保护的是你发送的内容；混淆隐藏的是你正在使用 VPN 这一事实。关于这些层如何组合，请参阅 安全架构。