对称加密 vs 非对称加密：关键区别详解

对称加密使用同一个密钥进行加密和解密——比如 AES-256-GCM，这是在传输过程中保护文件的密码算法。非对称加密使用密钥对：一个任何人都能看到的公钥，以及只有你持有的私钥，RSA-4096 和 Curve25519 等算法均属此类。对称加密速度快（在现代 CPU 上可达每秒几吉字节），但需要双方共享同一个密钥。非对称加密解决了密钥交换难题，但速度慢了约 1000 倍。每一家现代文件传输服务——HexaTransfer、Tresorit、Proton Drive、SwissTransfer——都同时使用两者：用非对称加密交换对称密钥，再用对称加密加密实际文件内容。

单密钥世界：对称加密

对称密码算法对两个方向使用同一密钥。如果我用密钥 K 加密文件，你需要同样的密钥 K 才能解密。目前仍在使用的主要对称算法有：

AES（Rijndael），有 128、192、256 位三种密钥长度，在 FIPS 197 中标准化。
ChaCha20，使用 256 位密钥，在没有 AES-NI 硬件加速的设备上更受青睐。
3DES——已于 2023 年被 NIST 弃用，请勿使用。

吞吐量是对称加密的最大优势。AES-256-GCM 在支持 Intel AES-NI 的 CPU 上每核心可达约 3–5 GB/s，ChaCha20-Poly1305 在 ARM 手机上可达 1.5–3 GB/s。加密 10 GB 文件只需几秒钟。

问题在于：如何将密钥传递给另一方？通过邮件发送密钥无济于事。这就是密钥分发问题，也是非对称加密存在的原因。

双密钥世界：非对称加密

1976 年由 Diffie 和 Hellman 发明，1977 年由 Rivest、Shamir 和 Adleman 以 RSA 的形式实现。每个用户拥有一个密钥对：公开发布的公钥和保密的私钥。用公钥加密的内容只能用私钥解密，反之亦然。

如果你想给我发一份秘密文件，你用我的公钥加密它，只有我的私钥能打开它——而我从来不需要向你分享任何秘密。密钥分发问题就此解决。

当前主要的非对称算法有：

RSA-2048 或 RSA-4096——速度慢，但支持广泛，用于 TLS 证书。
椭圆曲线（ECDH、ECDSA），使用 P-256、P-384 或 Curve25519 等曲线——密钥更短，运算更快。256 位 EC 密钥的安全性相当于 3072 位 RSA 密钥。
Ed25519——现代签名算法的默认选择，被 SSH 和 Signal 采用。

非对称加密为何不适合直接加密文件

非对称运算的计算成本很高。RSA-4096 加密在现代 CPU 上每秒约处理 100–500 次运算，每次运算处理约 470 字节（RSA 块大小减去填充）。这意味着速度约为 200 KB/s——比 AES-256-GCM 慢约 5 万倍。

用 RSA 加密 10 GB 文件需要约 14 小时，而 AES-256-GCM 只需约 3 秒。这种速度上的不对称决定了没有人会真正用 RSA 直接加密文件。

混合加密：现实世界中的做法

所有需要同时满足安全性和速度的协议都将两者结合。TLS 1.3、PGP、Signal、Age 以及所有可信的文件传输服务都采用这一模式：

发送方生成一个随机的 256 位 AES 密钥（即"会话密钥"或"文件密钥"）。
文件用 AES-256-GCM 和该密钥加密。
AES 密钥本身用收件方的公钥（RSA-OAEP 或 ECIES）加密。
密文和加密后的密钥一起传输给收件方。
收件方用私钥解密 AES 密钥，再用 AES 密钥解密文件。

非对称加密的成本只发生一次，用于处理 256 位密钥；大量文件数据则以全速对称加密处理。两全其美。

文件传输服务的差异所在

基于浏览器的传输服务面临一个额外挑战：收件方可能没有密钥对，他们只是在点击一个链接。三种模式应对这一情况：

仅使用对称链接（SwissTransfer、HexaTransfer 等）：在发送方浏览器中生成随机 AES-256 密钥，嵌入 URL 片段，收件方浏览器从片段读取密钥。无需非对称加密——片段本身就是传输通道。
账号到账号的非对称加密（Tresorit、Proton Drive）：每个用户在注册时生成 RSA 或 ECC 密钥对，为特定收件方加密的文件使用其公钥包裹。
带密码的混合方式（多种服务）：URL 片段包含盐值，用户输入密码，PBKDF2 或 Argon2id 派生对称密钥。不涉及非对称加密，但密码充当共享密钥。

基于链接的方式最简单，适合无账号的收件方。账号绑定的非对称加密更安全，因为链接丢失不会导致密钥泄露。根据你的威胁模型选择合适的方式。

数字签名：非对称加密的另一用途

非对称加密能做到对称加密做不到的事：证明作者身份。如果我用私钥签名一个文件，任何持有我公钥的人都能验证是我签的，并且确认文件自签名后未被篡改。对称加密可以提供认证（HMAC、GCM 标签），但只在已共享密钥的双方之间有效。

常用的签名算法有：

RSA-PSS 配合 SHA-256——传统但广泛支持。
ECDSA 使用 P-256 或 P-384——通过 NIST 认证，用于美国联邦系统。
Ed25519——快速、确定性、对弱随机数生成器具有抵抗力，是现代首选。

软件分发（apt、Homebrew、Docker 镜像）依赖 Ed25519 或 RSA 签名来防止供应链篡改。文件传输服务通常不直接暴露签名功能，但 AES-256-GCM 中的 GCM 认证标签在单次加密范围内提供了完整性保护。

密钥长度与安全级别

针对经典计算机的等效安全级别对照表：

128 位对称 ≈ 3072 位 RSA ≈ 256 位 EC（P-256 或 Curve25519）
192 位对称 ≈ 7680 位 RSA ≈ 384 位 EC（P-384）
256 位对称 ≈ 15360 位 RSA ≈ 512 位 EC（P-521）

NIST 对新系统的当前建议：至少 112 位安全级别，即 RSA-2048 或 P-256。联邦机构要求在 2030 年之前至少使用 128 位安全级别（RSA-3072、P-384）。

对于未来的量子计算机，对称密钥的强度约减半（Grover 算法），而 RSA 和 ECC 则会被完全攻破（Shor 算法）。NIST 于 2024 年标准化了后量子替代方案：ML-KEM（原 Kyber）用于密钥交换，ML-DSA（原 Dilithium）用于签名。迁移工作正在进行，但速度缓慢。

如何选择合适的方案

实用决策指南：

为自己加密文件（备份、归档）：使用 AES-256-GCM 配合通过 Argon2id 派生的强密码，无需非对称加密。
向已知收件方发送文件：混合方式——文件用 AES-256-GCM，会话密钥用公钥包裹。
向多个收件方发送：对文件进行一次 AES 加密，然后分别用每个收件方的公钥包裹密钥，每个收件方额外增加约 300 字节。
证明作者身份：使用 Ed25519 对密文进行签名。
通过链接临时分享：使用对称加密，密钥放在 URL 片段中。

综合运用

当前敏感传输的合理技术栈：AES-256-GCM 用于批量加密，X25519 ECDH 在收件方有账号身份时用于密钥交换，PBKDF2 或 Argon2id 用于从密码派生密钥，TLS 1.3 作为传输层。这一组合是现代经过审计的服务所部署的方案。

在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。