端到端加密在文件传输中的工作原理

《个人信息保护法》（PIPL）第五十一条要求数据处理者对个人信息采取加密等安全技术措施；《数据安全法》（DSL）同样要求对重要数据实施加密保护。端到端加密（E2EE）的核心含义是：离开你设备的字节以某个从未接触过服务器的密钥加密，只有你的预定接收方才能解密。服务器只存储密文，什么有意义的内容都看不到，即便遭受入侵也不会暴露文件内容。这套加密方案通常由对称加密算法（如AES-256-GCM或XChaCha20-Poly1305）加密文件本体，辅以密钥交换算法（如X25519 ECDH或RSA-OAEP）保护密钥材料。

E2EE实际防御的威胁模型

E2EE专门防御以下威胁：传输服务商遭到黑客攻击、被传票要求配合或本身存在恶意；网络攻击者在代理处拦截TLS解密后的流量；存储桶的备份快照落入错误之手；以及服务商内部人员的未授权访问。它不防御发送方或接收方设备上的恶意软件、捕获解密链接的钓鱼攻击，以及接收方账户被盗用。理解威胁模型至关重要，因为"已加密"这个词经常被滥用于指代"传输使用TLS加上服务器端AES静态加密"——这种方案下服务提供商仍然持有密钥。

对文件内容的对称加密

文件使用对称算法加密，因为公钥密码学处理大量数据时速度太慢。现代首选是AES-256-GCM，定义于NIST SP 800-38D，在一次操作中同时提供机密性和认证完整性。每个文件使用随机生成的256位密钥和唯一的96位随机数（nonce，绝不与同一密钥重复使用）进行保护。XChaCha20-Poly1305定义于RFC 8439和RFC 8103，在没有AES-NI硬件加速的设备（如较旧的ARM处理器）上通常速度更快。两种算法都会生成密文加一个128位认证标签，任何篡改都会被检测到。

从密码派生密钥

当E2EE使用密码时，密码本身绝不直接作为加密密钥——那样会对暴力破解太脆弱。取而代之的是使用密钥派生函数：PBKDF2-HMAC-SHA256（OWASP 2025建议迭代次数60万次或更多）、Argon2id（m=19 MiB，t=2，依照RFC 9106）或scrypt（RFC 7914）将密码拉伸为强密钥。随机生成的128位或256位盐值可防止彩虹表攻击。派生得到的密钥用于加密文件。盐值和迭代次数与密文一同存储，供接收方输入密码时重新构造密钥。

基于账户的公钥封装

当接收方拥有已发布公钥的账户时，无需输入密码。发送方生成一个随机文件加密密钥（FEK），用FEK通过AES-256-GCM加密文件，然后按照RFC 7748的X25519 ECDH密钥协议结合RFC 5869的HKDF-SHA256派生封装密钥，或使用PKCS#1 v2.2的RSA-OAEP（SHA-256），将FEK加密至每个接收方的公钥。封装后的FEK与密文一并存储。只有持有接收方私钥的人才能解封FEK并解密文件。这正是Signal和WhatsApp用于消息的模型，应用于文件载荷的版本。

基于链接的E2EE：URL片段的妙用

浏览器文件传输中有一个巧妙的技巧：将解密密钥存储在URL片段（#之后的部分）中。片段在HTTP请求中永远不会发送到服务器。形如https://example.com/d/abc123#k=B9kZtR...的链接，服务器只能看到文件ID，密钥部分留在客户端。浏览器下载密文，在JavaScript中读取URL片段，并在本地完成解密。服务提供商永远看不到密钥。注意事项是：一旦链接在任何地方泄露——日志、截图、即时通讯应用的预览——密钥也随之泄露。

AEAD与哈希的完整性保证

GCM和ChaCha20-Poly1305等带关联数据认证加密（AEAD）模式可防止篡改。密文中哪怕一位翻转，认证标签的验证就会失败，解密函数返回错误而非乱码明文。在AEAD之上，许多实现还对明文计算SHA-256或BLAKE3哈希并作为清单条目，供接收方在解密后验证文件与发送方意图一致。这对于分块传输的大文件尤为重要——部分传输成功时，若不做验证，尾部缺失可能会被静默忽略。

大文件的分块加密

在单次AES-GCM操作中加密一个10 GB文件需要维护10 GB的状态，在浏览器中不切实际。实际实现将文件分成若干块（通常每块1 MB到16 MB），每块独立使用派生子密钥和基于计数器的nonce加密。age加密工具（定义于age-encryption.org）使用64 KB分块配合ChaCha20-Poly1305。分块边界还让浏览器能够通过Streams API流式解密——文件全部到达之前就可以开始写入磁盘——同时支持网络中断时的断点续传。

E2EE之上的传输安全

TLS 1.3（定义于RFC 8446）在E2EE之上仍然不可或缺——不是为了保护载荷机密性（载荷已经加密），而是为了保护元数据的隐私性：文件名、大小和时序信息。TLS 1.3配合X25519前向保密密钥交换，即便服务器的长期密钥日后被泄露，历史会话记录也无法被解密。证书锁定或HSTS预加载可防止降级攻击。E2EE加TLS 1.3的组合，既保护文件内容，也保护"谁在向谁发送什么"这一操作模式。

常见的实现陷阱

有三个错误反复出现：第一，在AES-GCM中对同一密钥重用nonce会灾难性地破坏机密性——始终使用新鲜的随机nonce或绝不重复的计数器；第二，用自制代码实现加密算法，而非使用libsodium、Web Crypto API（SubtleCrypto）或BoringSSL等经过审计的库——常量时间操作对于防止计时攻击至关重要；第三，没有对文件元数据和内容一起进行认证——如果发送方身份、文件名或接收方列表没有包含在AAD（关联认证数据）中，攻击者就可以在不被察觉的情况下替换元数据。HexaTransfer通过在客户端使用标准的Web Crypto原语并采用经过审查的实现模式来避免这些问题。

验证一项服务是否真正实现了E2EE

对营销说辞保持审慎。真正的E2EE意味着服务提供商即便收到法院命令也无法解密文件。请寻找：描述确切算法（AES-256-GCM、X25519、HKDF、PBKDF2迭代次数）的公开技术文档，可供审计的开源客户端代码，以及承认E2EE能防御什么、不能防御什么的威胁模型说明。对加密文件提供服务器端密码恢复的服务，不是真正的E2EE——它们持有密钥。声称"零知识"的服务应以密码协议描述而非口号来支撑这一说法。

访问 https://hexatransfer.com — 免费，无需注册，最大10 GB。