三、密码学基础：对称加密、非对称加密、哈希函数与数字签名
密码学是信息安全工程的基石，它解决的是数据在不可信信道上的机密性（Confidentiality）、完整性（Integrity）、真实性（Authenticity）与不可否认性（Non-repudiation）问题。本章将系统梳理对称加密（DES、AES）、非对称加密（RSA、ECC）、哈希函数（MD5、SHA系列）及数字签名原理，并结合实际工程场景分析其选型与误用风险。下图展示了现代密码体系的整体协作关系：
上图清晰地展示了三类密码学原语在真实系统中的地位：对称加密负责高效的数据保护，非对称加密负责安全的密钥协商与身份认证，哈希函数则为数据完整性提供指纹。数字签名则是非对称加密与哈希函数的协同应用。下面逐一深入剖析。
3.1 对称加密：DES与AES
3.1.1 核心原理
对称加密使用同一个密钥进行加密和解密。其安全性完全依赖于密钥的保密性。加密过程可表示为 C = E(K, M)，解密过程为 M = D(K, C)。由于算法公开，密钥管理成为唯一的安全瓶颈。
- DES（Data Encryption Standard）：分组长度为64位，密钥有效位56位（实际64位含8位奇偶校验）。采用Feistel网络结构，共16轮迭代。由于密钥空间仅
2^56，在1999年已被电子前沿基金会（EFF）在22小时内破解，目前仅用于兼容旧系统。 - 3DES（Triple DES）：对DES进行三次运算（加密-解密-加密），有效密钥长度112位或168位。虽然安全性提升，但软件运行效率低，正逐步被AES取代。
- AES（Advanced Encryption Standard）：分组长度128位，支持128/192/256位密钥。采用SPN（Substitution-Permutation Network）结构，轮数根据密钥长度分别为10/12/14轮。AES在硬件和软件上均有极高效率，是当前国际标准（FIPS 197）。
3.1.2 操作模式与工程选型
分组密码必须配合操作模式才能加密任意长度的数据。常见模式包括：
| 模式 | 特点 | 典型应用 | 注意事项 |
|---|---|---|---|
| ECB | 每个分组独立加密 | 不建议使用 | 相同明文产生相同密文，泄露数据模式 |
| CBC | 前一个密文块参与当前加密 | 文件加密、传统SSL | 需要随机IV，不能并行加密 |
| CTR | 计数器加密后与明文异或 | 磁盘加密、网络流加密 | 可并行，但计数器不能重复 |
| GCM | CTR模式 + Galois认证 | TLS 1.2/1.3、VPN | 同时提供机密性和完整性，推荐使用 |
3.1.3 实战场景：数据库字段加密
某金融系统需要对用户手机号进行加密存储。初始方案使用ECB模式，导致相同手机号产生相同密文，攻击者可通过频率分析推断用户行为。整改后采用AES-256-GCM，并为每条记录生成随机12字节IV（Nonce），同时将认证标签（16字节）一并存储。改造后，相同明文在不同记录中产生不同密文，且任何篡改行为都会被认证标签检测。
// 伪代码示例：AES-256-GCM加密
iv = random(12 bytes)
cipher, tag = AES_256_GCM_Encrypt(key=K, iv=iv, plaintext=phone, aad=user_id)
storage = iv || cipher || tag该方案在性能上仅增加约5%的开销，但安全性显著提升。关键教训：不要使用ECB模式，不要重复使用IV。
3.1.4 常见误区与复盘
- 误区一：认为DES仍然安全。实际上DES的56位密钥在专用硬件上可在数小时内暴力破解。
- 误区二：忽略IV的随机性。CBC模式中IV可预测会导致“BEAST攻击”。
- 误区三：将密钥硬编码在代码中。应使用硬件安全模块（HSM）或密钥管理服务（KMS）存储。
3.2 非对称加密：RSA与ECC
3.2.1 核心原理
非对称加密使用公钥（Public Key）和私钥（Private Key）组成的密钥对。公钥公开分发，私钥严格保密。其数学基础是单向陷门函数：正向计算容易，反向求解极其困难。
- RSA：基于大整数分解难题。密钥生成时选择两个大素数p和q，计算
n = p×q，公钥为(e, n)，私钥为(d, n)。安全性依赖于n的因子分解难度。推荐密钥长度至少2048位，长期安全建议3072位。 - ECC（椭圆曲线密码）：基于椭圆曲线离散对数问题（ECDLP）。在相同安全强度下，ECC密钥长度远短于RSA。例如，256位ECC提供与3072位RSA相当的安全性。常用曲线包括P-256、secp256r1、Curve25519（X25519）。
3.2.2 性能对比与选型
| 指标 | RSA-2048 | ECC P-256 | 说明 |
|---|---|---|---|
| 密钥长度 | 2048位 | 256位 | ECC更节省存储和带宽 |
| 加密速度 | 较慢（约1000次/秒） | 较快（约5000次/秒） | ECC在移动设备上优势明显 |
| 解密速度 | 较慢 | 较快 | RSA私钥操作涉及大数模幂 |
| 签名生成 | 较慢 | 较快 | ECC签名生成效率高 |
| 签名验证 | 较快 | 较快 | 两者验证速度接近 |
| 硬件支持 | 广泛 | 现代CPU/手机均支持 | 新系统优先ECC |
3.2.3 实战场景：TLS握手密钥交换
在TLS 1.3中，客户端与服务器使用ECDHE（椭圆曲线Diffie-Hellman Ephemeral）进行前向保密的密钥协商。服务器发送其EC公钥，客户端生成临时密钥对，双方通过ECDH计算共享密钥。整个过程不传输私钥，且每次会话使用临时密钥，即使服务器长期私钥泄露，历史会话也无法被解密（前向保密）。
// TLS 1.3 ECDHE流程
ClientHello: 支持的曲线列表 (如 x25519, secp256r1)
ServerHello: 选择曲线 + 服务器临时公钥
Client: 生成临时密钥对，计算共享密钥
双方: HKDF派生会话密钥该方案有效抵御了被动窃听和重放攻击。关键点：临时密钥必须每次会话重新生成，否则失去前向保密性。
3.2.4 常见误区与风险
- 误区一：RSA密钥越长越安全。超过4096位后，安全性提升有限，但性能显著下降。
- 误区二：直接使用RSA加密大数据。RSA加密长度受限于密钥长度（如2048位只能加密245字节），应使用混合加密（RSA+AES）。
- 风险提示：ECC实现中若随机数生成器存在缺陷（如重复使用nonce），可能导致私钥泄露（如PS3签名漏洞）。
3.3 哈希函数：MD5、SHA系列
3.3.1 核心原理与安全属性
哈希函数将任意长度消息压缩为固定长度摘要，需满足三个核心属性：
- 抗原像性（单向性）：给定摘要y，无法找到消息x使得H(x)=y。
- 抗第二原像性：给定消息x，无法找到x'≠x使得H(x')=H(x)。
- 抗碰撞性：无法找到任意两个不同消息x和x'使得H(x)=H(x')。
此外，雪崩效应要求输入改变1位，输出约一半位发生变化。
3.3.2 算法演进与安全性现状
| 算法 | 摘要长度 | 安全性状态 | 推荐用途 |
|---|---|---|---|
| MD5 | 128位 | 已破解（碰撞攻击可行） | 仅用于非安全校验（如文件分块校验） |
| SHA-1 | 160位 | 已破解（SHAttered攻击，2017） | 禁止用于数字签名和证书 |
| SHA-256 | 256位 | 安全 | 数字签名、区块链、完整性校验 |
| SHA-3 | 224/256/384/512位 | 安全（Keccak算法） | 新系统可选用，抗量子计算更强 |
3.3.3 实战场景：软件完整性校验
某软件分发平台需要确保用户下载的安装包未被篡改。初始方案仅提供MD5校验值，攻击者可以构造恶意文件与合法文件具有相同MD5值。整改后采用SHA-256，并通过HTTPS页面展示摘要，同时使用代码签名证书对摘要进行数字签名。用户下载后计算SHA-256并与官方公布值比对，任何字节的修改都会导致摘要完全不同。
# Linux下计算SHA-256
$ sha256sum software.iso
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 software.iso该方案将篡改检测能力从“可能被绕过”提升到“计算上不可行”。关键经验：哈希函数只能检测意外损坏，不能防止恶意篡改，必须配合数字签名。
3.3.4 常见误区
- 误区一：使用MD5存储用户密码。应使用bcrypt、scrypt或Argon2等专用密码哈希算法（加盐+慢哈希）。
- 误区二：认为哈希加密可以替代加密。哈希是单向的，无法解密，适用于完整性校验而非机密性保护。
- 误区三：忽略长度扩展攻击。对于SHA-256，使用
H(secret || message)构造MAC不安全，应使用HMAC-SHA256。
3.4 数字签名原理与应用
3.4.1 核心原理
数字签名结合了哈希函数和非对称加密，提供真实性、完整性和不可否认性。签名过程：发送方对消息哈希后，用私钥加密摘要生成签名；验证过程：接收方用公钥解密签名得到摘要，再对消息计算哈希并比对。若一致则签名有效。
- 签名生成：
σ = Sign(SK, H(M)) - 签名验证：
Verify(PK, M, σ) → True/False
RSA签名（PKCS#1 v1.5或PSS）和ECDSA是两种主流方案。Ed25519（基于Curve25519）是更现代的替代，具有抗侧信道攻击和确定性签名（无随机数依赖）的优势。
3.4.2 工程实现流程
| 步骤 | 操作 | 使用密钥 | 输出 |
|---|---|---|---|
| 1. 哈希 | 对原文计算SHA-256摘要 | 无 | 32字节摘要 |
| 2. 签名 | 用私钥对摘要进行加密运算 | 发送方私钥 | 签名值σ |
| 3. 传输 | 发送原文 + 签名 | 无 | 数据包 |
| 4. 验证 | 用公钥解密签名得到摘要1，计算原文哈希摘要2，比对 | 发送方公钥 | 验证结果 |
3.4.3 实战案例：软件更新签名机制
背景：某智能设备厂商的OTA（Over-The-Air）升级包被中间人攻击者替换为恶意固件，导致设备被植入后门。
初始现象：设备仅通过HTTP下载升级包，未做任何完整性校验。攻击者通过DNS劫持将固件替换为恶意版本。
分析过程：安全团队审计发现，升级流程缺少三个关键环节：①传输未加密；②无完整性校验；③无来源认证。
整改方案：
- 升级包使用AES-256-GCM加密，密钥由设备内置的预置密钥派生。
- 对升级包计算SHA-256摘要，并使用厂商私钥进行Ed25519签名。
- 设备端内置厂商公钥，升级前验证签名，签名无效则拒绝安装。
结果对比：整改后，即使攻击者截获升级包，也无法伪造有效签名。设备拒绝安装任何未授权固件。攻击面从“完全开放”缩小为“需要破解签名算法”（计算上不可行）。
风险与代价：私钥管理成为新的关键点。若厂商私钥泄露，攻击者可签名恶意固件。因此私钥必须存储在HSM中，并实施严格的访问控制。
复盘经验：数字签名是软件供应链安全的最后一道防线。任何自动更新机制都必须包含签名验证，且公钥应通过安全渠道预置（如出厂烧录），而非通过网络获取。
3.4.4 常见误区与总结
- 误区一：使用RSA-PKCS#1 v1.5签名时未使用随机填充，导致Bleichenbacher攻击。应使用PSS填充。
- 误区二：验证签名时未检查证书链。仅验证签名算法正确但未确认公钥归属，仍可能被中间人攻击。
- 误区三：签名和加密使用同一密钥对。应分离用途，降低密钥泄露影响范围。