1. 密码学与密码工程导论

密码学是一门研究如何在不安全信道上实现安全通信与可信计算的学科。它的核心目标不是“把信息藏起来”这么简单,而是要在明确的威胁模型下,保证数据的机密性、完整性、真实性和可用性。密码工程则是把密码学理论转化为可部署系统的工程实践:它关心算法选型、密钥生命周期、协议交互、随机数质量、侧信道防护、性能与合规等现实约束。理解这两者的区别与联系,是学习本课程的第一块基石。

一、课程目标与学习路径

本课程面向“能理解、能实现、能评估”三个层次。理解层面,需要掌握对称加密、公钥密码、哈希函数、消息认证码、数字签名、密钥交换等基本原语的安全定义与典型构造;实现层面,需要能够使用标准库完成加密、签名、验签、密钥派生等操作,并正确处理随机数、填充、编码和错误处理;评估层面,需要能够识别常见误用,例如ECB模式泄露明文结构、固定IV导致重放、RSA未加填充、随机数可预测等。课程后续章节会围绕这些能力逐步展开,而本章负责建立整体地图。

二、密码学发展脉络

密码学大致经历了三个阶段。第一阶段是古典密码,以替换和置换为主,如凯撒密码、维吉尼亚密码,安全性依赖算法保密和手工计算,容易被频率分析攻破。第二阶段是现代密码学,以Shannon提出的混淆与扩散原则为标志,出现了DES、AES等分组密码,以及RSA、Diffie-Hellman等公钥算法,安全性开始建立在数学难题和公开算法之上。第三阶段是密码工程与可证明安全,强调形式化安全模型、可证明安全归约、标准化协议(如TLS 1.3、Signal协议)以及工程实现中的侧信道与容错问题。这一脉络说明:算法公开不等于不安全,真正的安全来自密钥保密和严谨的工程实现。

三、密码工程的定义与范畴

密码工程不是“调用一个加密函数”那么简单。它至少覆盖以下范畴:

  • 原语选择与参数配置:例如AES-128-GCM用于认证加密,SHA-256用于哈希,Ed25519用于签名,X25519用于密钥交换。
  • 密钥管理:包括密钥生成、分发、存储、轮换、撤销和销毁。密钥一旦泄露,算法再强也无意义。
  • 协议设计:定义消息顺序、身份认证、前向保密、重放保护等,如TLS握手、Noise协议框架。
  • 实现安全:防止时序攻击、缓存攻击、故障注入等侧信道威胁,常需常数时间实现和硬件保护。
  • 合规与标准:遵循NIST、ISO、GM/T等标准,满足行业监管要求。

一个典型的工程判断是:如果只需要保证数据不被篡改,使用HMAC-SHA256即可;如果需要同时保证机密性和完整性,应优先选择AES-GCM或ChaCha20-Poly1305这类AEAD算法,而不是“先AES-CBC再HMAC”的手工组合,因为后者容易在填充和MAC顺序上出错。

四、安全目标与攻击模型

密码系统的安全目标通常归纳为CIA triad,但在工程中需要更细化的表述:

安全目标含义典型技术
机密性未授权者无法读取明文AES-GCM、RSA-OAEP
完整性数据未被篡改HMAC、AEAD标签
真实性确认消息来源身份数字签名、证书
不可否认性发送者无法否认行为Ed25519、RSA-PSS
前向保密长期密钥泄露不影响历史会话ECDHE、X25519

攻击模型则描述攻击者能力。常见模型包括:唯密文攻击、已知明文攻击、选择明文攻击(CPA)、选择密文攻击(CCA)、选择消息攻击等。工程上最需要警惕的是CCA,因为现实协议中攻击者往往能构造密文并观察解密结果。AEAD算法之所以重要,正是因为它们在设计上就抵抗CCA。另一个关键模型是侧信道攻击,攻击者不直接破解数学难题,而是通过功耗、时间、电磁辐射等物理信息推断密钥。这提醒我们:安全目标必须与攻击模型匹配,脱离模型的“安全”没有意义。

五、现代密码系统的整体架构

一个现代密码系统通常由以下层次构成:最底层是密码原语(AES、SHA-2、Curve25519等);其上是密码协议(TLS、SSH、IPsec、Signal);再上是密钥管理与身份基础设施(KMS、PKI、CA、HSM);最上层是应用接口与业务逻辑(加密API、SDK、配置策略)。数据从应用层进入,经过协议封装、原语运算、密钥调用,最终形成密文或签名在网络中传输。下图展示了这一整体架构与典型数据流。

现代密码系统整体架构与数据流 应用层 业务数据 · 用户身份 · 策略配置 · 加密API调用 明文 / 待签名数据 封装请求 协议层 TLS 1.3 · Noise · SSH · IPsec · 握手 / 记录 / 重放保护 身份认证 密钥协商 前向保密 消息分帧 调用原语 密码原语层 AES-GCM / ChaCha20 SHA-256 / SHA-3 HMAC / KDF Ed25519 / X25519 密钥调用 密钥与身份基础设施 KMS · HSM · PKI / CA · 密钥轮换 · 撤销 · 审计日志 密钥生命周期管理 密文/签名

从图中可以看到,数据并不是直接“加密”就结束,而是经过应用层封装、协议层协商、原语层运算和密钥层调用,最终才形成可传输的密文或签名。任何一层出错,整体安全性都会下降。例如,协议层若缺少重放保护,攻击者可以重复发送旧密文;密钥层若使用弱随机数生成密钥,原语再强也会被预测。

六、一个可操作的教学示例

假设我们要在客户端与服务端之间传输一条消息“transfer=100”。一个合理的工程做法是:双方先通过X25519完成ECDHE密钥交换,使用HKDF-SHA256从共享秘密派生会话密钥,然后使用AES-128-GCM对消息加密,并附加96位随机nonce和128位认证标签。接收方用相同密钥和nonce解密,并验证标签。如果标签验证失败,直接丢弃消息,不返回任何明文信息,以避免padding oracle类攻击。这个流程体现了“先协商、再派生、后加密、必验证”的工程顺序,也是TLS 1.3记录层的基本思路。

工程提示:选择AEAD算法时,优先使用标准库提供的AES-GCM或ChaCha20-Poly1305,不要自行拼接“加密+MAC”。如果必须组合,应遵循Encrypt-then-MAC顺序,并对IV、密文和关联数据一起计算MAC。
常见误区:把哈希函数当作加密使用。SHA-256是单向的,不能用来“解密”;把Base64当作加密也是错误的,它只是编码,不提供任何机密性。