illegalCreed

中文

English

中文

English

Appearance

对称与非对称加密 ​

基于 HTTP 现代标准 · 核于 2026-06

速查 ​

  • 对称加密：加密、解密用同一把密钥（共享密钥 / 会话密钥）。代表算法 AES、ChaCha20。快、适合大数据流，痛点是密钥分发——双方怎么先安全地共享这把密钥？
  • 非对称加密：密钥成对（公钥 + 私钥），一把加密只能用另一把解密。代表算法 RSA、ECC（椭圆曲线，等强度下密钥更短、运算更快）。慢，但解决了密钥分发与身份认证。
  • 公钥加密 / 私钥解密：任何人都能用你的公钥加密，只有持私钥的你能解——这就把「共享密钥」难题转成了「公开公钥」。
  • 私钥签名 / 公钥验签：只有持私钥者能生成签名，任何人用公钥可验证——保证完整性与不可否认（身份）。
  • 哈希（SHA-256）：单向、定长（256 位）、雪崩效应（改 1 比特，摘要面目全非）。它不是加密（不可逆、无密钥），是「内容指纹」。
  • 数字签名 = 哈希 + 非对称：先对内容做哈希得摘要，再用私钥加密摘要即签名；验签方用公钥解出摘要，与自己算的摘要比对。
  • TLS 用混合加密：握手阶段用非对称安全地协商出一把对称会话密钥，之后所有应用数据都用对称加密传——兼顾安全（解决分发）与性能（对称快）。
  • 每个会话一把新的会话密钥；新会话重新握手、重新协商，互不复用。
  • 前向保密（PFS）：会话密钥用临时密钥协商（ECDHE）生成、用完即弃，私钥日后即便泄露也无法解密历史流量——细节见 TLS 握手流程。
  • 选型直觉：传大量数据 → 对称；协商密钥 / 验证身份 / 签名 → 非对称；校验完整性 → 哈希。三者各司其职，TLS 把它们组合起来。

对称加密：一把钥匙锁与开 ​

对称加密（symmetric-key cryptography）指加密和解密使用同一把密钥的算法。MDN 的定义直白：「使用同一把密钥进行加密和解密的密码算法」。这把共享的秘密又叫「密钥」（secret key）或「会话密钥」。

它的优点是快：对称算法效率极高，可以在不显著影响性能的前提下加密海量数据，因此适合给真正的应用数据流（网页、视频、API 响应）加密。

主流算法两类：

  • AES（Advanced Encryption Standard）：分组密码，按 16 字节为一块处理，必须配合工作模式使用（如 GCM、CTR、CBC）。现代 TLS 首选 AES-GCM，加密同时带完整性校验。
  • ChaCha20：流密码，常与 Poly1305 组成 ChaCha20-Poly1305。在没有 AES 硬件加速的设备（如部分移动端）上比 AES 更快，是 TLS 1.3 的标配套件之一。

对称加密的死穴：密钥分发

对称加密本身很安全也很快，但有个前提——通信双方必须先持有同一把密钥。问题就出在这「先」字上：在一个不安全的网络（互联网）里，A 怎么把这把密钥安全地交给 B？直接发出去就会被中间人截获，截获了就能解密一切。这就是密钥分发（key distribution）难题，单靠对称加密无解。

非对称加密：公钥私钥，一对钥匙 ​

非对称加密（asymmetric / public-key cryptography）用成对的密钥：一把公钥（public key，可公开）、一把私钥（private key，严格保密）。核心性质是 MDN 强调的那句：「一把密钥所做的变换，只能用另一把密钥还原」。

这对密钥能干两件事，方向正好相反：

加密方向：公钥加密，私钥解密 ​

任何人都能用公钥向私钥持有者发送加密消息，但只有私钥持有者能解密。

公钥可以放心公开，谁都能拿它加密；但只有持私钥的一方能解开。于是「如何共享秘密」这个对称加密的死穴被绕过了——不必共享秘密，只需公开公钥即可。

签名方向：私钥签名，公钥验签 ​

任何人都能验证签名，但只有对应私钥的持有者能生成它。

反过来用私钥处理数据，任何人都能用公钥验证。这就同时带来身份认证与不可否认：能验过的签名，必定出自持私钥者之手（详见 数字签名）。

主流算法：

  • RSA：可用于加密，也可用于签名，历史最悠久、最常见。
  • ECC（椭圆曲线密码，含 ECDH 密钥协商、ECDSA 签名）：在等强度下密钥更短、运算更快、传输与存储开销更小，现代 TLS 与证书正大量转向 ECC。

非对称的代价：慢

非对称运算（大数模幂、椭圆曲线点乘）的计算量远大于对称加密——慢上几个数量级。所以它不适合给大量数据加密，而是专门用来干「关键但量小」的事：协商密钥、验证身份、签名。

哈希与数字摘要 ​

哈希函数（如 SHA-256）把任意长度的输入压成定长输出（SHA-256 固定 256 位 / 32 字节）的「摘要」（digest / 指纹）。它有三个关键性质：

  • 单向：由输入算摘要极快，由摘要反推输入在计算上不可行。
  • 定长：无论输入 1 字节还是 1 GB，输出长度恒定。
  • 雪崩效应：输入哪怕只改动 1 个比特，输出摘要也会大面积改变，看不出与原摘要的关联。

哈希不是加密

哈希没有密钥、不可逆，目的不是「保密后还能还原」，而是「给内容生成可比对的指纹」。它常用来校验完整性（内容有没有被改动），以及作为数字签名的第一步。把它和加密混为一谈是常见误区。

数字签名：用私钥背书内容 ​

数字签名 = 哈希 + 非对称，目标是同时证明「内容没被篡改」（完整性）和「确实是某人发的」（不可否认 / 身份）。流程如下：

签名与验签流程

签名方（持私钥）：

  1. 对原始内容做哈希（如 SHA-256），得到摘要；
  2. 用自己的私钥加密这个摘要，产物就是数字签名；
  3. 把「原始内容 + 签名」一起发出。

验签方（持公钥）：

  1. 用对方公钥解开签名，得到「原始摘要」；
  2. 对收到的原始内容自己重新做一遍哈希，得到「本地摘要」；
  3. 两个摘要完全一致 → 内容未被篡改，且必出自持私钥者之手；否则验证失败。

为什么先哈希再签？因为非对称运算慢，直接签整段内容代价高；先压成定长摘要，签名对象就只有 32 字节，又快又能锁定全文（雪崩效应保证改一点摘要就变）。

签名 ≠ 加密内容

数字签名默认不隐藏内容（原文照样可见），它保证的是「完整 + 来源可信」，而不是「保密」。保密交给加密、可信交给签名，两件事别混。

为什么 TLS 要「混合」用：兼顾安全与性能 ​

到这里两难已经很清楚：

维度对称加密非对称加密
速度快，适合大数据流慢（几个数量级），只宜小数据
密钥数量1 把共享密钥1 对（公钥 + 私钥）
密钥分发难（死穴）容易（公钥可公开）
典型用途加密应用数据协商密钥 / 身份认证 / 签名

单用任何一种都不行：只用对称，密钥没法安全分发；只用非对称，传大量数据太慢。TLS 的答案是把两者组合（混合加密），让各自只做自己擅长的事。

Cloudflare 对 TLS 的描述正是这个思路：「TLS 同时使用非对称加密和对称加密。在 TLS 握手中，客户端与服务端商定出用于对称加密的新密钥，称为会话密钥（session keys）……握手本身借助非对称密码学来保证生成会话密钥过程的安全，并验证服务端来源的身份。」

混合加密一句话

用慢而安全的非对称，安全地协商出一把对称会话密钥；之后用快的对称加密传所有数据。 非对称负责「安全地把钥匙递过去（并验明身份）」，对称负责「之后高速地锁与开」。

整体流程示意（具体握手报文见下一页）：

text
① 握手阶段（非对称登场，量小）
   客户端 ──── 借助服务端公钥 / 临时密钥协商 ────▶ 服务端
   双方各自算出 同一把「会话密钥」（对称密钥，不在网上明传）
        │
        ▼
② 数据阶段（对称登场，量大）
   客户端 ◀──── 用会话密钥做 AES-GCM / ChaCha20 加密 ────▶ 服务端
   网页、API、视频……全部走对称加密，高速且安全

每个会话都会重新握手、协商出一把全新的会话密钥，会话之间互不复用——这既是安全需要，也为下面的前向保密打好了基础。

前向保密（PFS）：留个引子

现代 TLS 进一步要求会话密钥由临时密钥协商（如 ECDHE）生成、用完即弃，且不直接依赖服务器长期私钥来传递。这样即便服务器私钥日后泄露，攻击者也无法用它解密过去截获的流量——这就是前向保密（Perfect Forward Secrecy, PFS）。它具体如何在握手中实现，见 TLS 握手流程。

小结 ​

  • 对称加密（AES / ChaCha20）一把密钥锁与开，快但有密钥分发死穴；非对称加密（RSA / ECC）公私钥成对，慢但解决了密钥分发与身份。
  • 哈希（SHA-256）单向、定长、雪崩，生成内容指纹校验完整性；数字签名 = 哈希 + 私钥，给内容签上「完整 + 来源可信」的戳。
  • TLS 用混合加密：非对称只负责在握手阶段安全协商出一把对称会话密钥（并验身份），之后所有数据走对称加密——这就是它既安全又快的根因。
  • 上一页 为什么需要 HTTPS 说明了「不加密」的代价；本页讲清了 HTTPS 底层的加密原语；下一页 数字证书与 CA 信任链 解决「公钥到底是不是对方的」这一信任问题。