文章目录
-
- [1. 对称加密与非对称加密](#1. 对称加密与非对称加密)
-
- [1.1 对称加密（Symmetric Encryption）](#1.1 对称加密（Symmetric Encryption）)
- [1.2 非对称加密（Asymmetric Encryption）](#1.2 非对称加密（Asymmetric Encryption）)
- [1.3 混合加密系统](#1.3 混合加密系统)
- [2. 公钥密码学基础](#2. 公钥密码学基础)
-
- [2.1 密钥对生成](#2.1 密钥对生成)
- [2.2 公钥与私钥的数学关系](#2.2 公钥与私钥的数学关系)
- [2.3 密钥长度与安全强度](#2.3 密钥长度与安全强度)
- [3. 哈希函数与数字摘要](#3. 哈希函数与数字摘要)
-
- [3.1 哈希函数定义](#3.1 哈希函数定义)
- [3.2 常见哈希算法对比](#3.2 常见哈希算法对比)
- [3.3 哈希在数字签名中的作用](#3.3 哈希在数字签名中的作用)
- [4. 数字签名机制](#4. 数字签名机制)
-
- [4.1 数字签名的三大安全目标](#4.1 数字签名的三大安全目标)
- [4.2 签名与验签流程](#4.2 签名与验签流程)
- [4.3 RSA 签名详解](#4.3 RSA 签名详解)
- [4.4 ECDSA（椭圆曲线数字签名算法）](#4.4 ECDSA（椭圆曲线数字签名算法）)
- [5. 安全电子邮件完整流程](#5. 安全电子邮件完整流程)
-
- [5.1 场景需求](#5.1 场景需求)
- [5.2 混合加密方案详解](#5.2 混合加密方案详解)
- [5.3 流程图](#5.3 流程图)
- [5.4 为什么使用三层加密？](#5.4 为什么使用三层加密？)
- [5.5 为什么先签名再加密？](#5.5 为什么先签名再加密？)
- [6. 公钥分发与信任体系](#6. 公钥分发与信任体系)
-
- [6.1 问题：Alice 如何获得 Bob 的公钥？](#6.1 问题：Alice 如何获得 Bob 的公钥？)
- [6.2 解决方案一：公钥基础设施（PKI）](#6.2 解决方案一：公钥基础设施（PKI）)
- [6.3 解决方案二：公钥服务器（PGP 模式）](#6.3 解决方案二：公钥服务器（PGP 模式）)
- [6.4 解决方案三：信任网（Web of Trust）](#6.4 解决方案三：信任网（Web of Trust）)
- [6.5 解决方案四：TOFU（Trust On First Use）](#6.5 解决方案四：TOFU（Trust On First Use）)
- [6.6 各方案对比](#6.6 各方案对比)
- [7. 常见攻击与防护措施](#7. 常见攻击与防护措施)
-
- [7.1 中间人攻击（MITM）](#7.1 中间人攻击（MITM）)
- [7.2 重放攻击（Replay Attack）](#7.2 重放攻击（Replay Attack）)
- [7.3 选择性密文攻击（CCA）](#7.3 选择性密文攻击（CCA）)
- [7.4 侧信道攻击（Side-Channel Attack）](#7.4 侧信道攻击（Side-Channel Attack）)
- [7.5 私钥泄露风险](#7.5 私钥泄露风险)
- [7.6 哈希碰撞攻击](#7.6 哈希碰撞攻击)
- [7.7 前向保密（Forward Secrecy）](#7.7 前向保密（Forward Secrecy）)
- [8. 实际应用场景](#8. 实际应用场景)
-
- [8.1 HTTPS/TLS](#8.1 HTTPS/TLS)
- [8.2 代码签名](#8.2 代码签名)
- [8.3 区块链交易](#8.3 区块链交易)
- [8.4 SSH 认证](#8.4 SSH 认证)
- [8.5 电子邮件加密（PGP/S/MIME）](#8.5 电子邮件加密（PGP/S/MIME）)
- [8.6 数字证书应用](#8.6 数字证书应用)
- [8.7 物联网（IoT）安全](#8.7 物联网（IoT）安全)
- [9. 最佳实践总结](#9. 最佳实践总结)
-
- [9.1 算法选择](#9.1 算法选择)
- [9.2 实现注意事项](#9.2 实现注意事项)
- 结语
1. 对称加密与非对称加密
1.1 对称加密（Symmetric Encryption）
定义 ：加密和解密使用同一把密钥的加密方式。
核心公式：
- 加密：C = E(K, P)
- 解密：P = D(K, C)
其中：P 为明文，C 为密文，K 为密钥，E 为加密函数，D 为解密函数。
常见算法：
| 算法 | 密钥长度 | 特点 | 适用场景 |
|---|---|---|---|
| AES | 128/192/256 bit | 快速、安全、标准化 | 文件加密、网络通信 |
| DES | 56 bit | 已过时，不安全 | 历史系统兼容 |
| 3DES | 168 bit | DES 的改进，较慢 | 金融系统遗留 |
| ChaCha20 | 256 bit | 软件实现快 | 移动设备、TLS |
优点：
- 加解密速度快（比非对称加密快 1000 倍以上）
- 适合加密大量数据
- 算法简单，硬件实现容易
缺点：
- 密钥分发困难：如何安全地把密钥传给对方？
- 密钥管理复杂：n 个人互相通信需要 n(n-1)/2 个密钥
- 无法实现身份认证：双方都有相同密钥，无法证明是谁发的
1.2 非对称加密（Asymmetric Encryption）
定义 ：使用一对密钥（公钥和私钥），公钥加密的数据只能用私钥解密，反之亦然。
核心公式：
- 密钥对生成：(PK, SK) = KeyGen()
- 加密：C = E(PK, P)
- 解密：P = D(SK, C)
数学基础 ：非对称加密基于单向陷门函数（One-way Trapdoor Function）：
- 正向计算容易
- 反向计算困难（除非有陷门信息，即私钥）
常见数学难题：
- 大整数分解问题（RSA）：给定 n = p × q，求 p 和 q
- 离散对数问题（Diffie-Hellman、ElGamal）：给定 g^x mod p，求 x
- 椭圆曲线离散对数（ECC）：给定 k×G，求 k
常见算法对比：
| 算法 | 安全强度 | 密钥长度 | 速度（签名/验证） | 主要用途 |
|---|---|---|---|---|
| RSA-2048 | 112 bit | 2048 bit | 慢/慢 | 通用加密、签名 |
| RSA-3072 | 128 bit | 3072 bit | 更慢/更慢 | 长期安全需求 |
| ECC-256 | 128 bit | 256 bit | 较快/慢 | 移动设备、IoT |
| ECC-384 | 192 bit | 384 bit | 中等/较慢 | 高安全需求 |
注意：ECC 签名生成速度较快，但签名验证速度通常慢于 RSA（因为需要更多的椭圆曲线点乘运算）。
优点：
- 解决密钥分发问题（公钥可以公开）
- 密钥管理简单（每人只需一对密钥）
- 可实现数字签名和身份认证
缺点：
- 计算速度慢（比对称加密慢 1000-10000 倍）
- 不适合加密大量数据
- 密钥长度较长
1.3 混合加密系统
核心思想：结合对称加密和非对称加密的优点。
发送方操作流程：
- 生成随机对称密钥 Ks（会话密钥）
- 用 Ks 加密消息 m → E(Ks, m)
- 用接收方公钥 PK_B 加密 Ks → E(PK_B, Ks)
- 发送 [E(PK_B, Ks), E(Ks, m)]
接收方操作流程：
- 用私钥 SK_B 解密得到 Ks → D(SK_B, E(PK_B, Ks))
- 用 Ks 解密消息 → D(Ks, E(Ks, m))
为什么需要混合加密？
- 对称加密：速度快，适合加密数据
- 非对称加密：解决密钥分发，适合加密短数据（如密钥）
实际应用：TLS/SSL、PGP、S/MIME 都采用混合加密。
2. 公钥密码学基础
2.1 密钥对生成
RSA 密钥生成关键参数：
- public_exponent：通常选择 65537 (0x10001)，是费马素数，计算效率高
- key_size ：3072 bit 是当前推荐标准，2048 bit 仅用于兼容旧系统
安全建议：根据 NIST SP 800-57 指南，新系统应使用 RSA 3072+ 或 ECC 256+。
2.2 公钥与私钥的数学关系
以 RSA 为例，密钥生成过程：
- 选择两个大素数 p 和 q
- 计算 n = p × q（模数）
- 计算 φ(n) = (p-1)(q-1)（欧拉函数）
- 选择 e（公钥指数），满足 1 < e < φ(n) 且 gcd(e, φ(n)) = 1
- 计算 d（私钥指数），满足 d × e ≡ 1 (mod φ(n))
公钥 ：PK = (e, n)
私钥：SK = (d, n)
加密 ：C = M^e mod n
解密：M = C^d mod n
核心性质：
- 从公钥 (e, n) 推导私钥 d，需要分解 n 为 p 和 q
- 当 n 足够大（2048 bit 以上），分解在计算上不可行
2.3 密钥长度与安全强度
| 对称密钥长度 | RSA 密钥长度 | ECC 密钥长度 | 安全强度 | 预计安全年限 | 推荐使用场景 |
|---|---|---|---|---|---|
| 80 bit | 1024 bit | 160 bit | 80 bit | 已不安全 | 禁止使用 |
| 112 bit | 2048 bit | 224 bit | 112 bit | 2030 年前 | 仅用于兼容旧系统 |
| 128 bit | 3072 bit | 256 bit | 128 bit | 2040 年前 | 新系统推荐标准 |
| 192 bit | 7680 bit | 384 bit | 192 bit | 长期安全 | 高安全需求 |
| 256 bit | 15360 bit | 512 bit | 256 bit | 长期安全 | 极高安全需求 |
建议：
- 新系统：RSA 3072+ 或 ECC 256+
- 存量系统：RSA 2048 应尽快升级到 3072+
- 长期安全需求：考虑 RSA 4096 或 ECC 384+
3. 哈希函数与数字摘要
3.1 哈希函数定义
哈希函数 H(x) 将任意长度输入映射为固定长度输出（摘要/指纹）。
数学表示：H: {0,1}* → {0,1}^n
核心特性：
- 确定性：相同输入 → 相同输出
- 快速计算：给定 x，快速计算 H(x)
- 单向性：给定 h，难以找到 x 使得 H(x) = h
- 抗碰撞：难以找到 x₁ ≠ x₂ 使得 H(x₁) = H(x₂)
- 雪崩效应：输入微小变化 → 输出巨大变化
3.2 常见哈希算法对比
| 算法 | 输出长度 | 安全性 | 速度（软件/硬件） | 状态 |
|---|---|---|---|---|
| MD5 | 128 bit | 已破解 | 快/快 | ❌ 禁止使用 |
| SHA-1 | 160 bit | 已破解 | 中等/快 | ❌ 禁止使用 |
| SHA-256 | 256 bit | 安全 | 中等/极快 | ✅ 推荐使用 |
| SHA-384 | 384 bit | 安全 | 较慢/快 | ✅ 高安全需求 |
| SHA-512 | 512 bit | 安全 | 较慢/快 | ✅ 高安全需求 |
| SHA-3 | 可变 | 安全 | 中等/中等 | ✅ 新一代标准 |
| BLAKE2 | 可变 | 安全 | 快/快 | ✅ 性能优先 |
重要说明：
- SHA-256 在现代 CPU 上有专用指令集（如 Intel SHA Extensions），硬件实现极快
- SHA-512 在 64 位系统上通常比 SHA-256 更快（因为每次处理更多数据）
- 速度依赖于实现方式（纯软件 vs 硬件加速）
3.3 哈希在数字签名中的作用
为什么需要先哈希再签名？
- 效率：非对称加密慢，哈希值固定长度（如 256 bit），签名速度快
- 安全性：直接签名长消息可能存在安全隐患
- 兼容性：签名算法通常设计为处理固定长度输入
正确做法：
- 先计算摘要：摘要 = Hash(长消息)
- 再签名：签名 = Sign(私钥，摘要)
4. 数字签名机制
4.1 数字签名的三大安全目标
-
认证性（Authentication）
- 验证消息确实来自声称的发送者
- 只有私钥持有者能生成有效签名
-
完整性（Integrity）
- 验证消息在传输中未被篡改
- 任何改动都会导致签名验证失败
-
不可否认性（Non-repudiation）
- 发送者事后不能否认自己发送过该消息
- 因为只有他有私钥
4.2 签名与验签流程
发送方（签名）：
- 输入：消息 m，私钥 SK_A
- 步骤：
- 计算摘要 h = H(m)
- 生成签名 σ = Sign(SK_A, h)
- 发送 (m, σ)
接收方（验证）：
- 输入：消息 m，签名 σ，公钥 PK_A
- 步骤：
- 计算摘要 h' = H(m)
- 验证 Verify(PK_A, σ, h')
- 返回 True/False
4.3 RSA 签名详解
RSA 签名原理：
- 签名生成：σ = Sign(SK, h) # 使用私钥和签名算法
- 签名验证：Verify(PK, σ, h) # 使用公钥和验证算法
重要说明 ：虽然教学中常说"用私钥加密摘要"，但这种说法不严谨：
- 加密 的目的是机密性，防止未授权方读取数据
- 签名 的目的是认证性和完整性，验证数据来源和未被篡改
- RSA 签名不是简单的"反向加密"，而是使用专门的签名算法和填充方案
重要：必须使用填充方案！
直接使用"教科书 RSA"存在严重安全隐患：
- 存在选择性伪造攻击
- 存在同态攻击（签名可被组合）
安全填充方案：
-
PKCS#1 v1.5（传统方案）
- 填充格式：0x00 0x01 [FF...FF] 0x00 [ASN.1 头] [哈希值]
- 已被广泛实现
- 存在 Bleichenbacher 攻击风险
- 仅用于兼容旧系统
-
PSS（Probabilistic Signature Scheme）（推荐）
- 随机化签名（相同消息每次签名不同）
- 可证明安全性
- 推荐使用
4.4 ECDSA（椭圆曲线数字签名算法）
优势：
- 密钥短（256 bit ECC ≈ 3072 bit RSA）
- 签名生成速度快
- 适合资源受限环境
签名过程（简化）：
- 输入：消息摘要 h，私钥 d
- 步骤：
- 选择随机数 k
- 计算 (x, y) = k × G（G 为基点）
- r = x mod n
- s = k^(-1) × (h + r×d) mod n
- 签名 = (r, s)
注意：k 必须随机且保密，否则私钥会泄露！
历史案例：Sony PS3 签名漏洞就是因为 k 固定
5. 安全电子邮件完整流程
5.1 场景需求
Alice 要给 Bob 发送一封安全邮件，需要满足：
- 机密性：只有 Bob 能阅读邮件内容
- 认证性：Bob 能确认邮件确实来自 Alice
- 完整性：邮件在传输中未被篡改
5.2 混合加密方案详解
符号说明：
- m：原始邮件内容
- H(·)：哈希函数（如 SHA-256）
- K_A^-：Alice 的私钥
- K_A^+：Alice 的公钥
- K_B^+：Bob 的公钥
- K_B^-：Bob 的私钥
- K_S：临时生成的对称密钥（会话密钥）
发送方（Alice）操作：
步骤 1：生成数字签名
- 1.1 计算摘要：h = H(m)
- 1.2 签名：sig = Sign(K_A^-, h)
步骤 2：生成并加密会话密钥
- 2.1 生成随机会话密钥 K_S
- 2.2 用 Bob 的公钥加密：encrypted_Ks = Encrypt_RSA(K_B^+, K_S)
步骤 3：对称加密（保护内容和签名）
- 3.1 拼接：data = m || sig
- 3.2 加密：ciphertext = Encrypt_AES(K_S, data)
步骤 4：发送
- 4.1 发送包：[encrypted_Ks, ciphertext]
接收方（Bob）操作：
步骤 1：解密会话密钥
- 1.1 K_S = Decrypt_RSA(K_B^-, encrypted_Ks)
步骤 2：解密邮件内容
- 2.1 data = Decrypt_AES(K_S, ciphertext)
- 2.2 分离：m || sig = data
步骤 3：验证签名
- 3.1 计算摘要：h' = H(m)
- 3.2 验证：Verify(K_A^+, sig, h')
- 3.3 如果验证通过，则邮件可信
5.3 流程图
┌─────────────────────────────────────────────────────────────┐
│ Alice │
│ │
│ 邮件 m ──┬──→ H(·) ──→ h ──┬──→ K_A^-(·) ──→ sig │
│ │ │ │
│ │ ↓ │
│ │ m || sig │
│ │ │ │
│ │ ↓ │
│ └────────→ AES 加密 (K_S) ──→ ciphertext │
│ │
│ 生成 K_S ──→ RSA 加密 (K_B^+) ──→ encrypted_Ks │
│ │
│ 发送：[encrypted_Ks, ciphertext] ──────────────→ Internet │
└─────────────────────────────────────────────────────────────┘
│
↓
┌─────────────────────────────────────────────────────────────┐
│ Bob │
│ │
│ 接收：[encrypted_Ks, ciphertext] │
│ │ │ │
│ ↓ ↓ │
│ RSA 解密 (K_B^-) AES 解密 (K_S) │
│ │ │ │
│ ↓ ↓ │
│ K_S m || sig │
│ │ │
│ ↓ │
│ 分离 m 和 sig │
│ │ │
│ m ──→ H(·) ──→ h' ←── K_A^+(sig) │
│ │
│ 比较 h' == h ? │
│ ✓ 验证通过 │
└─────────────────────────────────────────────────────────────┘5.4 为什么使用三层加密？
第一层：数字签名（K_A^-）
- 目的：认证 + 完整性
- 为什么用私钥：只有 Alice 能生成，所有人都能验证
第二层：对称加密（K_S）
- 目的：机密性 + 效率
- 为什么用对称加密：速度快，适合加密大量数据
第三层：非对称加密（K_B^+）
- 目的：安全传输会话密钥
- 为什么加密 K_S：确保只有 Bob 能拿到解密钥匙
5.5 为什么先签名再加密？
方案对比：
-
先签名再加密（推荐）
- 发送：Encrypt(m, Sign(m))
- 签名也被加密，保护发送者身份
- 接收者解密后才能验证，隐私性好
- 标准做法（如 S/MIME、PGP）
-
先加密再签名
- 发送：Sign(Encrypt(m))
- 签名未加密，任何人都能看到是谁发送的
- 可能对加密数据签名存在安全隐患
- 仅用于特殊场景（如需要第三方审计）
6. 公钥分发与信任体系
6.1 问题：Alice 如何获得 Bob 的公钥？
这是公钥密码学的核心难题 。如果公钥分发不安全，攻击者可以实施中间人攻击（Man-in-the-Middle Attack）。
中间人攻击示例：
正常流程：
- Alice ←───── K_B^+ ───── Bob
- Alice 用 K_B^+ 加密，Bob 解密阅读
中间人攻击：
- Alice ←───── K_M^+ ───── Bob
- Mallory 在中间截获，用 K_M^+ 加密
- Mallory 解密后读取/篡改，再用 K_B^+ 重新加密
- Bob 解密（ unaware）
结果：
- Alice 以为在和 Bob 通信
- Bob 以为在和 Alice 通信
- 实际上所有消息都经过 Mallory
6.2 解决方案一：公钥基础设施（PKI）
核心思想：引入可信第三方（CA，Certificate Authority）为公钥背书。
数字证书结构（X.509 v3）：
- 版本号：v3
- 序列号：唯一标识
- 签名算法：SHA256WithRSA
- 颁发者：CN=DigiCert Global Root CA
- 有效期：生效时间 - 过期时间
- 主体：CN=bob@example.com（证书持有者）
- 主体公钥信息：算法 + 公钥
- 扩展项：密钥用途、主题备用名称
- 签名值：CA 的私钥对以上内容的签名
证书链验证：
- 信任链：根 CA（自签名）→ 中间 CA → Bob 的证书 → Bob 的公钥
- 验证过程：
- 操作系统/浏览器内置根 CA 公钥
- 用根 CA 公钥验证中间 CA 证书
- 用中间 CA 公钥验证 Bob 的证书
- 信任 Bob 的公钥
6.3 解决方案二：公钥服务器（PGP 模式）
机制：
- 用户将公钥上传到公共服务器（如 keyserver.ubuntu.com）
- 其他人通过邮箱或密钥 ID 搜索下载
问题：
- 服务器不验证身份，任何人都可以上传声称是 Bob 的公钥
- 需要指纹验证
指纹验证流程：
- Alice 从服务器下载 Bob 的公钥
- Alice 计算公钥指纹（如：ABCD 1234 EF56 7890 ...）
- Alice 通过可信渠道（电话、见面、已加密聊天）联系 Bob
- Bob 告知自己的公钥指纹
- Alice 比对两个指纹
- 一致：信任该公钥
- 不一致：拒绝使用
6.4 解决方案三：信任网（Web of Trust）
PGP 的理念：
- 不依赖中心化 CA
- 用户互相签名认证公钥
机制：
- Alice 信任 Charlie
- Charlie 签名认证了 Bob 的公钥
- → Alice 可以选择信任 Bob 的公钥
信任级别：
- 完全信任（ultimate）：自己的密钥
- 完全信任（full）：完全信任该人的签名
- 边际信任（marginal）：部分信任
- 不信任（none）：不信任
现状：
- 管理复杂，用户友好性差
- 现代实践中逐渐被 PKI 取代
- 仍在 PGP/GPG 社区使用
6.5 解决方案四：TOFU（Trust On First Use）
机制：
- 第一次使用公钥时自动信任
- 后续如果公钥变化则警告
应用：
- SSH 首次连接
- 存储在
~/.ssh/known_hosts
风险：
- 第一次连接就可能被中间人攻击
- 适合风险可控场景
6.6 各方案对比
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| PKI/CA | 自动化、用户友好 | 依赖 CA、单点故障 | Web、S/MIME |
| 公钥服务器 + 指纹 | 去中心化 | 需手动验证 | PGP/GPG |
| 信任网 | 社区自治 | 复杂、难用 | 小众社区 |
| TOFU | 简单 | 首次连接风险 | SSH、内部系统 |
| 直接交换 | 最安全 | 不可扩展 | 高安全需求 |
7. 常见攻击与防护措施
7.1 中间人攻击（MITM）
攻击原理：攻击者拦截通信，替换公钥，冒充通信双方。
防护措施：
- 证书验证：严格验证证书链
- 证书钉扎（Certificate Pinning）：只信任特定证书或公钥
- 指纹验证：手动核对公钥指纹
- HPKP（HTTP Public Key Pinning）：已弃用，改用 Expect-CT
7.2 重放攻击（Replay Attack）
攻击原理：攻击者截获合法消息，稍后重复发送。
示例：
- Alice → Bob: "Transfer 1000 CNY" (加密 + 签名)
- 攻击者截获该消息
- 攻击者 → Bob: "Transfer 1000 CNY" (重复发送)
- Bob 执行转账（重复扣款）
防护措施：
-
时间戳：
- 消息包含时间戳和有效期
- 接收方检查时间戳是否在允许范围内
-
随机数（Nonce）：
- 消息包含随机生成的唯一值
- 接收方记录已使用的 nonce，拒绝重复
-
序列号：
- 消息包含递增序列号
- 接收方检查序列号是否递增
7.3 选择性密文攻击（CCA）
攻击原理：攻击者能够解密自己选择的密文，从而推断出其他密文的内容。
RSA 的弱点：
- 教科书 RSA 具有同态性：E(m1) × E(m2) = E(m1 × m2)
- 攻击者可以利用此特性
防护措施：
-
使用填充方案：
- 加密：OAEP（Optimal Asymmetric Encryption Padding）
- 签名：PSS（Probabilistic Signature Scheme）
-
避免直接使用 RSA 加密数据：
- 仅用于加密对称密钥
- 使用混合加密
7.4 侧信道攻击（Side-Channel Attack）
攻击原理：通过分析加密设备的物理特征（时间、功耗、电磁辐射）推断密钥。
类型：
- 时序攻击：测量解密时间差异
- 功耗分析：测量设备功耗变化
- 电磁分析：测量电磁辐射
防护措施：
- 恒定时间算法：避免分支依赖密钥
- 盲化（Blinding） ：
- RSA 解密盲化：
- 选择随机 r
- 计算 c' = c × r^e mod n
- 解密 m' = c'^d mod n
- 计算 m = m' × r^(-1) mod n
- RSA 解密盲化：
- 硬件防护：使用 HSM（硬件安全模块）
7.5 私钥泄露风险
常见原因：
- 硬编码在代码中
- 存储在无保护的文件中
- 弱密码保护
- 内存泄漏
- 备份不当
防护措施：
- 使用密钥管理系统（KMS）：AWS KMS、HashiCorp Vault、Azure Key Vault
- 硬件安全模块（HSM）：私钥永不离开 HSM，物理防护 + 逻辑防护
- 密钥轮换：定期更换密钥（如每 90 天）
- 访问控制：最小权限原则，审计日志
7.6 哈希碰撞攻击
攻击原理：找到两个不同消息 m1 和 m2，使得 H(m1) = H(m2)。
历史案例：
- MD5：2004 年被攻破，可实用碰撞
- SHA-1：2017 年 Google 宣布 SHAttered 攻击
防护措施：
- 使用安全哈希算法 ：
- SHA-256、SHA-384、SHA-512
- SHA-3
- MD5、SHA-1
7.7 前向保密（Forward Secrecy）
问题：如果长期私钥泄露，所有历史通信都能被解密。
解决方案 ：使用临时密钥（Ephemeral Key）进行密钥交换。
Diffie-Hellman 密钥交换：
- Alice：生成 a，计算 A = g^a mod p
- Bob：生成 b，计算 B = g^b mod p
- Alice → Bob: A
- Bob → Alice: B
- 共享密钥：
- Alice: K = B^a mod p = g^(ba) mod p
- Bob: K = A^b mod p = g^(ab) mod p
- 每次会话使用新的 a 和 b
- 即使长期私钥泄露，历史会话密钥仍安全
TLS 中的实现：
- DHE（Diffie-Hellman Ephemeral）
- ECDHE（Elliptic Curve DHE）
推荐配置：
- TLS 1.2+
- 密钥交换：ECDHE
- 加密：AES-256-GCM
- 哈希：SHA-384
8. 实际应用场景
8.1 HTTPS/TLS
握手流程（简化）：
- Client → Server: ClientHello（支持的加密套件）
- Server → Client: ServerHello（选择的加密套件）+ Certificate（服务器证书）+ ServerKeyExchange（DH 参数）
- Client → Server: ClientKeyExchange（客户端 DH 参数）+ ChangeCipherSpec + Finished（加密）
- Server → Client: ChangeCipherSpec + Finished（加密）
- 加密通信开始
关键点：
- 证书验证服务器身份
- ECDHE 提供前向保密
- 对称加密（AES）保护数据
8.2 代码签名
场景：软件开发者对发布包签名，用户验证完整性。
流程：
- 开发者签名：gpg --detach-sign --armor release-v1.2.tar.gz
- 用户验证：gpg --verify release-v1.2.tar.gz.asc release-v1.2.tar.gz
应用：
- Linux 发行版软件包
- Windows 驱动程序
- macOS 应用
- Git 提交签名
8.3 区块链交易
Bitcoin 交易签名：
- 交易输入：前一笔交易的输出引用 + 解锁脚本（签名 + 公钥）
- 交易输出：金额 + 锁定脚本（收款人公钥哈希）
- 验证：
- 节点获取公钥
- 验证签名
- 检查余额
- 确认交易
特点：
- 去中心化验证
- 不可篡改
- 公开可验证
8.4 SSH 认证
公钥认证：
- 生成密钥对：ssh-keygen -t ed25519 -C "user@example.com"
- 复制公钥到服务器：ssh-copy-id user@server
- 登录（无需密码）：ssh user@server
流程：
- Client → Server: 声明身份：user
- Server → Client: 随机挑战（nonce）
- Client → Server: 用私钥签名 nonce
- Server: 用公钥验证签名，验证通过 → 允许登录
8.5 电子邮件加密（PGP/S/MIME）
PGP 工作流：
- 生成密钥对：gpg --gen-key
- 导出公钥：gpg --armor --export user@example.com > public.key
- 导入他人公钥：gpg --import bob_public.key
- 签名并加密邮件：gpg --sign --encrypt --recipient bob@example.com message.txt
- 解密并验证：gpg --decrypt message.txt.gpg
S/MIME：
- 基于 X.509 证书
- 集成在邮件客户端（Outlook、Apple Mail）
- 依赖 CA 体系
8.6 数字证书应用
客户端证书认证：
- 传统认证：用户名 + 密码
- 证书认证：客户端证书 + 私钥
优势：
- 更强的身份验证
- 防钓鱼
- 可审计
应用：
- 企业内部系统
- 银行网银
- API 认证
8.7 物联网（IoT）安全
挑战：
- 资源受限（计算能力、存储）
- 大规模部署
- 物理安全风险
解决方案：
-
轻量级算法：
- ECC 而非 RSA（密钥短）
- ChaCha20-Poly1305（软件实现快）
-
设备证书：
- 出厂预置证书
- 设备唯一身份
-
安全启动：
- 固件签名验证
- 防止恶意固件
9. 最佳实践总结
9.1 算法选择
| 用途 | 推荐算法 | 参数 |
|---|---|---|
| 非对称加密 | RSA / ECC | RSA-3072+ / ECC-256+ |
| 对称加密 | AES-GCM / ChaCha20 | AES-256 |
| 哈希 | SHA-256 / SHA-3 | SHA-256 以上 |
| 签名 | ECDSA / EdDSA / RSA-PSS | P-256 / Ed25519 |
| 密钥交换 | ECDHE | P-256 / X25519 |
9.2 实现注意事项
-
不要自己实现密码算法
- 使用成熟库（OpenSSL、Libsodium、cryptography）
- 实现细节容易出错
-
使用安全的随机数生成器
- 使用密码学安全随机（如 Python 的 secrets 模块）
- 避免使用伪随机（如 random 模块）
-
及时更新依赖
- 关注安全漏洞公告
- 定期升级库版本
-
密钥管理
- 永远不要硬编码密钥
- 使用 KMS 或 HSM
- 定期轮换密钥
-
防御深度
- 多层防护
- 假设单层防护会被突破
结语
公钥密码学是现代信息安全的基石，理解其原理和实践对于从事 IT 行业至关重要。
核心要点回顾：
- 混合加密：对称加密保效率，非对称加密保安全
- 数字签名：私钥签名，公钥验签，实现认证和完整性
- 信任体系：公钥必须通过可信渠道获取（CA、指纹验证）
- 算法选择：使用现代安全算法，避免已破解的旧算法
- 实现细节：使用成熟库，关注侧信道攻击和实现漏洞
持续学习：密码学是快速发展的领域，量子计算、后量子密码学、零知识证明等新技术不断涌现。保持学习，关注最新研究和标准更新。
实践建议：
- 动手实现简单示例，理解原理
- 使用工具分析实际协议（如 Wireshark 抓包 TLS）
- 参与开源项目，学习最佳实践
- 关注安全漏洞公告，理解攻击原理
记住：**密码学是数学、计算机科学和工程学的交叉领域，理论安全和实现安全同样重要。