kp-031 密码学基石：对称加密、非对称加密与数字签名

注：本文基于模型知识整理，建议结合权威教材与 RFC 原文核对细节。

一句话定义

密码学为网络安全提供四个可组合的原语：对称加密保机密、非对称加密解决密钥分发、哈希与 HMAC 保完整性与来源、数字签名提供认证与不可否认性——HTTPS 等一切安全协议都是对这些原语的编排。

为什么重要

TLS、SSH、代码签名、即时通讯加密全部建立在这几块基石上。不掌握它们，读不懂 kp-024 的 TLS 握手，也看不懂 kp-032 中攻击为何得手、防御为何成立；而把「加密」「哈希」「签名」混为一谈，正是工程实现中反复出现的真实漏洞来源。

前置知识

建议先读 kp-004《封装与复用》，理解报文如何在层间封装、哪些字段需要保护；若尚未读 kp-024《HTTPS/TLS》，可在读完本文后回看其握手流程，两文互为印证。

核心概念

安全四目标与威胁对应：机密性防窃听、完整性防篡改、身份认证防冒充、不可否认性防抵赖。
对称加密（Symmetric Encryption）：加解密同一密钥；现行标准是高级加密标准（Advanced Encryption Standard, AES），密钥长度取 128 位或 256 位。
非对称加密（Asymmetric Encryption，又称公钥密码）：公钥加密、私钥解密；代表是 RSA（基于大整数分解难题）与椭圆曲线密码（Elliptic Curve Cryptography, ECC，基于椭圆曲线离散对数难题）。
密码学哈希（Cryptographic Hash）：任意长度输入映射为固定长度摘要，现行常用 SHA-256。
基于哈希的消息认证码（Hash-based Message Authentication Code, HMAC）：带密钥的哈希。
数字签名（Digital Signature）与证书（Certificate）：不可否认性的来源、公钥的信任载体。

公式与模型

密钥数量对比：n 个人两两保密通信，对称体制需维护 n(n−1)/2 把密钥（n=100 时约 4950 把）；公钥体制每人一把私钥共 n 把，公钥可公开分发。

签名与加密的方向对照：

加密：c = E(K_pub, m)，m = D(K_pri, c)——公钥加密，私钥解密；
签名：s = Sign(K_pri, H(m))，Verify(K_pub, s, H(m))——私钥签名，公钥验签。

两个方向恰好相反，这是本章最容易混淆的一点。

图示

混合加密体制（TLS 的骨架）：

  发送方                                   接收方
    │ 1. 非对称手段协商出一次性会话密钥 K_s      │
    │ ──────────────────────────────────────► │
    │ 2. 数据全程用 AES(K_s) 对称加密           │
    │ ══════════════ 密文流 ════════════════► │ 解密
    │        慢（只用一次，传的是密钥）            │
    │                        快（每帧都用，传的是数据）

数字签名流程：

  发送方 A                                  验证方（任何人）
    │ m ──哈希──► h ──A 的私钥签名──► s        │
    │ ════════════ (m, s) ════════════════► │ 用 A 的公钥验 s，
    │                                       │ 并重算 H(m) 比对
    │ 谁能签？只有持有 A 私钥的 A               │
    │ 谁能验？任何人（公钥公开）                │

原理与机制

对称加密与它的死结。 对称加密速度快，适合加密大块数据，AES 经受住了密码学界的长期公开检验。但它有结构性难题——密钥分发：双方必须先共享同一把密钥，而在不安全的网络上「先安全地把密钥送过去」本身就需要加密，陷入鸡生蛋的死循环；n 个用户两两通信更退化为 n(n−1)/2 把密钥的保管灾难。密钥分发问题正是非对称加密的出发点。

非对称加密：用数学难题造单向门。 公钥密码基于「陷门单向函数」：正向计算容易，没有陷门（私钥）时反向计算不可行。RSA 的安全性依赖大整数分解——两个大素数相乘容易，把乘积分解回去在现有算力下不可行；ECC 依赖椭圆曲线离散对数难题，同等安全强度下密钥更短，NIST SP 800-57 给出的等价参考是 256 位 ECC 与 3072 位 RSA 相当。代价是运算慢，只适合加密小块数据或封装密钥，不适合大流量。

混合体制是必然选择。 工程上的标准答案：用非对称手段完成一次性的会话密钥协商（如 TLS 中的 ECDHE 密钥交换），之后所有数据用对称加密（如 AES-GCM）保护——非对称负责「慢而关键的那一次」，对称负责「快而大量的每一帧」。这正是 kp-024 中 TLS 握手与数据传输两个阶段的分工。

哈希：保完整性，但不是加密。 密码学哈希要求单向性（给定摘要难还原原文）与抗碰撞性（难找到两个不同输入得到相同摘要）；SHA-256 是现行主流，MD5 与 SHA-1 已被实际碰撞攻击击破，新用途一律禁用。注意：哈希没有密钥、不可逆，不是加密；裸哈希只能校验「数据没变」，不能校验「数据来自谁」——攻击者可以把摘要连同数据一起替换。

HMAC：补上来源这一环。 HMAC 用密钥参与哈希计算，只有持有相同密钥的方才能算出一致的值，于是同时完成完整性校验与来源认证，广泛用于双方已共享密钥的场景（如 TLS 记录层校验、各类 API 签名）。

数字签名：不可否认性的全部来源。 发送方对消息哈希用私钥签名并附在消息后；验证方用发送方公钥验签并重算哈希比对。方向务必记清：签名用私钥、验签用公钥，与加密恰好相反。正因为私钥只有本人持有、公钥人人可用，「此消息确系本人发出且未被改动」才能对任何第三方成立——这是不可否认性，单纯加密或 HMAC 都给不出（HMAC 双方同持密钥，无法向第三方区分是谁生成）。

证书：给公钥上个户口。 还剩最后一个缺口：你拿到的「对方公钥」怎么确认真是对方的？中间人可以把自己的公钥递给你。证书由证书机构（Certificate Authority, CA）用自己的私钥对「身份＋公钥」整体签名，把两者绑定；验证方用内置的 CA 根证书逐级校验证书链。CA 体系解决的是公钥本身的分发可信问题，正是 kp-024 TLS 握手第一环节的答案。

实例分析

软件发布是三原语协作的常见样本：官网提供安装包的同时给出 SHA-256 校验和与开发者数字签名，用户先验签（确认包出自该开发者、途中未被篡改），再可选重算哈希做本地复核。TLS 会话则是完整编排：证书验证（非对称＋CA）到 ECDHE 协商会话密钥（非对称），再到记录层 AES-GCM 加密与校验（对称）——一次非对称运算、海量对称运算，兼顾安全与性能。

常见误区

「RSA 比 AES 安全」：安全性取决于密钥长度与用途，不取决于算法家族；两者职责不同，无从比较「谁更安全」。
「哈希就是加密」：哈希无密钥、不可逆；「把密码哈希后加密存储」在概念上就是混淆，正确说法是加盐哈希存储。
「签名就是用私钥加密消息」：签名针对消息哈希而非整条消息，目的不是保密；签名用私钥、验签用公钥。
「MD5/SHA-1 弱一点但还够用」：两者已被构造出实际碰撞，安全场景必须迁移到 SHA-256 及以上。
「对称加密过时了」：恰恰相反，数据加密的主力始终是对称加密，非对称只负责密钥分发与签名。

自测题

非对称加密解决了对称加密的哪个死结？

答案要点：密钥分发：无需预共享安全信道即可建立保密通信；n 个用户的密钥量从 n(n−1)/2 降到 n。

一条消息既要保密又不可否认，应如何组合原语？

答案要点：先哈希并用发送方私钥签名附在消息后，再对接收方（或会话密钥）加密整体；验证时先解密再验签——签名与加密各司其职。

签名与加密的密钥方向有何不同？

答案要点：加密是公钥加密、私钥解密；签名是私钥签名、公钥验签，且签名对象通常是消息哈希；两个方向恰好相反。

哈希、HMAC、数字签名在「验证来源」上的能力差异？

答案要点：裸哈希无来源能力；HMAC 能向通信双方证明消息出自共享密钥持有者，但无法向第三方区分；数字签名可向任何第三方证明且不可抵赖。

证书解决了什么问题？没有 CA 体系，HTTPS 会怎样？

答案要点：解决「公钥归属」的信任问题；没有 CA，浏览器无从判断服务器公钥真伪，中间人可随意替换公钥，TLS 的认证基础随之崩塌。