密码学协议与密钥工程

• 两种 AEAD 的硬件与软件性能
• 各协议对 AEAD 的选型
• 网络性能与 CPU 指令集

二者都是 AEAD，同时提供机密性与完整性。AES-GCM 依赖 AES-NI 硬件加速，在有 AES-NI 的 x86/服务器上性能极佳；ChaCha20-Poly1305 是纯软件 ARX 实现，在无 AES-NI 或 SIMD 受限的设备（特别是 ARM 移动端）上性能更好且更抗时序侧信道。TLS 1.3 与 QUIC 都同时支持两者，由客户端与服务器协商选择；WireGuard 选择了 ChaCha20-Poly1305，因为它目标平台多样、软件实现高效、且无 AES-NI 的移动/嵌入式设备上优势明显。

工程取舍集中在"硬件加速可用性"与"软件跨平台性能"。协议层同时支持两种 AEAD 是 crypto-agility 的体现，让端点在适配其硬件能力的前提下选择最优。

• HPKE 的架构（KEM+KDF+AEAD）
• 三种模式 base/PSK/Auth
• 与 E2E 加密的集成

HPKE（Hybrid Public Key Encryption，RFC 9180）是一种现代"混合公钥加密"方案，用 KEM（如 X25519、ML-KEM）协商对称密钥，再用 AEAD 加密数据，并通过 KDF 派生密钥。它提供三种模式：base（基础）、PSK（预共享密钥）、Auth（认证发送者）。在端到端加密邮件与消息中，HPKE 用于向某接收方公钥加密数据，配合封装密钥（encapsulated key）让接收方用私钥解封，简化了传统"RSA-OAEP 加密+对称加密"的复杂流程，并天然支持后量子 KEM 替换。

HPKE 把"密钥协商+数据加密"标准化为单一 API，减少实现错误，且各组件可替换（crypto-agility）。它被 Message Layer Security、OHTTP 等现代协议采用。

• 双线性配对
• 签名聚合能力
• 短签名与聚合应用

BLS 签名基于双线性配对（pairing），签名是曲线上的一个群元素，签名很短（约 32-48 字节）。其突出特性是支持签名聚合：多个不同签名者的签名可以聚合为单个短签名，且验证时只需一次配对运算，大幅降低验证开销。这在区块链（如 Ethereum 2.0 的聚合）、共识协议、BLS12-381 曲线等场景中很有价值。缺点是配对运算较慢，且需要 pairing-friendly 曲线。

BLS 的聚合能力来自双线性映射 e(aG, bH)=e(G,H)^(ab) 的性质，使多个签名可合并验证。它适合"多签名者、少验证量"的场景，与 ECDSA 不可聚合形成对比。

• 相同安全强度下的密钥长度
• 加解密/签名验签速度
• 带宽与存储

在相同安全强度下，ECC 的密钥长度远小于 RSA（如 256 位 ECC 约等价于 3072 位 RSA），因此密钥、签名、公钥更小，带宽和存储开销更低。计算上，ECC 的密钥生成、签名和验签通常更快，但 RSA 加密（公钥运算）较快而解密（私钥运算）较慢；ECC 的私钥运算（点乘）也较快。整体上 ECC 在相同安全级别下性能和带宽更优，是现代 TLS（ECDHE、ECDSA）和区块链的主流选择。

安全强度对标：ECC-256≈RSA-3072，ECC-384≈RSA-7680。ECC 在移动端、IoT、低带宽场景下优势明显，且点乘更省资源。

• 基于 Curve25519/Curve448 的 ECDH
• Montgomery 曲线
• 常数时间与安全性

X25519 是基于 Curve25519（Montgomery 曲线）的 ECDH 密钥交换函数，X448 基于 Curve448。它们在 libsodium、OpenSSL 等库中提供"X25519()"API，输入对方公钥与自己的私钥，输出共享密钥。其设计目标是恒定时间实现（避免时序侧信道）、简单安全、无密钥协商的复杂填充问题，且随机数要求低。X25519 提供约 128 位安全强度，X448 提供约 224 位。它们被 TLS 1.3、Signal、WireGuard 广泛采用。

Curve25519 的 Montgomery 形式让 X25519 极易实现为常数时间，天然抗侧信道，且私钥生成可采用 clamp 处理，简化实现。这是其成为现代默认 ECDH 的原因。

• 握手阶段的签名与验签
• RSA vs ECDSA 的运算成本
• 证书链验证

TLS 握手中，服务器需要对握手消息签名（做服务器身份认证），客户端验证签名。ECDSA 的签名与验签在相同安全强度下比 RSA 更快、密钥更小；RSA 的私钥签名（私钥运算）较慢，而验签（公钥运算）较快。此外 ECDSA 证书更小，握手报文更小。因此在 TLS 1.3 中，ECDSA（P-256/P-384）和 EdDSA 是主流签名，RSA 仍在兼容但逐渐被替代。握手时还有密钥交换（ECDHE）与证书链验证，ECC 系整体更高效。

RFC 8446（TLS 1.3）推荐 ECDSA 与 EdDSA，RSA 作为兼容保留。ECC 在小报文、低延迟、移动端场景优势明显。

• 幂运算与离散对数
• 共享密钥构造
• 安全性假设

DH 基于模幂运算：双方选共享公开参数 g 和素数 p，各自选私钥 a、b，计算 A=g^a mod p、B=g^b mod p 并发送给对方，随后各自计算 s=B^a mod p 和 s=A^b mod p，得到相同共享密钥 g^(ab) mod p。窃听者只知道 A、B、g、p，但由 A 求 a 是离散对数问题，在计算上不可行，因此无法计算共享密钥。DH 提供前向保密（配合临时密钥），但不提供身份认证，需配合签名或证书。

DH 的安全性建立在离散对数问题的计算困难性上。它解决"密钥协商"而非"认证"，实际应用（如 TLS）中需结合证书验证身份。

• ECDH 的点乘运算
• 相同安全强度下的长度与速度
• 应用场景

ECDH 在椭圆曲线群上做标量乘法：双方生成私钥 d、计算公钥 Q=dG，收到对方公钥后计算共享点 d·Q'，其 x 坐标作为共享密钥。相比传统 DH，相同安全强度下 ECDH 的密钥和参数更小（256 位 vs 3072 位）、运算更快、占用带宽更少，且 Curve25519 支持常数时间实现。因此 ECDH 在 TLS、移动端、IoT、低功耗设备上性能优势明显，是现代密钥协商的主流。

ECDH 的安全基础是椭圆曲线离散对数问题，在相同安全级别下比整数 DH 更高效。X25519 是 ECDH 的工程化实现。

• 1-RTT 的完整握手与密钥派生
• 0-RTT 的预置密钥与 early data
• 安全权衡（重放）

TLS 1.3 完整握手是 1-RTT：客户端 ClientHello 与服务器 ServerHello 后，双方通过 ECDHE 协商出共享 secret，再经 HKDF 的 extract/expand 派生主密钥与各阶段密钥，随后加密证书与握手消息。0-RTT 是复用之前会话（PSK 或 resumption）的优化：客户端在第一次报文（ClientHello）中就可以携带 early data 数据，用从先前会话派生的密钥加密，从而少一次往返。代价是 0-RTT 数据可能被重放，且无法获得前向保密（因为复用旧密钥），因此只用于幂等、低风险数据。

0-RTT 牺牲前向保密与抗重放，换取低延迟。1-RTT 每次都用新临时密钥，前向保密完整。工程上需权衡延迟与安全。

• CSPRNG 必要性
• Padding Oracle 规避
• 制造安全实践

侧信道攻击利用实现的物理信息泄露：时序侧信道（运算时间依赖密钥）、Cache 侧信道（访问模式泄露）、功耗侧信道（功耗波形）。规避需常数时间实现、避免依赖密钥的查表与分支、使用硬件加速。随机数必须用 CSPRNG，否则密钥/Nonce 可被预测。Padding Oracle 攻击利用解密时对 padding 校验的错误提示，规避方法是使用 AEAD（如 GCM）、统一错误信息、仅做认证再解密。整体应使用成熟库、避免手工实现、遵循最小化与参数化设计。

这些漏洞来自"实现与算法分离"，属于工程层面。正确做法是把机密性、完整性交给 AEAD，把随机数交给系统 CSPRNG，把比较做成常数时间。

• FIPS 140-2/3 是模块安全认证
• FIPS 203/204/205 是算法标准
• 商业产品合规差异

FIPS 140-2/3 是密码模块的安全认证标准，定义密码模块的物理安全、密钥管理、接口、自检等要求，用于政府与合规场景（如 US federal）。FIPS 203/204/205 是后量子算法标准：203 定义 ML-KEM，204 定义 ML-DSA，205 定义 SLH-DSA。前者是"模块级认证"，后者是"算法级标准"。商业产品差异在于：FIPS 140 认证要求产品在特定模块上通过 NIST 认证测试，而 PQC 算法标准规定了算法实现与参数，产品需在 FIPS 140 认证模块中集成 PQC 算法以满足合规迁移。

两者层级不同：FIPS 140 强调"模块如何安全地实现密码功能"，FIPS 203/204/205 强调"算法用哪套参数、如何实现"。商用产品须同时满足模块认证与算法标准。

• Edwards 曲线的常数时间
• 签名速度与安全性
• 确定性签名

Ed25519 基于 Edwards 曲线 Curve25519，Ed448 基于 Curve448，是 Edwards-curve 数字签名算法（EdDSA）。其优势包括：实现简洁、支持常数时间（抗时序侧信道）、签名速度快（约 10μs）、签名短（Ed25519 为 64 字节）、确定性签名（无需额外随机数，避免 nonce 复用风险）、公钥小。Ed25519 提供约 128 位安全强度，Ed448 约 224 位。被 SSH、PGP、TLS 1.3、区块链广泛采用。

Edwards 曲线的完整加法公式天然适合常数时间实现，且确定性 nonce 消除了 ECDSA 的 nonce 复用漏洞，因此比 ECDSA 更安全、更易正确实现。

• 签名与验签的运算差异
• 相对其他算法的性能
• 实际吞吐

Ed25519 的签名约 10μs、验签约 30μs（具体数字依硬件而定），表明它极快，每秒可完成数万至数十万次签名/验签。验签比签名慢约 3 倍，因为验签需要做倍点运算并验证曲线方程，而签名主要是单次标量乘法。相比 RSA 私钥运算和 ECDSA 验签，Ed25519 在同类安全强度下性能优异，适合高吞吐的签名场景（如 TLS 握手、区块链交易、代码签名）。

这里"约 10μs/30μs"是典型现代 CPU 上的量级，用于说明 EdDSA 的高性能和低延迟，帮助工程选型判断每秒可处理的签名数量。

• 各长度对应的安全强度
• NIST 建议
• 长期安全考虑

RSA 安全强度大致为：2048 位约 112 位安全强度，3072 位约 128 位，4096 位约 140 位。NIST SP 800-57 建议 2030 年之前使用 2048 位及以上，之后推荐 3072 位及以上；256 位 ECC 对标 3072 位 RSA。选择时要平衡安全强度与性能：2048 位是当前最低可接受值，3072 位是较长期推荐，4096 位带来自负增益但性能下降明显。量子时代 RSA 面临 Shor 算法威胁，需迁移到 PQC。

RSA 密钥越长，安全强度越高但运算与带宽越大。NIST 建议随时代提高最小值，以对冲计算能力增长。密钥长度选择是"安全强度需求"与"性能/带宽"的权衡。

• OAEP 填充的随机化与安全性
• PSS 填充的随机化与安全性
• 替代 PKCS#1 v1.5 的理由

RSA-OAEP 是 RSA 加密的填充方案，通过 MGF（掩码生成函数）进行随机化填充，使相同明文产生不同密文，并抵抗选择密文攻击（CCA）。RSA-PSS 是 RSA 签名的随机化填充方案，通过随机盐使相同消息产生不同签名，抵抗选择消息攻击，安全性有形式化证明。二者都替代了有缺陷的 PKCS#1 v1.5 填充（v1.5 加密存在 Bleichenbacher 攻击），因此现代系统强制使用 OAEP 加密与 PSS 签名。

随机化填充是 RSA 安全的关键：v1.5 的确定性填充与可预测结构导致 padding oracle 攻击。OAEP 与 PSS 的随机化与掩码结构消除了这些攻击面。

• X25519 临时密钥
• ECDHE 的会话密钥
• 前向保密机制

X25519 作为 ECDH 函数，在 TLS 中通常以 ECDHE（临时 ECDH）方式使用：双方每次握手都生成新的临时 X25519 密钥对，用公钥协商出会话密钥，握手结束后销毁临时私钥。由于会话密钥只依赖临时密钥，服务器长期私钥（用于签名认证）不参与密钥派生，即使长期私钥泄露，历史会话也无法被解密，从而提供前向保密。X25519MLKEM768 等混合方案也在保持前向保密的同时加入后量子安全。

前向保密的关键是"临时密钥用完即弃"。X25519 的高效与常数时间特性使其成为 ECDHE 前向保密的首选实现。

• PKCS#7/PKCS#5 的块填充
• OAEP 的加密填充
• PSS 的签名填充

PKCS#7（AES 等分组密码）与 PKCS#5（主要针对 8 字节块 DES）是分组密码的块填充，用于把明文补充到块长度，填充字节值等于填充长度。OAEP 是 RSA 加密的随机化填充，含掩码生成函数与随机种子，抵抗选择密文攻击。PSS 是 RSA 签名的随机化填充，含随机盐，抵抗选择消息攻击。PKCS#7/5 用于对称分组加密，OAEP/PSS 用于 RSA 非对称运算，用途与安全性质完全不同。

PKCS#7/5 是"长度对齐"填充，OAEP/PSS 是"安全强化"填充。前者解决块边界，后者解决 RSA 的数学结构安全问题。CBC 模式下 PKCS#7 填充配合错误提示可引发 padding oracle 攻击。

• 常数时间与实现难度
• 性能与安全性
• 生态兼容性

Curve25519 实现了常数时间抗侧信道、实现简单、速度较快，安全性设计保守（无 NSA 参数），适合现代协议；但 X25519 只做 ECDH，不能直接签名（需 Ed25519）。secp256r1（P-256）是 NIST 标准曲线，被 TLS 证书、浏览器、FIPS 场景广泛支持，生态兼容性好，但实现中需注意常数时间与 nonce 管理，且字段（p=2^256-2^224+...）运算在部分架构上略慢。工程取舍：新系统倾向 Curve25519（更安全、更快），需兼容既有生态时用 P-256。

Curve25519 的 Montgomery 形式与精心选择的参数使其成为"安全默认"；P-256 因生态成熟仍是许多标准化场景（如 WebAuthn、TLS 证书）的基线。两者都约 128 位安全强度。

• ECDSA 的 nonce k 的作用
• nonce 复用导致私钥泄露
• Sony PS3 教训

ECDSA 签名需要随机 nonce k，若同一私钥对两条不同消息复用同一个 k，攻击者可通过两条签名方程相减直接恢复私钥 d。Sony PS3 事件中，其固件签名使用了固定随机数 k，导致攻击者轻松恢复私钥，进而伪造任意游戏的签名。这警示 ECDSA 必须保证 nonce 唯一且不可预测，否则私钥即刻泄露。这也推动了确定性签名（如 RFC 6979，用消息哈希派生 k）和 EdDSA 的采用。

nonce 是 ECDSA 的"一次性秘密"，复用的后果是私钥泄露，而非仅签名可伪造。确定性 nonce 或 EdDSA 从根源上消除该风险。

• 各曲线的安全强度
• 性能与负载
• 合规与兼容

NIST P-256、P-384、P-521 是 FIPS 186 定义的素数域曲线，安全强度分别约 128、192、256 位。P-256 最常用，性能最好、兼容性最广，是多数场景（TLS、证书）的默认；P-384 用于更高安全需求（如 CNSA 1.0 要求）；P-521 提供最高强度但运算与带宽成本大。工程取舍：在满足安全需求的前提下选最轻的曲线，P-256 是普遍选择，P-384/P-521 用于合规或高安全场景。需注意这些曲线实现上的常数时间与侧信道问题。

曲线选择与安全强度、性能、合规绑定。P-256 是"性价比"最优，P-521 是"强度"最优但成本高。P-384 常用于满足某些监管要求。

• 各协议的 Ed25519 支持
• 密钥与签名格式
• 兼容性

SSH 支持 Ed25519 作为主机密钥与用户认证密钥（ssh-ed25519），OpenSSH 默认支持且推荐。PGP/GnuPG 自 2.1 起支持 Ed25519 签名与 Curve25519 加密。TLS 1.3 支持 Ed25519 作为证书签名算法与握手签名算法（signature_algorithms 扩展）。三者的共同点是 Ed25519 提供小密钥、快速签名、确定性 nonce、常数时间抗侧信道，非常适合现代应用。但旧系统/库可能不支持，需注意兼容性。

Ed25519 已成现代密码学的事实标准之一，被主流协议与库广泛支持，其安全性、性能与实现简单性使它在 SSH、PGP、TLS 中逐渐成为默认推荐。

• secp256k1 的参数与安全性
• 性能优化
• 应用与风险

secp256k1 是比特币等区块链使用的椭圆曲线，其素数 p 接近 2^256，形式简单（k=1），支持高效的标量乘法优化（如利用 p 的特殊形式、GLV 分解），因此签名验签性能好。它提供约 128 位安全强度，与 P-256 同级。工程上它的优势是性能与确定性（RFC 6979 确定性 nonce），但长期使用固定曲线存在量子威胁（Shor 算法），且缺乏更广泛第三方生态（不像 P-256 那样被 TLS 证书广泛采用）。它在区块链、签名、密钥派生（BIP32）中广泛使用。

secp256k1 的 k=1 使部分优化更高效，但安全性分析与 P-256 相当。工程取舍是"性能与生态" vs "通用兼容性"，区块链生态普遍采用它。

• 双线性配对
• BLS12-381 的参数
• ZK 证明的效率

BLS12-381 是 pairing-friendly 曲线，支持高效的双线性配对运算，是 zk-SNARK（如 Groth16、Plonk）等零知识证明系统的关键基础设施。配对运算用于验证多项式承诺与证明关系，BLS12-381 的安全强度（约 128 位）与字段大小使其成为 ZK 证明的主流选择。它还支持 BLS 签名聚合。工程上它被 Zcash、Ethereum、zk-STARK 证明系统等广泛使用，其参数选择平衡了配对效率与安全。

双线性配对是许多 ZK 证明和签名聚合的数学基础。BLS12-381 通过精心选择的子群阶与嵌入度，在安全性与运算效率间取得平衡，成为 ZK 领域的"默认曲线"。

• HPKE 的组成与架构
• 三种模式
• 现代应用

HPKE（RFC 9180）是混合公钥加密标准，通过 KEM（如 X25519、ML-KEM 768）协商出共享密钥，用 KDF（如 HKDF-SHA256）派生密钥，再用 AEAD（如 AES-128-GCM、ChaCha20-Poly1305）加密数据。它提供 base、PSK、Auth 三种模式，分别用于无需认证、预共享密钥认证、认证发送者。HPKE 把"非对称加密少量数据"标准化为单一 API，简化了以前的 OAEP/混合方案，支持算法替换（crypto-agility），被 E2E 加密、OHTTP、MLS 等采用。

HPKE 的价值在于"架构标准化+组件可替换"。它分离密钥协商、派生与加密三个环节，使各层可独立升级（如把 KEM 换成 ML-KEM 实现后量子），是现代协议设计的基础构件。

• nonce 重用对机密性的影响
• nonce 重用对认证的影响
• 随机 vs 计数器 nonce 的约束

AEAD 使用 nonce 使每次加密的密钥流唯一。若同一 key 下 nonce 重用，CTR 模式密钥流重复，两个密文异或可恢复明文（破坏机密性）；同时 GCM 的 GHASH 认证密钥、ChaCha20-Poly1305 的 Poly1305 子密钥也会被推导，攻击者可伪造认证标签（破坏完整性），因此 nonce 重用同时破坏机密性与完整性。随机 nonce 要求碰撞概率低（如 12 字节随机值，需密钥生命周期内统计安全），计数器 nonce 要求严格单调递增、绝不回绕，且需多重实例共享时保证全局唯一。

AEAD 的 nonce 是安全性的单点故障。工程上必须对 nonce 生命周期做严格管理，随机 nonce 依赖概率，计数器 nonce 依赖状态管理，二者都不可违反"同一 key 下 nonce 唯一"。

• 各 KDF 的内存硬度
• 并行度
• 抗 ASIC/GPU

PBKDF2 只做重复哈希，无内存硬度，抗 GPU/ASIC 弱，但靠迭代次数。bcrypt 有少量内存（约 4KB）与迭代，抗 GPU 中等，但不抗 ASIC、内存使用固定。scrypt 引入内存硬度（内存与时间参数），通过大内存占用提高并行破解成本，抗 ASIC 较好。Argon2id 是 Argon2 的混合变体，同时提供内存硬度、时间成本与并行度可调，设计上抗 GPU/ASIC 与侧信道，是当前最推荐的口令 KDF（OWASP 首选）。综合排序：Argon2id > scrypt > bcrypt > PBKDF2（按现代安全性）。

内存硬度是核心：大内存使 ASIC/GPU 无法并行处理大量口令，从而抬高破解成本。Argon2id 兼顾数据依赖与数据独立，抗侧信道且内存可调，是口令哈希的全新最佳实践。

• 带盐与内存困难的意义
• 透明重哈希
• 渐进迁移策略

密码验证应采用带盐的内存困难 KDF（如 Argon2id、scrypt），因为：盐打破彩虹表、内存困难抬高 GPU/ASIC 暴力破解成本、算法可调参随硬件升级。参数升级时，不能一次性重算所有存量哈希（代价大且需用户口令），应使用"透明重哈希"（transparent rehash）：验证时若发现存量哈希用的是旧参数，重新用新参数计算并更新存储，用户下次登录时自动升级。同时可采取分期迁移（分批、按用户活跃度）与新旧参数并存运行。

渐进迁移的关键是"验证时升级"而非"离线重算"，前提是 get 到用户明文口令（登录时）才能重哈希。这样既完成参数升级，又避免停机与大规模重算。

• CHACHA20 的软件实现优势
• AES-NI 与 ARMv8 AES 指令
• 平台差异

AES-GCM 依赖 AES-NI（x86）或 ARMv8 AES 指令（AESD/AESE）硬件加速；在无这些指令或 SIMD 受限的老旧 ARM 设备上，AES-GCM 软件实现慢且易受时序侧信道影响。ChaCha20-Poly1305 是纯 ARX 软件算法，无需硬件指令即可高效运行，且天然常数时间，因此在广泛 ARM 移动端（尤其无 AES 硬件加速的设备）上性能与安全性优于 AES-GCM。取舍：有 AES-NI 的 x86 服务器上 AES-GCM 更快；ARMv8 新设备有 AES 指令时 AES-GCM 也快，但 ChaCha20 在无硬件加速的广泛移动端上更稳。因此 TLS 1.3 同时支持两者，由端点协商。

工程取舍是"依赖硬件加速" vs "纯软件一致性"。ChaCha20 保证跨平台一致的性能与常数时间，AES-GCM 在有硬件加速时更快。协议层支持两者以适配不同硬件。

• X25519/X448 的性能与侧信道
• libsodium 与 BoringSSL 的实现
• 工程差异

X25519/X448 基于 Montgomery 曲线，标量乘法可用常数时间实现，抗时序侧信道；性能上 X25519 约 128 位安全强度、X448 约 224 位，均极快。libsodium 与 BoringSSL 都实现了 X25519，但实现策略不同：libsodium 采用 ref10 等参考实现，强调跨平台与可移植性；BoringSSL 采用高度优化的汇编（如 x86_64 的 51 位 limb 实现），针对特定平台极致优化性能。两者都保证常数时间与安全，差异在性能优化程度、平台支持与 API 设计。工程上按目标平台与性能需求选择。

实现差异主要体现为"移植性 vs 极致性能"。BoringSSL 为 Chrome 等优化的汇编更快但依赖特定 CPU；libsodium 更通用。安全性上两者都遵循常数时间规范。

• 计数器 nonce 的共享状态
• 跨进程 nonce 唯一性
• 重复风险与代价

若 AES-GCM nonce 由 64 位计数器递增，跨多进程共享同一 key 时，nonce 唯一性依赖计数器的全局单调性。若各进程各自维护计数器，可能产生重复 nonce（破坏机密性与完整性）；若共享计数器，则需原子递增与同步，引入协调开销与瓶颈。工程上评估：单进程内计数器可保证唯一，但跨进程/多实例需引入分布式唯一性（如机器 ID+进程 ID+计数器组合，或由中央服务分配），并考虑计数器回绕风险（2^64 上限）。更稳妥的做法是每个 key 只由一个进程使用，或使用足够宽的随机 nonce。

计数器 nonce 的唯一性是"全局必须成立"的硬约束，跨进程共享 key 时成本是协调与同步。若 key 生命周期长、实例多，计数器方案风险高，应改用随机 nonce 或为每个实例独立 key。

• 各库的 API 风格
• 误用防御
• 集成方式

libsodium 提供高层、难以误用的 API（如 crypto_sign、crypto_box），强调开箱即用、自动选择安全参数，适合快速集成。ring（Rust）提供安全默认、编译期排除不安全算法，适合 Rust 生态。Tink（Google）提供"接口级"API 与密钥管理抽象（keyset），强制使用 AEAD 等安全原语，支持密钥轮换。BoringSSL 是 Chromium 的 OpenSSL 分支，提供底层 FIPS 认证的 C API，性能极佳但需谨慎使用。API 差异影响集成：高层库（libsodium/Tink）减少误用、集成快；底层库（BoringSSL）性能强但需更多安全知识。工程上按安全需求、语言生态与性能要求选库。

"误用免变"（misuse-resistant）是 API 设计的关键。Tink 通过 Keyset 强制正确使用，libsodium 通过简化原语减少误用，而底层库把安全责任交给开发者。工程集成应优先选高层、抗误用的库。

• transcript 哈希
• 降级防护
• 跨协议混淆

协议把握手过程中所有消息（包括版本、密钥交换参数、随机数、证书）做哈希（transcript hash），并让签名、密钥派生都绑定该 hash。这样若攻击者试图降级协议版本（如从 TLS 1.3 降到 1.2）或改变参数，transcript 会变化，签名验证失败，密钥派生不同，从而被检测。绑定身份（证书、PSK 标识）与上下文（协议标签、应用数据）防止把某协议的握手消息误用于另一协议（跨协议混淆），避免攻击者重放或混淆不同协议的消息。TLS 1.3 用 HKDF 的 info 参数与 transcript 绑定实现这一点。

transcript 绑定是"防篡改协议状态"的机制。任何参数变化都会改变哈希，进而改变签名与密钥派生，从根源上阻止降级与混淆攻击。这是现代协议（TLS 1.3、Signal）的基石。

• FAPI 的安全要求
• mTLS、PAR、JAR 的作用
• 金融场景部署

FAPI（Financial-grade API）是 OpenID 基金会针对金融等高安全场景的 OIDC/OAuth 配置文件，要求更强的安全控制。mTLS（双向 TLS）用于客户端与 server 双向认证，绑定客户端身份与证书，防止请求拦截。PAR（Pushed Authorization Requests）在授权码流程中把高敏感请求参数推送到授权服务器，减少 URL 长度与参数篡改风险。JAR（JWT Secured Authorization Request）用 JWT 签名或加密授权请求，保证请求完整性与会话绑定。三者部署通常结合：客户端证书（mTLS）绑定、PAR 推送请求、JAR 签名请求，配合严格的 client authentication 与 token 绑定，满足金融合规。

FAPI 的部署是"纵深防御"：mTLS 保护传输与身份，PAR 保护请求参数，JAR 保护请求完整性，共同防止授权码拦截、请求篡改与重放。金融场景要求高，常建议采用 FAPI 2.0 的安全基线。

• 混合密钥协商的安全性
• 兼容性与降级风险
• 成熟度

混合密钥交换（如 X25519MLKEM768）把经典 X25519 与后量子 ML-KEM 的协商结果共同派生会话密钥，安全性取两者取强：只要其中一方未破，会话就安全。这既获得后量子保护，又保留经典算法作为后备，避免纯 ML-KEM 的潜在实现缺陷或标准演进风险。直接替换为纯 ML-KEM 的风险包括：算法成熟度与实现验证不足、与现有中间件/库的兼容性、以及若 ML-KEM 某参数被攻破则无后备。混合模式实现平滑过渡（crypto-agility），是当前主流部署。

混合是"渐进式迁移"的保险策略。它保证在不确定的量子时间线下，无论经典还是后量子先被攻破，安全性都不降级。工程上双密钥协商成本低，收益是安全兜底。

• 混合证书的两种主要形式
• 中间盒与旧库的解析
• 兼容性风险

混合证书有两种形式：单一证书含两个签名（如 ECDSA+ML-DSA）或多个证书链（composite cert 或 parallel chains）。风险在于：存量中间盒（防火墙、负载均衡、代理）与旧 TLS 库可能无法解析新的扩展格式或两种签名，导致证书解析失败、握手拒绝或降级。单证书双签名需要扩展 ASN.1，旧实现可能忽略或报错；并行证书链需客户端支持多链验证。此外密钥长度、签名尺寸增大也会影响 MTU 与握手性能。缓解策略是回退到纯经典证书、渐进部署、或使用各自独立的证书链。

兼容性风险来自"新格式不被旧实现识别"。需在中间件升级前保留经典证书回退，并控制 PQC 签名尺寸对握手与传输的影响。工程上采用渐进式与回退机制。

• SLH-DSA 的哈希签名特性
• 签名尺寸与速度
• 信任根 vs 高频握手

SLH-DSA（原 SPHINCS+）是唯一基于安全哈希的无状态签名，安全性只依赖哈希函数（极为保守），无需做任何结构化假设，因此安全性极强，适合作为信任根（根 CA 签名）——其签名频次低、重安全性。但它的签名尺寸很大（约 7-49KB，远大于 ECDSA、ML-DSA）且签名/验签较慢，若用于高频 TLS 握手（每次握手都签名），会显著增加带宽与延迟，不适合。因此它作为"信任根用高安全签名"，而终端实体证书与握手用更小更快的 ML-DSA 或混合方案。

信任根签名频次低，可承受大尺寸与慢速度，换取最高安全性；高频握手看重签名尺寸与速度。SLH-DSA 的定位是"安全底线"而非"性能主力"。

• PKCS#1 v1.5 的 Bleichenbacher 攻击
• OAEP 的随机化与掩码
• 填充预言防御

PKCS#1 v1.5 加密填充是确定性的，且其格式可被攻击者探测（padding oracle 攻击，最著名的是 Bleichenbacher 1998 攻击），攻击者通过反复询问解密是否成功，逐步恢复明文，导致 RSA 加密被破坏。RSA-OAEP 采用随机化填充与掩码生成函数（MGF），使相同明文产生不同密文，且解密错误信息不含可被利用的填充结构差异，抵抗选择密文攻击（CCA）。因此现代系统强制使用 OAEP 加密，禁用 v1.5 加密。

差异核心是"填充的随机性与可预测性"。v1.5 的确定性填充使攻击者可利用 oracle 判断，OAEP 的随机化与掩码消除该信息泄露。PSS 也同理用于签名（替代 v1.5 签名）。

• 签名大小
• 验签性能
• 侧信道与安全性

Ed25519 签名 64 字节，Ed448 签名 114 字节，ECDSA P-256 签名约 64 字节（r,s 各 32 字节），大小相近。性能上 Ed25519 验签通常比 ECDSA 快（Edwards 高效公式），且确定性、常数时间抗侧信道；ECDSA 需要随机 nonce（存在 nonce 复用风险）且常数时间实现较难。侧信道安全性上 Ed25519 天然常数时间、确定性 nonce，更安全；ECDSA 需特别小心 nonce 与幂运算。取舍：新系统倾向 Ed25519（更安全、确定性、抗侧信道），需兼容既有生态（如 WebAuthn、TLS 证书）时用 P-256。

两者签名大小相近，但 Ed25519 在安全实现难度与侧信道鲁棒性上更优。ECDSA 的 nonce 管理是最大风险点，EdDSA 通过确定性 nonce 消除之。

• 可公开验证性
• 密钥分发
• 不可否认性

数字签名用私钥签名、公钥验证，公钥可公开分发，因此任何人都可用公钥验证签名，具有可公开验证性；由于只有私钥持有者能产生签名，可提供不可否认性（签名者无法抵赖）。MAC 用对称共享密钥生成和验证，双方都能验证，因此无法提供不可否认性（接收方可伪造 MAC），且密钥分发需双方共享密钥、无法公开。差异核心：签名是"非对称、可公开验证、不可否认"，MAC 是"对称、仅共享双方可验证、不可否认性弱"。

若需要第三方裁判或审计，必须用数字签名（不可否认）；若只需双方互信验证消息完整性，MAC 足够且更快。不可否认性依赖公钥公开与私钥独占。

• 序列号与滑动窗口
• 乱序接受与重复拒绝
• 窗口过小的后果

防重放窗口（如 IPsec、WireGuard 中的 replay window）维护一个已接收序列号的最大值 max 和一个窗口大小 N。收到序号 seq 时：若 seq>max 则接受并更新窗口；若 seq 在 [max-N+1, max] 内且未被记录则接受；若 seq 小于窗口左边界（太旧）或在窗口内但已记录则视为重复/重放而拒绝。这样能接受一定范围内的乱序报文，同时拒绝重放。窗口过小（N 太小）会导致合法乱序报文被误判为"太旧"而丢弃，造成丢包与重传；窗口过大则增加内存与状态维护成本。工程上需平衡乱序容忍度与状态开销。

窗口解决"乱序 vs 重放"的权衡：窗口越大容忍乱序越多，但重放检测范围也越大、状态越多。窗口大小需按网络乱序特性（如 IP 分片、多路径）设定。

• 层级密钥结构
• 逐层封装与派生
• 减少暴露与轮换

密钥分层（key hierarchy）把密钥分为根密钥（Root Key，KEK 的 KEK）、密钥加密密钥（KEK）和数据密钥（DEK）。根密钥通常保存在 HSM 中，KEK 用于加密 DEK，DEK 用于加密实际数据。DEK 只短暂存在、可频繁轮换，且泄露时只影响单个数据或少量数据；KEK 不直接加密数据，泄露影响面受控；根密钥极少使用、保存在高安全硬件中。这样，数据加密最频繁的 DEK 可低成本轮换，而根密钥与 KEK 的暴露面被最小化，实现"最小暴露 + 可控轮换"。

分层使"高价值密钥少用、低价值密钥常用"，把轮换成本与暴露风险集中在易替换的 DEK 上。KMS 的 envelope encryption（信封加密）正是这一思想的工程实现。

• alg=none 攻击
• ES256 的密钥混淆
• 防御策略

JWT "算法混淆"漏洞包括：1）alg=none 攻击，攻击者把签名算法改为 none 并删除签名，若服务器未强制要求签名则接受伪造 token；2）HS256/RS256 混淆，服务器用公钥验证 RS256 签名时，若被诱导把签名算法改为 HS256，并用公钥作为 HMAC 的密钥来验证，攻击者可用公钥自行构造 HMAC 签名（因为公钥公开）；3）ES256 存在密钥混淆（把公钥当私钥字节）等。防御：白名单允许的算法、禁止 none、验证时严格按 token 预设算法校验、不信任 header 中的 alg、使用库的安全默认（如只允许 RS256/ES256/EdDSA）、以及用 JWK 明确指定密钥用途。

根因是"信任 token 中的 alg 声明"。防御核心是"服务端固定算法、不随任意 header 变化"，并明确密钥类型与算法绑定。

• PKCE 的 code_verifier/code_challenge
• 授权码拦截防御
• 公共 vs 机密客户端

PKCE（RFC 7636）在授权码流程中，客户端首先生成随机 code_verifier，算出 code_challenge（SHA-256 或 plain）随授权请求发送；换取 token 时用 code_verifier 兑换，授权服务器校验 code_verifier 与 code_challenge 匹配。这样即使授权码被拦截，拦截者没有 code_verifier 也无法兑换 token，防御授权码拦截。机密客户端（有 client_secret）可用 client_secret 认证，PKCE 是额外加固；公共客户端（无 secret，如原生 App、SPA）PKCE 是必要防护，因为无法用 client_secret 认证。OAuth 2.1 强制公共客户端使用 PKCE。

PKCE 的本质是"证明授权码与请求者绑定"。公共客户端必须依赖 PKCE 而非 secret 来防御拦截，机密客户端也建议使用以增加纵深防御。

• 各字段语义
• 防重放与过期
• 受众与签发者验证

JWT 的标准声明组合提供安全控制：iss 标识签发者，用于验证 token 来源可信；aud 标识受众，限定 token 只被指定服务接受，防止跨服务复用；exp 设置过期时间，控制 token 生命周期，过期即失效；nbf 设置生效时间，防止 token 在指定时间前被使用；jti 是唯一 ID，配合服务端黑名单或一次性机制可防重放（同一 jti 只能使用一次）。工程组合：验证时校验 iss、aud、exp、nbf，用 jti 做重放检测，短 exp 限制暴露窗口，必要时轮换刷新 token。

这些声明是"验证链条"：iss 验证来源、aud 验证目标、exp/nbf 验证时间窗口、jti 验证唯一性。组合使用才能完整防御重放、过期与跨域滥用。

• 密钥/令牌轮换
• 审计与日志脱敏
• 根因修复

发现令牌泄露后应先迅速吊销受影响的令牌（调用撤销接口或黑名单），再轮换与该令牌关联的密钥/凭证（如客户端 secret、签名密钥），并审查日志找泄露途径。同时立即对日志系统做脱敏改造（不记录 Authorization 头、mask 敏感字段、加密日志、限制日志访问权限），防止此类泄露再次发生。最后做审计：检查泄露前的访问记录、评估影响范围（哪些数据被访问）、更新告警规则与监控。整个处置是"响应-修复-防范-审计"闭环。

处置优先级是"先止血（吊销）再修复（轮换）再防患（脱敏）再复盘（审计）"。日志脱敏是预防性措施，审计是事后溯源，两者与吊销轮换共同构成完整响应。

• harvest-now-decrypt-later 概念
• 非对称密码的紧迫性
• 对称密码的缓解

"先收集后解密"（HNDL）指攻击者现在抓取并存储加密流量，待未来量子计算机可用时再解密。这使非对称密码（RSA、ECC、DH）的迁移优先级最高，因为 Shor 算法一旦可用即可破 RSA/ECC，且历史数据会被解密；对称密码（AES）因 Grover 只是平方加速，只需 AES-256 加长密钥即可缓解，优先级较低。因此对长生命周期数据（医疗、政府、金融），现在就应迁移到 PQC 混合，否则未来这批数据会被解密。

HNDL 改变了"被动等待"的思维：因为数据有生命周期，long-lived data 现在就要迁移。非对称因 Shor 彻底破解而最紧迫，对称因加长密钥可自救而次之。

• 签名与公钥尺寸差异
• 验证速度
• 证书链与握手压力

ECDSA 签名约 64-96 字节、公钥约 32-64 字节；ML-DSA 签名约 2.4-4.6KB、公钥约 1.3-2.6KB；SLH-DSA 签名更大（约 7-49KB）、公钥约 32-64 字节。ML-DSA、SLH-DSA 的签名尺寸显著大于 ECDSA，且验证速度相对较慢。这给证书链与握手带来压力：证书链中多个签名会大幅增加握手报文大小，可能超过 TCP 初始拥塞窗口或 MTU，导致握手延迟、需要分片；TLS 1.3 握手需要更多往返或分片传输。工程上需权衡签名尺寸与安全，选择合适参数并考虑分片、压缩与带宽预算。

PQC 签名的大尺寸是主要工程挑战。证书链与握手报文膨胀会带来带宽、延迟与兼容性压力，需通过分片、参数选择与性能调优应对。

• 协议层的算法标识
• 代码层的抽象与配置
• 避免长度与格式硬编码

crypto-agility 指系统能平滑切换或替换密码算法。协议层：通过版本协商、算法标识符（如 TLS signature_algorithms、cipher suites）、显式算法 ID 字段，使协议不绑定单一算法，长度与格式不硬编码固定值。代码层面：抽象加密接口（密钥、签名、KDF 接口），用配置或策略选择算法，密钥对象携带算法与参数（如 JOSE 的 JWK 带 alg/kty），避免把算法名、密钥长度、签名尺寸写死。测试中要覆盖多种算法组合，确保替换算法时无需改协议与格式。这样当算法被攻破或需升级（如 PQC 迁移）时，只需新增实现与配置，不改协议逻辑。

硬编码的代价是迁移成本高、crypto-agility 差。设计时把"算法选择"与"数据格式"解耦，用元数据描述算法，是实现敏捷性的关键。

• 握手报文尺寸增长
• MTU 与拥塞窗口
• ML-KEM-1024 密文尺寸

PQC 迁移使握手报文显著增大：ML-KEM-1024 的密文约 1568 字节、公钥约 1568 字节，加上 TLS 1.3 握手还包含大签名（ML-DSA）与证书，整个握手报文可能远超 MSS（约 1460 字节）和 TCP 初始拥塞窗口（约 10 个 MSS）。这导致握手需要分片（TLS 记录分片）、增加往返，或在低拥塞窗口下限制传输效率，成为工程瓶颈。ML-KEM-1024 的密文尺寸意味着单一加密结果大于单个 TCP 段，需分片传输，且握手流量占比上升，需调整拥塞窗口、支持分片与压缩。

握手报文膨胀把"带宽问题"变成"传输机制问题"：报文超过 MTU 需分片、超过初始拥塞窗口需多轮。工程上需支持 TLS 分片、增大初始窗口、控制证书链大小。

• extract 的熵提取
• expand 的密钥扩展
• salt/IKM/info 的分工

HKDF（RFC 5869）包含 extract 与 expand 两个阶段。extract 从输入密钥材料 IKM（可能不够均匀或熵不足）提取出均匀的伪随机密钥 PRK，用 salt 作为额外熵源与去相关因子；expand 从 PRK 扩展到任意长度的输出密钥，用 info 提供上下文信息（区分不同用途、协议层、会话阶段），保证不同用途的密钥彼此独立。分工：IKM 是原始密钥材料（如 DH 共享密钥），salt 是可选的非秘密熵源（用于去相关、防弱熵），info 是公开上下文标签（用于密钥隔离与用途绑定）。三者配合使 HKDF 既安全又灵活。

extract 解决"输入熵质量差"的问题，expand 解决"输出多样化与用途隔离"的问题。TLS 1.3 用 HKDF 派生各阶段密钥，正是利用 info 区分不同用途。

• 各 KMS 的密钥分级
• HSM 集成
• 审计能力

AWS KMS 提供信封加密（CMK+DEK 分级）、HSM（FIPS 140-2/3 验证）托管根密钥、IAM 权限控制与 CloudTrail 审计，完全托管、无服务器。GCP KMS 类似，提供 Cloud KMS 与 HSM（Cloud HSM）选项，有 IAM 与 Cloud Audit Logging。HashiCorp Vault 是自托管、开源，提供动态密钥、transit 引擎、密钥分级与可插拔 HSM/Seal 集成，审计日志可自定义，适合复杂多环境与自控需求。对比：托管云 KMS（AWS/GCP）管理简单、HSM 验证、审计深度集成；Vault 更灵活、可自托管、支持动态密钥与多后端，但需自行运维与集成审计。

选择取决于"托管 vs 自控"与"审计/合规"需求。云 KMS 优势是托管与 HSM 合规，Vault 优势是灵活与动态密钥。三者都提供密钥分级与审计，但深度与方式不同。

• zk-SNARK vs zk-STARK
• Trusted Setup vs Transparent
• 工程取舍

zk-SNARK（如 Groth16、Plonk）证明小、验证快，但通常需要可信设置（Trusted Setup，生成公共参考串，若泄露可伪造证明）且依赖椭圆曲线假设；zk-STARK（如 StarkWare）证明大、验证较慢，但无需可信设置（Transparent Setup，只依赖哈希与随机 oracle）、抗量子，且可递归组合。工程边界：SNARK 适合证明小、验证快的场景（如链上验证），但需处理可信设置风险（可用 MPC 生成）；STARK 适合无信任前提、抗量子、证明可并行生成的场景，但证明尺寸大、带宽成本高。选择取决于信任模型、证明大小与验证性能需求。

"可信设置 vs 透明"是安全信任模型的分界：可信设置把信任放在公共参考串的生成过程，透明设置无需该信任。证明尺寸与验证性能是另一维度的权衡。

• PIR 的概念
• 隐私保护原理
• 工程价值与限制

私有信息检索（PIR）允许用户从服务器数据库查询一条记录，而服务器无法得知用户查询了哪一条（查询隐私）。其原理是用户用同态加密或混淆等技术，把查询编码为服务器无法区分的形式，服务器计算后返回结果，用户只能解读自己那条。工程价值：保护用户查询隐私（如医疗、位置、广告、DNS 查询），防止服务器侧画像。但 PIR 计算与通信开销大，工程上常与硬件辅助（如可信执行环境）或批量处理后端结合。它是隐私增强技术（PET）之一，与匿名（如 Tor）互补：匿名隐藏"谁"在查询，PIR 隐藏"查了什么"。

PIR 的价值在于把"查询意图"与服务器隔离，让服务器无法通过查询行为做监督或画像。其代价是计算与带宽，工程上需在小规模或特定场景（如 CDN、DNS）落地。

• HPKP 弃用原因
• 移动端 TLS pinning
• pinned 列表更新

HPKP（HTTP Public Key Pinning）曾用于钉扎服务器公钥，但因其有自身的 DoS 风险（误配置导致用户无法访问）且被弃用。移动应用多用 TLS pinning：在客户端硬编码/配置期望的服务器证书或公钥（或 CA），验证时只接受钉扎的凭据，防止中间人通过其他 CA 签发证书。实现差异：HPKP 是 HTTP 头在服务端下发，pinning 是客户端内置校验。pinned CA 列表更新策略：通过应用内远程配置（如动态下发 pin 集）、灰度发布、设置多个备用 pin、定期轮换公钥并提前发布新 pin，避免因 pin 过期导致用户无法连接。工程上需在安全与可用性间平衡。

HPKP 弃用因自锁风险；移动端 pinning 提供更强抗中间人，但更新困难。更新策略是通过远程配置与多 pin 轮换，避免"钉扎了自己"的可用性事故。

• 告警规则设计
• IAM 紧急收紧
• 处置优先级

检测到 KMS 异常（如暴力枚举、跨区域下载数据密钥）时，应先"止血"再"加固"再"复盘"：最紧急的是立即禁用/吊销异常的访问凭证（key/role/access key），限制被攻击身份的使用权限；其次收紧 IAM 策略（最小权限、限制跨区域、限制来源 IP/VPC、增加条件限制），暂停可疑 API 调用；再启动告警规则升级（对高频失败、异常区域、异常时间设置告警），并审计日志定位影响范围。排序上"阻断访问"优先于"加告警"，因为告警只是监测，阻断才能止损。

处置优先级是"先阻断疑似攻击路径，再收紧策略，最后强化监测与审计"。告警规则应在平时就配置好，异常时要快速触发；紧急收紧 IAM 是控制面动作。

• FIPS 203/204/205 时间表
• CNSA 2.0 时间表
• 商用迁移预期

NIST FIPS 203（ML-KEM）、204（ML-DSA）、205（SLH-DSA）于 2024 年发布正式标准，提供后量子算法标准。NSA CNSA 2.0 给出了明确的迁移时间表：2025 年软件与固件签名、2026 年 TLS 与 DNSSEC 中的 PQC、2030 年前在其它应用（网络设备、VPN、邮件、网页浏览）中排除使用 RSA/ECC 等传统算法，2033 年起国家安防系统（NSS）全面 PQC-only。这给商用系统一个预期：在 2030-2033 年前完成从 RSA/ECC 向后量子算法的迁移，长期系统需在 2025-2026 年就启动 PQC 集成，以符合政府合同与合规要求。

CNSA 2.0 的时间表是"渐进禁用"：先软件签名、再 TLS、再全面 PQC-only。商用系统应把 PQC 迁移纳入路线图，在截止前完成混合到纯 PQC 的过渡。

• 内存约束
• 算力约束
• 带宽与功耗

嵌入式与 IoT 设备通常内存小（KB 级）、算力弱（无硬件加速）、功耗受限、无法升级硬件。PQC 迁移面临：ML-KEM/ML-DSA 的密钥与签名尺寸大（数 KB），占用有限 RAM 与 Flash；后量子运算（格点乘、NTT）计算量大，弱 CPU 上慢，且无 AES-NI/ARM 优化可用；PQC 握手报文大，增加带宽与传输功耗；部分算法（如 SLH-DSA）内存峰值高。约束使这些设备难以直接运行高性能 PQC。工程上需选择节能参数（如 ML-KEM-512）、极致优化、预计算、或由网关/云端代理执行 PQC 运算，设备仅做轻量操作。

PQC 的"大尺寸与高算力"跟嵌入式"小内存弱算力"矛盾。需权衡参数级别、利用硬件加速（如 ARM Crypto Extensions）、或采用代理/边缘计算分担，平衡安全与资源。