第一章 对称加密：单一密钥的快速加密体系

1.1 设计目标

对称加密旨在解决数据传输过程中的机密性（Confidentiality）问题，即确保未经授权的第三方无法解读通信内容。

1.2 工作机制

对称加密采用单一密钥完成加密与解密操作。发送方使用密钥 K 将明文转换为密文，接收方使用同一个密钥 K 将密文还原为明文。

text

【发送方】 【接收方】 明文 P │ ▼ ┌─────────┐ ┌──────────────┐ ┌─────────┐ │ 密钥 K │ ──► │ AES加密算法 │ ──► │ 密文 C │ └─────────┘ └──────────────┘ └────┬────┘ │ (网络传输) │ ▼ ┌─────────┐ ┌──────────────┐ ┌─────────┐ │ 密钥 K │ ──► │ AES解密算法 │ ◄─── │ 密文 C │ └─────────┘ └──────────────┘ └─────────┘ ▲ │ └────────── 密钥 K 须经由安全信道预共享 ────────┘ ▼ 明文 P ✅

1.3 核心算法

1.4 技术优势与局限

优势：

• 运算速度快，适合加密大规模数据（AES-NI硬件指令集可实现GB/s级吞吐）

• 算法成熟，经过长期密码分析考验

• 配合认证加密模式（如AES-GCM）可同时保证完整性

局限：

• 密钥分发问题：通信双方须预先共享同一密钥，在开放网络环境中难以安全实现

• 每对通信方须维护独立密钥，N方通信需管理 N(N-1)/2 个密钥

• 缺乏内生的身份认证机制

对称加密的核心矛盾在于：加密效率虽高，但密钥的安全送达本身就是一个与原问题难度相当的保密通信问题。

第二章 非对称加密：公钥密码学的革命性突破

2.1 设计目标

非对称加密旨在从根本上解决对称加密的密钥分发困境，同时为数字签名技术提供数学基础。

2.2 数学原理

非对称加密基于陷门单向函数（Trapdoor One-way Function）：正向计算容易，逆向计算困难，但掌握特定"陷门"信息后逆向计算变得可行。具体实现依赖以下数学难题：

• RSA：大整数质因数分解的困难性

• ECC（椭圆曲线密码）：椭圆曲线上的离散对数问题

• SM2：基于椭圆曲线，国产标准

2.3 密钥对机制

系统为每个用户生成一对数学上关联的密钥：

• 公钥（Public Key）：可向任何人公开，用于加密或验证签名

• 私钥（Private Key）：用户独享，绝对保密，用于解密或生成签名

其核心性质为：用公钥加密的数据，只能用对应的私钥解密。

text

【接收方】生成密钥对 │ ├────────────────► 公钥 (e, n) → 公开发布 │ └────────────────► 私钥 (d, n) → 安全存储，永不离本地 【发送方】 【接收方】 明文 P (通常为对称会话密钥) │ ▼ ┌──────────────┐ │ 公钥加密操作 │ C = P^e mod n │ (RSA) │ └──────┬───────┘ │ ▼ 密文 C ─────────────(网络传输)─────────────────► 密文 C │ ▼ ┌──────────────┐ │ 私钥解密操作 │ │ P = C^d mod n│ └──────┬───────┘ │ ▼ 明文 P ✅ (仅私钥持有者可解密)

2.4 代表性算法对比

2.5 优势与局限

优势：

• 彻底解决密钥分发问题，公钥可透明公开

• 为数字签名和身份认证提供基础架构

• 支持密钥协商协议（如ECDH）

局限：

• 运算速度远低于对称加密（RSA-2048比AES约慢3个数量级）

• 单次可加密的数据长度受密钥长度限制（RSA-2048最多加密约245字节）

• 面临量子计算威胁（Shor算法可破解RSA和ECC）

非对称加密并非要取代对称加密，而是在两者之间实现分工：非对称加密负责安全传递"对称密钥"，对称加密负责高速传输"实际数据"。

第三章 数字签名：完整性保障与不可否认机制

3.1 设计目标

数字签名旨在解决以下安全问题：

• 完整性（Integrity）：确保消息在传输过程中未被篡改

• 不可否认性（Non-repudiation）：确保发送方无法否认曾发送该消息

3.2 与加密的本质区别

数字签名与加密操作方向相反：

3.3 技术实现路径

非对称加密算法无法高效处理任意长度的消息，因此实际签名流程采用"先哈希，后签名"的方案：

签名生成流程（发送方）：

1. 对原文 M 应用密码学哈希函数（如SHA-256），生成固定长度的摘要 H

2. 使用发送方的私钥对摘要 H 进行非对称加密，得到数字签名 Sig

3. 将原文 M 与签名 Sig 一并发送

签名验证流程（接收方）：

1. 对收到的原文 M' 进行同样的哈希运算，得到摘要 H1

2. 使用发送方的公钥解密签名 Sig，得到摘要 H2

3. 比较 H1 与 H2 是否一致

若一致，则同时证明：① 消息未被篡改（哈希匹配）；② 消息确由私钥持有者发送（公钥验证通过）。

text

【发送方 (持有私钥)】 【接收方 (持有发送方公钥)】 原文 M (任意长度) 原文 M' (收到的) │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ SHA-256哈希 │ │ SHA-256哈希 │ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ 摘要 H (256位) 摘要 H1 (256位) │ │ ▼ │ ┌─────────────┐ ┌──────────┐ │ │ 私钥加密 H │ ──► │ 签名 Sig │ │ │ (RSA) │ │ │ │ └─────────────┘ └────┬─────┘ │ │ │ (发送 M + Sig) │ │ │ └──────────┬────────────────┘ ▼ ┌─────────────┐ │ 公钥解密 Sig │ │ 得到摘要 H2 │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ H1 == H2 ? │ └──────┬──────┘ │ ┌───────┴───────┐ │ │ ✅ 有效 ❌ 无效 (完整且来源可信) (被篡改或伪造)

3.4 常用算法组合

第四章 数字证书：公钥信任体系的基石

4.1 设计目标

非对称加密和数字签名的安全性均建立在"公钥可信"这一前提之上。然而，公钥本身是纯粹的数字对象，不携带身份信息。攻击者可以伪造公钥并发起中间人攻击（Man-in-the-Middle Attack）。

数字证书旨在解决此问题：将公钥与持有者身份进行密码学绑定，建立可信的认证链路。

4.2 X.509 证书结构

数字证书遵循 X.509 v3 国际标准，其核心字段结构如下：

4.3 证书信任链（Chain of Trust）

证书的安全性通过层级信任链实现。浏览器/操作系统内置一组根CA证书（Root CA）作为绝对信任锚点，根CA签发中间CA，中间CA再签发最终实体证书。

text

┌─────────────────────────────────────────────────────────┐ │ 根CA证书 (Root CA) │ │ - 内置于操作系统/浏览器，构成信任锚点 │ │ - 自签名证书（Self-signed），不依赖上级 │ │ - 私钥严格物理隔离，极少联机使用 │ └────────────────────────┬────────────────────────────────┘ │ 根CA私钥签发 ▼ ┌─────────────────────────────────────────────────────────┐ │ 中间CA证书 (Intermediate CA) │ │ - 根CA不直接签发终端证书，引入中间层隔离风险 │ │ - 若中间CA失密，可单独吊销，根CA不受影响 │ │ - 可形成多级中间CA结构 │ └────────────────────────┬────────────────────────────────┘ │ 中间CA私钥签发 ▼ ┌─────────────────────────────────────────────────────────┐ │ 服务器实体证书 (End-entity Certificate) │ │ - 包含主体域名(example.com)和对应的公钥 │ │ - 包含CA的数字签名，验证通过则公钥可信 │ │ - 实际用于TLS服务端认证 │ └─────────────────────────────────────────────────────────┘

4.4 证书验证流程

当客户端（浏览器）接收到服务器证书时，执行以下验证逻辑：

1. 检查证书有效期是否在有效范围内

2. 检查证书是否已被吊销（通过CRL或OCSP查询）

3. 读取证书的"颁发者"字段，定位上级CA证书

4. 使用上级CA证书中的公钥验证当前证书的签名

5. 递归验证上级证书，直至达到内置的根CA证书

6. 确认证书的Subject与所访问的域名匹配（SAN检查）

全部通过后，该证书绑定的公钥被视为可信。

第五章 四组件协作机制：以TLS 1.3为例

TLS（Transport Layer Security）协议是四组件协同工作的典型实例。以下以TLS 1.3简化握手过程说明各模块职责：

text

客户端 (浏览器) 服务器 (网站) │ │ │ ① Client Hello (支持的密码套件、随机数) │ │ ────────────────────────────────────────────────► │ │ │ │ ② Server Hello + **数字证书** │ │ (证书内含服务器公钥 + CA数字签名) │ │ ◄──────────────────────────────────────────────── │ │ │ │ ③ 验证证书链： │ │ - 用内置CA公钥逐级验证签名 │ │ - 确认服务器公钥与域名匹配 │ │ 【数字证书模块完成】 │ │ │ │ ④ 生成临时对称会话密钥 K │ │ │ │ ⑤ 使用证书中的**服务器公钥**加密 K │ │ 【非对称加密模块完成】 │ │ ────────────────────────────────────────────────► │ │ │ │ ⑥ 使用**服务器私钥** │ 解密获取K │ │ 【非对称加密模块】│ │ │ │ ⑦ 后续应用数据全部使用 K 进行**对称加密**传输 │ │ 【对称加密模块完成】 │ │ ◄════════════════════════════════════════════════► │ │ │ │ ⑧ 服务器发送关键扩展消息时附加**数字签名** │ │ 客户端用服务器公钥验签，防止篡改 │ │ 【数字签名模块完成】 │ └──────────────────────────────────────────────────┘

各组件在TLS体系中的功能定位

第六章 综合对比

结语

对称加密、非对称加密、数字签名与数字证书四者并非互相替代，而是构成了密码学应用中的分层协作体系。对称加密承担数据加密的重任以保证效率，非对称加密解决密钥分发难题并搭建信任基础，数字签名提供数据来源的确定性，数字证书则为这一切注入"信任"这一关键要素。正是这四者的精密配合，才使得当前互联网的大规模安全通信成为可能。