2. 密码学基础
安全通信协议的设计本质上是密码学原语在真实网络环境中的工程化组合。无论是TLS 1.3、SSH、IPsec还是自定义的专有协议，其安全性都建立在四类核心密码学构件之上：对称加密提供机密性，非对称加密解决密钥分发与身份认证，哈希函数保证数据完整性，消息认证码（MAC）则同时提供完整性与数据源认证。本章将深入剖析这四类原语的数学原理、工程特性及其在协议设计中的典型应用模式，为后续章节的协议构造打下坚实基础。
2.1 对称加密：机密性的基石
核心原理
对称加密算法中，加密和解密使用完全相同的密钥。其数学本质是一个可逆的变换对：设明文空间为 M，密文空间为 C，密钥空间为 K，加密函数 Ek: M → C 与解密函数 Dk: C → M 满足 Dk(Ek(m)) = m。现代对称加密主要分为分组密码（如AES）和流密码（如ChaCha20）两大类。AES采用代换-置换网络（SPN）结构，通过多轮的非线性替换（S-box）和线性混合（ShiftRows、MixColumns）实现充分的混淆与扩散；ChaCha20则基于ARX（加-旋转-异或）运算，在软件实现上具有更高的执行效率。
在实际协议设计中，对称加密通常以认证加密（AEAD）模式使用，如AES-256-GCM或ChaCha20-Poly1305。这些模式在加密的同时生成认证标签，将机密性与完整性保护合并为一步操作，既减少了协议消息轮次，又避免了“先加密后认证”组合中可能引入的padding oracle攻击。
工程选择与操作要点
| 算法 | 密钥长度 | 分组/流 | 典型场景 | 硬件加速 |
|---|---|---|---|---|
| AES-256-GCM | 256 bit | 分组(128 bit) | TLS 1.3、IPsec、磁盘加密 | AES-NI指令集 |
| ChaCha20-Poly1305 | 256 bit | 流 | 移动端、嵌入式、TLS 1.3备选 | 纯软件高效 |
| SM4-GCM | 128 bit | 分组(128 bit) | 国密合规场景 | 部分国产CPU支持 |
选择对称加密算法时，应优先考虑AEAD模式，避免单独使用CBC或CTR模式。若必须使用非AEAD模式，则必须搭配独立的MAC算法，并严格遵循“先加密后MAC”的构造顺序（Encrypt-then-MAC），以防止密文篡改攻击。
2.2 非对称加密：密钥分发与身份认证的桥梁
核心原理
非对称加密使用一对数学关联但不可互推的密钥：公钥（Public Key）和私钥（Private Key）。其数学基础包括大整数分解难题（RSA）、离散对数难题（DSA/ElGamal）以及椭圆曲线离散对数难题（ECC）。以RSA为例，选取两个大素数 p 和 q，计算 n = p×q，欧拉函数 φ(n) = (p-1)(q-1)，选择公钥指数 e 满足 gcd(e, φ(n)) = 1，私钥指数 d 满足 e×d ≡ 1 (mod φ(n))。加密为 c = me mod n，解密为 m = cd mod n。ECC则基于椭圆曲线点群上的标量乘法，在同等安全强度下密钥长度远小于RSA（256位ECC约等于3072位RSA）。
在安全通信协议中，非对称加密主要用于两个目的：密钥交换（如ECDHE）和数字签名（如ECDSA、EdDSA）。密钥交换协议（如Diffie-Hellman及其椭圆曲线变体）允许双方在不安全的信道上协商出共享密钥，其安全性基于计算Diffie-Hellman（CDH）假设。数字签名则提供不可否认性和身份认证，发送方用私钥签名，接收方用公钥验签。
协议设计中的操作流程
- 密钥生成：在安全环境中生成密钥对，私钥必须存储在硬件安全模块（HSM）或安全飞地中。
- 证书签发：将公钥与身份信息绑定，由CA签发X.509证书。
- 密钥交换：使用ECDHE等协议协商会话密钥，采用临时密钥对实现前向保密（PFS）。
- 身份验证：使用数字签名验证对端身份，防止中间人攻击。
2.3 哈希函数：数据完整性的指纹
核心原理
哈希函数将任意长度的输入映射为固定长度的输出（如SHA-256输出256位）。其核心安全属性包括：抗原像性（给定哈希值无法反推原文）、抗第二原像性（给定原文和哈希值，无法找到另一原文产生相同哈希）、抗碰撞性（无法找到任意两个不同输入产生相同哈希）。SHA-256基于Merkle-Damgård结构，将输入分块后通过压缩函数迭代处理；SHA-3则采用海绵结构（Sponge Construction），具有更强的安全冗余。
在协议设计中，哈希函数不仅用于完整性校验，还广泛用于：密钥派生（HKDF）、伪随机数生成、证书指纹计算、以及将非均匀随机输入（如DH共享密钥）转换为均匀分布的密钥材料。
案例拆解：TLS 1.3中的哈希应用
TLS 1.3协议中，哈希函数贯穿整个握手过程。以TLS_AES_256_GCM_SHA384套件为例，其密钥调度过程如下：
// 以HKDF-Extract为例
PRK = HMAC-SHA384(salt, IKM)
// 其中IKM为ECDHE共享密钥，salt为协议定义的固定值
// 随后通过HKDF-Expand派生出：
// client_handshake_traffic_secret
// server_handshake_traffic_secret
// client_application_traffic_secret_0
// server_application_traffic_secret_0该过程中，SHA-384同时承担了哈希和HMAC的双重角色。协议设计者必须确保哈希函数的输出长度与安全强度匹配：256位哈希提供128位安全强度，384位哈希提供192位安全强度。
key = SHA256(secret1 || secret2)），应使用HKDF等标准化的密钥派生函数，以避免长度扩展攻击和不同输入域之间的关联性风险。
2.4 消息认证码（MAC）：完整性与数据源认证
核心原理
消息认证码是带密钥的哈希函数，输出称为认证标签（Tag）。与普通哈希不同，MAC的验证需要共享密钥，因此能够同时提供完整性（消息未被篡改）和数据源认证（消息确实来自持有密钥的一方）。HMAC的构造为 HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))，其中 K' 是经过填充的密钥，opad 和 ipad 为固定常量。CMAC则基于分组密码（如AES）的CBC-MAC改进版本，适用于硬件加速场景。
在协议设计中，MAC的典型应用场景包括：
- 在非AEAD加密模式下，对密文计算MAC（Encrypt-then-MAC）。
- 在握手协议中，对握手消息的哈希值进行MAC计算，实现消息流完整性。
- 在会话票据（Session Ticket）中，使用MAC防止票据被篡改。
常见误区与复盘
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 先MAC后加密（MAC-then-Encrypt） | 可能引入padding oracle攻击 | 使用Encrypt-then-MAC或AEAD |
| 对明文和密文使用同一密钥 | 密钥重用导致安全性退化 | 加密密钥与MAC密钥必须独立派生 |
| MAC验证时使用非恒定时间比较 | 时序侧信道泄露标签信息 | 使用恒定时间比较函数（如 crypto_equal） |
| 忽略MAC标签长度截断 | 降低伪造难度 | 标签至少128位（如AES-GCM的16字节） |
小型场景化说明：物联网固件更新协议
假设设计一个IoT设备固件更新协议，固件包大小约50MB，设备资源受限。初始方案为：设备下载固件后计算SHA-256哈希，与服务器下发的哈希值比对。但攻击者可以同时篡改固件和哈希值。改进方案为：服务器使用HMAC-SHA256对固件计算认证标签，设备使用预置的共享密钥验证。进一步优化：由于固件较大，可先计算固件的SHA-256摘要，再对摘要计算HMAC，这样既保证了完整性，又减少了MAC计算的开销。最终方案为：固件包 = 固件数据 || SHA256(固件数据) || HMAC-SHA256(SHA256(固件数据), K)。该方案在设备端只需一次完整读取计算SHA-256，HMAC仅对32字节摘要计算，性能开销极小。
2.5 四种原语的协同与协议构造模式
一个健壮的安全通信协议通常按照以下模式组合四种原语：
- 握手阶段：使用非对称加密（ECDHE）协商会话密钥，使用数字签名完成身份认证。
- 密钥派生：通过HKDF将共享密钥扩展为多个独立的工作密钥（加密密钥、MAC密钥、IV等）。
- 数据传输：使用AEAD对称加密（如AES-256-GCM）保护应用数据，同时提供机密性和完整性。
- 会话管理：使用哈希函数生成会话标识、计算密钥更新参数。
这种分层设计确保了即使某一原语被攻破（如哈希碰撞），其他安全属性仍然得到保护。例如，TLS 1.3中即使攻击者能够碰撞SHA-256，也无法解密通信内容，因为加密密钥独立于哈希函数的抗碰撞性。