AEAD、哈希与 MAC 基础

• 两种 AEAD 的构造与特点
• 硬件加速支持
• 平台适用性

AES-GCM 与 ChaCha20-Poly1305 都是被广泛部署的 AEAD（认证加密）算法，都提供保密性与完整性。AES-GCM 基于 AES 计数器模式 + GHASH，在支持 AES-NI 的 CPU 上硬件加速后性能极佳，是 TLS 1.3 的主流选择；ChaCha20-Poly1305 是软件优化算法，无需 AES-NI，在 ARM、移动端、无硬件加速平台上性能更好且抗侧信道更稳健。工程选型取决于平台：有 AES-NI 的 x86 服务器用 AES-GCM，资源受限或软件平台用 ChaCha20-Poly1305。两者都需注意 nonce 唯一性。

选型核心是"硬件加速可得性 + 平台性能"。工程上，TLS 1.3 同时支持两者，客户端/服务端按能力协商，兼顾性能与兼容性。

• quarter-round 的运算
• 加、旋转、异或
• 软件实现与抗侧信道

ChaCha20 的核心变换是四分之一轮（quarter-round），对状态矩阵中的 4 个 32 位字执行"加、旋转、异或"（ARX）运算：先做两次加与异或、再结合循环移位，最后打乱。多个 quarter-round 组成一轮（round），20 轮构成完整 ChaCha20。其工程意义在于：所有运算都是简单的 32 位整数运算（无查表、无分支），天然适合软件实现且常量时间，抗时序侧信道，同时在无 AES-NI 的平台上性能出色。

quarter-round 的 ARX 结构使 ChaCha20 无 S-box 查表，避免缓存侧信道，且便于 SIMD 并行。工程上，这种设计是"软件友好 + 抗侧信道"的典范。

• HKDF 的 Extract/Expand
• salt 与 info 的作用
• 域分离与随机化

HKDF 分为 Extract（提取）与 Expand（扩展）两步。salt 用于在 Extract 阶段对输入密钥材料做随机化与域分离，防止弱密钥材料与多用途密钥混淆；info 用于在 Expand 阶段区分不同用途的派生密钥（如协议标识、密钥类型），实现上下文绑定。工程价值在于：salt 提升密钥质量、info 防止密钥在不同用途间被复用（域分离），是 TLS 1.3、WireGuard 等协议安全派生密钥的基础。

salt 与 info 是 HKDF 的两大工程安全机制。工程上，常把协议版本、会话 ID、用途名放入 info，确保不同上下文键唯一下派。

• bcrypt 的内存特性
• Argon2 的内存硬性
• 抗 GPU/ASIC 攻击

bcrypt 是 CPU 密集的慢哈希，但内存占用小且有固定结构，容易用 GPU/FPGA 并行加速暴力破解。Argon2 是"内存硬"（memory-hard）函数，其强度取决于内存占用（可配置 m 参数），需大量内存才能并行计算，显著提高 GPU/ASIC 暴力破解成本，且对密码强度更敏感。Argon2 是 PHC（Password Hashing Competition）获胜者，其中 Argon2id 结合了 Argon2i（抗侧信道）与 Argon2d（抗 GPU）的优势，是当前推荐的口令哈希。

内存硬性是"用内存换取抗暴力破解"的演进。工程上，Argon2 通过可调内存/时间/并行参数，使破解成本随内存线性增长，是 bcrypt 之后的主流选择。

• encrypt-then-MAC 的意义
• 三种组合顺序
• 防篡改

encrypt-then-MAC（先加密后认证）指先用 AES-CBC 加密明文，再对密文计算 HMAC。这种顺序是安全的，因为验证方先验证 MAC（认证密文），再解密，篡改的密文会被 MAC 拒绝，且不会对无效密文执行解密（避免 padding oracle）。相比之下，MAC-then-encrypt 与 encrypt-and-MAC 都存在安全隐患。工程上，encrypt-then-MAC 是推荐的组合方式，也是现代 AEAD（如 GCM）的设计思想基础。

encrypt-then-MAC 的边界是"认证在前、解密在后"，防止攻击者利用解密错误信息（padding oracle）进行攻击。工程上，AEAD 已内建此顺序，故新代码优先用 AEAD 而非手工 CBC+HMAC。

• nonce 唯一性
• nonce 复用的灾难
• 并发环境的风险

AES-GCM 要求每个 nonce 与密钥组合必须是唯一的，绝不能复用。若同一密钥下 nonce 复用，攻击者可用两个密文异或推出明文，且能伪造认证标签，导致灾难性失败。96 位 nonce 空间足够大，但随机生成时需注意碰撞概率（生日悖论），在高并发或大量消息场景下有碰撞风险。工程上，推荐用计数器（单调递增）或随机 + 碰撞检测，并避免在并发环境用随机 nonce 而忽略唯一性保证。

nonce 唯一性是 GCM 的第一安全要求。工程上，用显式计数器或保证足够熵的随机 nonce，并在多线程/多进程环境协调 nonce 分配，防止复用。

• SIV 的构造
• 确定性 nonce
• 与 GCM 的对比

AES-GCM-SIV 是 GCM 的"非滥用"（misuse-resistant）变体，它从明文与关联数据计算出一个"合成 IV"（SIV），再用该 IV 加密。即使 nonce 复用，SIV 也不会泄露明文（最多泄露"两条消息相同"这一事实），因此抗 nonce 复用攻击。工程价值在于：在 nonce 可能意外复用的高风险场景（如备份、多副本、日志）中，SIV 提供更强的安全保证。代价是性能略低于 GCM（需先计算 IV）。

SIV 的"合成 IV"使密文成为明文的确定性函数之一，nonce 复用不导致灾难。工程上，SIV 适合无法严格保证 nonce 唯一性的场景。

• 软件实现性能
• 无硬件加速平台
• 抗侧信道

ChaCha20-Poly1305 全部用 ARX（加、旋转、异或）运算，无需 AES-NI 等硬件加速指令，在无 AES-NI 的平台上（如 ARM Cortex、旧 x86、移动端）软件实现性能远优于 AES-GCM。其运算简单、无查表，便于常量时间实现与 SIMD 并行，抗缓存/时序侧信道。工程价值在于：在 IoT、嵌入式、移动设备等缺乏硬件加密的平台上，ChaCha20-Poly1305 是高性能、高安全的选择，也是 TLS 1.3 的推荐算法之一。

ChaCha20-Poly1305 的软件友好性使其成为"无硬件加速"平台的首选。工程上，它常与 AES-GCM 按平台能力协商，确保各平台性能与安全。

• SEP 的独立硬件
• 与主 CPU 的隔离
• 密钥保护

SEP（Secure Enclave Processor）是 Apple 设备中独立于主 CPU 的专用安全芯片，拥有自己的内核、内存、随机数发生器等，与主处理器物理隔离。安全边界在于：即使主 CPU 被攻破，SEP 内的密钥与数据仍受保护，因为攻击者无法直接访问 SEP 的私有内存与密钥。SEP 负责密钥存储、指纹/面容认证、加密等敏感操作，并通过硬件隔离 + 独立固件保证"即使主系统被入侵，SEP 仍安全"。工程价值在于为设备提供硬件级的信任根。

SEP 的安全边界是"物理隔离 + 独立信任根"。工程上，主 CPU 与 SEP 通过安全通道通信，敏感密钥永不离开 SEP，这是移动端安全的核心架构。

• RFC 8439 标准
• ARM 移动端性能
• TLS 1.3 的协商

ChaCha20-Poly1305 由 RFC 8439 标准化，是 TLS 1.3 的推荐 AEAD 之一。在 ARM 移动端，由于无 AES-NI 且 ARMv8 的 SHA/加密扩展覆盖有限，ChaCha20-Poly1305 的软件实现性能显著优于 AES-GCM，因此被广泛用于移动端的 TLS 加密、DNS-over-HTTPS、WireGuard 等。工程价值在于：为 ARM 生态提供高性能、无硬件依赖的认证加密，同时 TLS 1.3 支持按平台能力协商，兼顾性能与兼容。

ChaCha20-Poly1305 在移动端的价值是"软件性能 + 无硬件依赖"。工程上，移动端 TLS 常优先 ChaCha20-Poly1305，服务器端视 AES-NI 情况选择。

• 参数构成
• AES-NI 加速
• TLS 主流

AES-GCM 使用 96 位 nonce（推荐）、128 位认证标签、128 位分组，是 TLS 1.3 的默认 AEAD 之一。在支持 AES-NI 的现代 CPU 上，AES 加解密与 GHASH 都有硬件加速，吞吐可达数十 GB/s，是通用加密性能的标杆。工程价值在于：在 x86 服务器等含 AES-NI 硬件平台，AES-GCM 提供最高效的认证加密，支撑 TLS 的大量数据传输。其 128 位标签提供足够的完整性保证，nonce 用计数器管理。

AES-GCM 的优势是"硬件加速 + 标准成熟"。工程上，AES-NI 使 AES-GCM 成为服务器端加密的首选，通过 GCM 的并行 CTR 模式保持高吞吐。

• X25519 的曲线与实现
• 常量时间与抗侧信道
• TLS 1.3 默认

X25519 是基于 Curve25519 的椭圆曲线 Diffie-Hellman 密钥交换，由 RFC 7748 标准化。它使用 Montgomery 曲线，推荐固定点基实现，运算简单、天然常量时间、抗时序侧信道，且性能出色。在 TLS 1.3 中，X25519 是默认且最常用的 named group，用于握手密钥协商。工程价值在于：其实现简单安全、硬件与软件都高效，且与后量子 ML-KEM 混合（X25519MLKEM768）成为迁移路径。

X25519 的"常量时间 + 简单实现 + 高性能"使其成为 TLS 1.3 首选。工程上，其安全性（无分支、无秘密查表）降低了实现出错风险。

• N/r/p 参数含义
• 内存与时间权衡
• 调优策略

scrypt 是内存硬口令哈希，参数 N（CPU/内存成本，2 的幂）、r（块大小）、p（并行化）共同决定内存占用与时间。内存占用约 128·N·r 字节，工作时长与 N·r·p 相关。调优需在"安全性与性能"间平衡：N 和 r 决定内存硬性（越大越抗 GPU 破解），p 用于并行。工程上，需根据目标硬件内存与延迟预算选择参数，避免内存过大导致拒绝服务，也要保证足够的内存成本以抗专用硬件。常用如 N=2^17、r=8、p=1。

调优核心是"内存硬性 vs 可用性"。工程上，scrypt 需结合具体设备内存与合规要求微调，并注意 N 为 2 的幂、r 与 p 的合理区间。

• universal setup
• 多电路共享
• 可升级性

Plonk 使用通用可信设置（universal setup）：一次可信设置生成的公共参考串（CRS）可被多个不同电路共享，只要电路规模不超过设置的上限。与 Groth16 的每电路设置相比，Plonk 无需为每个新电路重新进行可信设置仪式，从而降低部署成本、支持电路升级与可编程性。工程价值在于：一次设置即可服务一整个应用生态（如 zkEVM、通用的 zk 应用），且新增电路无需重跑仪式。

通用设置是 Plonk 相比 Groth16 的关键优势。工程上，它配合自定义门与多项式承诺，是 zkEVM、Halo2 等主流方案的基础。

• StrongBox 与 TEE 的区别
• 硬件安全元素 vs TEE
• 密钥保护强度

StrongBox 是 Android 设备中的独立安全元素（SE），拥有独立的处理器、内存与安全存储，安全等级高于基于主 CPU 的 TEE（如 Trusty、Titan-M）。TEE 与主 CPU 共享物理硬件，通过隔离环境运行，但攻击者攻破主 CPU 后仍可能影响 TEE；StrongBox 作为独立硬件隔离，密钥永不离开安全元素，抗物理攻击更强。工程价值在于：对高安全需求（如支付、生物认证密钥）用 StrongBox，对一般密钥用 TEE，按安全等级分层。

StrongBox 是"更高隔离的信任根"。工程上，Android 的 Keystore 支持把密钥放入 StrongBox 获得最强保护，而 TEE 提供性能与安全平衡。

• TPM 2.0 session
• salted HMAC 鉴权
• 命令授权与防重放

TPM 2.0 的 session 用于命令授权与数据封装，TPM2_StartAuthSession 创建会话，其中 salted（盐化）HMAC 鉴权用密钥与盐计算 HMAC 验证命令授权，防止重放与中间人篡改。工程价值在于：为 TPM 命令提供强鉴权，确保敏感操作（如密钥使用、NV 写入）需要正确的授权，同时通过会话的随机盐防重放。这是 TPM 远程证明、安全启动与密钥管理的基础。

salted HMAC 鉴权是 TPM 会话安全的核心。工程上，会话绑定授权策略、随机盐与防重放，保证 TPM 操作只能由授权方执行。

• Ed25519 的特性
• 确定性签名
• 广泛部署

Ed25519 是基于 Curve25519 的 EdDSA 签名算法，由 RFC 8032 标准化。它使用确定性 nonce（签名可复现）、天然常量时间、抗侧信道，签名只有 64 字节、验证快，且安全性强。工程价值在于：在 SSH、PGP、JWT/Token 签名、TLS 证书等场景广泛采用，提供简单、安全、高效的签名方案。其确定性 nonce 消除了 RNG 故障导致的私钥泄露风险，是工程上最推荐的签名之一。

Ed25519 的"确定性 + 常量时间 + 高性能"使其成为现代签名首选。工程上，它替代 ECDSA 的随机 nonce 风险，广泛用于认证与签名。

• Halo2 的 Plookup
• custom gates
• Orchard 的应用

Halo2 是 Zcash 于 Orchard 协议中使用的 zk-SNARK 系统，结合 Plookup（查表查找，用于高效证明哈希与查表运算）与自定义门（custom gates，直接表达特定运算如椭圆曲线点加）来降低电路大小、提升证明性能。工程价值在于：通过专门的电路优化，使 Orchard 的隐私交易证明更小、生成更快，同时 Halo2 无需可信设置（递归证明），支持可扩展的隐私支付。它把复杂运算高效编码为电路。

Plookup 与自定义门是 Halo2 提升电路效率的关键。工程上，它们使 Zcash 的交易证明紧凑高效，是"电路级优化"的典范。

• NV 存储
• storage key 与 sealed data
• 持久化信任

TPM 2.0 的 NV 存储（Non-Volatile storage）用于持久化保存密钥、计数器、平台配置等数据。Storage key（存储密钥）是受 TPM 保护的封装密钥，用于加密/解锁其他密钥；sealed data（封印数据）是绑定到特定平台状态（PCR 值）的加密数据，只有平台状态匹配时才能解开。工程价值在于：为密钥与数据提供硬件级持久化保护，构建"硬件根信任"，支撑安全启动、磁盘加密（BitLocker）与远程证明。

NV 存储 + sealed data 是 TPM 的核心信任机制。工程上，sealed data 绑定 PCR 保证"平台未被篡改才可解密"，storage key 层级保护密钥树。

• KeyBag 与 Keychain
• 用户解锁后的密钥释放
• 数据保护

Keychain 是 Apple 系统的密钥/凭证存储，其底层数据由 Secure Enclave 保护。KeyBag（密钥袋）包含用于加密不同数据保护类别的密钥，用户解锁设备后，Secure Enclave 释放相应 KeyBag 数据密钥，使应用能访问已解锁类别的数据。工程价值在于：通过"解锁即释放"的机制，在用户认证后按需解密数据，同时保证锁定状态下密钥不可用、数据不可读，实现"数据保护等级"（如未解锁、解锁后、密钥锁定）的细粒度控制。

KeyBag 机制是 iOS 数据保护的核心。工程上，不同数据保护类别的密钥在解锁时释放、锁定时清除，确保数据只在用户授权后可用。

• getrandom 的特性
• 与 /dev/urandom 的对比
• 初始化与阻塞

Linux getrandom(2) 系统调用是获取随机字节的推荐接口。与 /dev/urandom 相比，getrandom 在系统随机池未初始化时会阻塞（除非设 GRND_NONBLOCK），从而避免"用未初始化熵生成可预测密钥"的安全隐患；且无需打开文件、无文件描述符管理与权限问题。工程价值在于：提供更安全、更简单的 CSPRNG 接口，保证密钥等敏感随机数在熵充分后才生成。工程上，竞态（如 fork 后）与初始化检查也更可靠。

getrandom 的关键是"初始化保证 + 简单接口"。工程上，它消除了 /dev/urandom 在早启动阶段可能返回可预测数据的风险，是安全随机数的首选。

• getentropy 接口
• 用户态实现
• 平台一致性

getentropy(3) 是用户态库函数，用于安全地获取随机字节，在 OpenBSD、glibc（Linux）、macOS 等系统提供一致的接口。它内部封装操作系统随机源（如 getrandom 系统调用），返回失败时不会静默返回弱随机数，保证调用方可据此判断熵源可用性。工程价值在于：让跨平台代码用统一接口获取安全随机数，避免直接操作 /dev/urandom 或自研随机方案的常见错误，提升可移植性与安全性。

getentropy 提供"统一、安全、可诊断"的随机接口。工程上，它常用于密码学库与安全工具，确保随机源可靠且可跨平台。

• nonce 重用的灾难性
• 防御策略
• nonce 管理

AES-GCM 的 nonce 重用在同一密钥下会导致灾难性失败：攻击者可恢复明文并可伪造认证标签。防御策略包括：使用计数器严格保证 nonce 唯一（单调递增）、在并发/多副本环境协调 nonce 分配、用随机 nonce 时检测碰撞并重试、对密钥做轮换限制 nonce 使用量，或在风险场景改用抗误用的 GCM-SIV。工程上，核心是"确保 nonce 永不重复"，并依赖密钥轮换与健壮的 nonce 管理。

nonce 复用是 GCM 最致命的工程风险。工程上，计数器设为并发安全、随机 nonce 结合碰撞检测、密钥按使用量轮换，可显著降低风险。

• 签名延迟
• 确定性 nonce
• RNG 依赖

Ed25519 使用确定性 nonce（由私钥与消息派生），签名可复现、无需随机数生成器，消除了"RNG 故障导致 nonce 泄露、私钥泄露"的经典风险，且签名验证快、实现常量时间。ECDSA-P256 传统上用随机 nonce，若 RNG 弱或 nonce 泄露则私钥可被恢复；虽然现代实现用 RFC 6979 确定性 nonce，但标准不强制。工程边界在于：Ed25519 在确定性、抗 RNG 故障与性能上更优，而 ECDSA-P256 因生态兼容性（如既有的证书、硬件）仍广泛使用。工程上，新系统优先 Ed25519，需兼容旧生态时用 ECDSA-P256。

确定性 nonce 是 Ed25519 的核心工程优势。工程上，它消除了 ECDSA 依赖随机 nonce 的私钥泄露风险，且性能与侧信道更优。

• PCR 0-23 分配
• measured boot
• 信任链

TPM 2.0 的 PCR（平台配置寄存器）0-23 按标准分配用途：PCR 0-3 用于平台固件（BIOS/UEFI）、PCR 4 用于启动管理器、PCR 5-7 用于配置与选项、PCR 8-15 关联启动代码、PCR 16 用于调试、PCR 17-22 用于度量启动的扩展、PCR 23 用于应用。measured boot 在启动时逐级度量（PC 固件、Bootloader、内核、驱动）并扩展 PCR，形成信任链。工程语义是：通过 PCR 值记录"系统被什么启动"，远程证明或 sealed data 可据此判断平台是否可信，防止被篡改的启动。

PCR 分配是"度量日志的标准化"。工程上，measured boot 把度量值扩展进 PCR，后续可用 PCR 值做 sealed data 绑定或远程证明，实现可信启动。

• KeyMaster/HardwareKeymaster
• attestation challenge
• 密钥真实性证明

Android Keystore 的硬件支持（KeyMaster/HardwareKeymaster）能生成密钥证明（attestation），证明密钥确实在硬件安全模块中生成并受保护。attestation challenge 是服务端生成的随机挑战，Keystore 在生成密钥时把 challenge 绑定进证明，证明该密钥是为当前请求（而非重放）生成的。工程价值在于：服务端可验证客户端的密钥确实由受信任硬件生成，用于防重放、设备认证与安全风控，支撑银行、支付等对密钥真实性要求高的场景。

attestation challenge 通过"绑定随机挑战"防重放。工程上，服务端用 challenge + 证明验证密钥真实性，是 Android 硬件密钥认证的核心。

• ECID 与 UID
• 硬件唯一标识
• 防伪认证

SEP 等安全元素拥有唯一的 ECID（芯片唯一标识）与 UID（唯一标识符），这些标识在制造时烧录、不可篡改，还常配合植根于硬件的密钥（HSM 类）使用。工程价值在于：用唯一标识 + 硬件密钥做防伪认证，服务器可验证设备身份真实性，防止伪造/克隆芯片。例如，用 ECID 派生或绑定密钥，确保加密数据只能被特定芯片解密，从而实现"硬件绑定"的防伪与设备认证。

ECID/UID 是"硬件指纹"。工程上，结合硬件密钥与签名证明，可让服务端验证设备真实性与防伪，是硬件安全的信任根之一。

• Titan M 硬件
• StrongBox 集成
• 密钥保护与验证

Pixel 3 及之后的设备使用 Titan M 安全芯片，Android 将其作为 StrongBox 实现的硬件后端。StrongBox 让应用把高敏感密钥（如支付、生物认证、应用密钥）放入 Titan M 中，由独立硬件执行加密操作，密钥永不离开安全元素。工程价值在于：为关键密钥提供独立于主 CPU 的硬件级保护，抗物理攻击与系统逃逸，并支持密钥证明（attestation）供服务端验证。这是 Android 硬件安全的最强级别。

Titan M 作为 StrongBox 后端，把硬件安全与 Android Keystore 集成。工程上，应用声明 StrongBox 需求即可获得独立硬件级密钥保护。

• AEAD 定义
• GCM 的加密与认证
• 关联数据

AES-GCM 是 AEAD（认证加密）算法，同时提供保密性（CTR 计数器模式加密）与完整性/认证（GHASH 计算认证标签）。它还支持关联数据（AAD），即不加密但需认证的头部信息。工程语义是：一次操作同时完成加密与完整性校验，接收方验证标签后即可确定密文与关联数据未被篡改，无需额外的 MAC 组合。这简化了实现、避免加密顺序错误，是 TLS 等现代协议的标准 AEAD。

AEAD 的"加密即认证"简化了安全设计。工程上，GCM 的标签（128 位）验证保证数据完整与来源可信，是现代通信的首选。

• AES-NI 指令
• 吞吐提升
• 应用场景

AES-NI 是 Intel/AMD CPU 提供的硬件加速指令集，支持 AES 加解密（AESENC、AESDEC）与 AES-GCM 需要的运算（如 AESKEYGENASSIST、PCLMULQDQ 用于 GHASH）。相比纯软件 AES，AES-NI 可将吞吐提升数倍到几十倍，达到数十 GB/s，且减少 CPU 负载。工程价值在于：使 AES-GCM 成为服务器端加密的高性能首选，支撑 TLS 大流量、磁盘加密、VPN 等场景。工程上，AES-NI 的存在使 AES-GCM 明显优于 ChaCha20-Poly1305。

AES-NI 是硬件加速的典范。工程上，检测 CPU 是否支持 AES-NI 并选择 AES-GCM，可显著提升加密吞吐，是性能优化关键。

• 三种密钥长度
• 轮数与安全强度
• 性能差异

AES 支持 128、192、256 位密钥长度，对应 10、12、14 轮加密。密钥越长安全强度越高：AES-128 约 128 位安全（当前足够），AES-192 与 AES-256 提供更高安全余量（AES-256 抗量子 Grover 算法约 128 位）。性能上，密钥长度对加解密速度影响很小（轮数略增），主要影响密钥调度。工程上，AES-128 是性价比默认，AES-256 用于高安全合规或长期保密场景。分组始终为 128 位。

安全强度与轮数随密钥增长。工程上，AES-256 因抗量子考虑与合规要求常被选用于长期数据，AES-128 性能相当。

• 各模式的特性
• 安全性
• 适用场景

ECB 对每个分组独立加密，相同明文产生相同密文，泄露模式、不安全。CBC 用前一个密文块链接当前分组，需 IV 与填充，但无认证。CTR 用计数器生成密钥流异或明文，可并行、无填充，但需唯一 nonce 且无认证。GCM 是 CTR + GHASH 认证模式，提供 AEAD。SIV 是抗误用的认证加密，nonce 复用安全。工程上：ECB 应避免，CBC 需配 MAC，CTR/GCM 适合现代应用，SIV 用于 nonce 易复用场景。

差异在于链接方式、认证能力与并行性。工程上，现代代码优先 AEAD（GCM、ChaCha20-Poly1305），避免 ECB/CBC 的认证缺失。

• GHASH 的作用
• GHASH 的串行性
• 并行化优化

GHASH 是 GCM 的认证部分，计算多项式哈希（Galois 域乘法）生成认证标签。GHASH 本质是串行的（每个分组依赖前一个分组的哈希结果），但工程上可通过"多块并行聚合"（如用 PCLMULQDQ 指令把多个块合并成一次多项式乘法）实现并行化，从而大幅提升吞吐。同时，CTR 加密本身可并行。工程价值在于：借助 PCLMULQDQ 等指令，GHASH 与 AES 并行，使 AES-GCM 在 AES-NI 平台上达到高吞吐。

GHASH 的串行性通过"块合并 + 硬件指令"优化。工程上，AES-NI 的 PCLMULQDQ 加速 GHASH 与 AES，是 GCM 高性能的关键。

• nonce 重用的后果
• 明文泄露
• 标签伪造

在 GCM 中，若同一密钥下 nonce 复用，两个密文使用相同密钥流，攻击者将两密文异或即可得到两明文异或（若知其一则得另一），造成明文泄露；更严重的是，两个认证标签可被组合伪造，攻击者能伪造任意密文的合法标签。这是 GCM 的"灾难性失败"（catastrophic failure）。因此 nonce 唯一性是 GCM 的第一安全要求。工程上，必须用计数器或严格管理 nonce，或改用抗误用的 SIV。

灾难性失败源于"同 nonce 同密钥流"。工程上，nonce 管理（计数器、并发协调、密钥轮换）是 GCM 安全部署的底线。

• 标签长度与伪造概率的关系
• 短标签的带宽节省
• 推荐的最短标签长度

GCM 身份认证标签默认 128 位，其伪造成功概率约为 2^(-taglen)。截断标签（如 64 或 32 位）可节省带宽与存储，但直接降低安全性——攻击者伪造概率随位数指数下降。工程上，标签至少应为 96 位（NIST 推荐），低于 64 位基本不安全。取舍在于：带宽受限场景（如 RFID、低功耗）可用短标签换取带宽，但必须接受更高的伪造风险，并配合密钥轮换。工程上应优先保证标签长度，仅在明确评估风险后截断。

标签本质是"认证强度"。截断标签是"用安全换带宽"的权衡，工程上需在安全边界内使用，通常不低于 96 位。

• Argon2id 的特性
• 抗 GPU/ASIC 攻击
• 参数选择

Argon2id 是 Argon2 的混合变体（兼具 Argon2i 的数据无关与 Argon2d 的数据相关），是 PHC（Password Hashing Competition）获胜算法，也是 OWASP 推荐的口令哈希首选。它通过控制内存（memory）、时间（iterations）与并行度（lanes）来抵抗 GPU/ASIC 暴力破解与模拟攻击。工程上，Argon2id 用于口令存储（如 /etc/shadow、登录系统），需为密码哈希选择合适参数（内存 64MB+、时间 3、并行 4），并配合随机盐。其内存硬特性使其难以被廉价硬件加速。

Argon2id 的工程价值在于"内存硬 + 抗并行"，把暴力破解成本提高到硬件难以承受。工程上需权衡内存与延迟，服务器内存需余量。

• Extract 阶段
• Expand 阶段
• 盐与信息的作用

HKDF 由两步组成：Extract（提取）用 HMAC 与盐（salt）把输入密钥材料（IKM）压缩成固定长度的伪随机密钥（PRK）；Expand（扩展）用 PRK 与信息（info）派生任意长度的多段密钥。工程上，Extract 负责"提取熵、消除输入中的弱熵与结构"，Expand 负责"按需生成多个独立密钥"。这种两步分离使 HKDF 能处理任意来源的输入熵（如 DH 共享、口令），并在 TLS 1.3、Noise 等协议中统一定义密钥派生。

Extract+Expand 是"先提纯、再扩展"的经典模式。工程上，salt 提供域分离与熵补充，info 允许为不同上下文的密钥生成独立密钥。

• Argon2i/d/id 的区别
• 内存、时间、并行参数
• 抗侧信道与暴力破解

Argon2 有三种变体：Argon2i（数据无关，抗侧信道时序攻击，适合无秘密输入的场景）、Argon2d（数据相关，抗时间-内存权衡攻击，但可能受侧信道影响）、Argon2id（混合，先数据无关后数据相关，平衡两者）。参数包括内存 m（如 64MB）、时间 t（迭代次数，如 3）、并行度 p（lane 数，如 4）。调优原则：内存要大（抵抗 GPU/ASIC 并行）、时间适中（控制延迟）、并行根据多核平衡。工程上选 Argon2id 并配置足够内存与时间以满足安全目标。

参数是"成本-延迟"的权衡。工程上，内存是抗 ASIC 的关键，时间控制 CPU 成本，并行度匹配多核。Argon2id 是默认推荐。

• 迭代次数与暴力破解
• 迭代次数的选值
• 相对内存硬方案的局限

PBKDF2 通过重复执行 HMAC（迭代次数）来增加口令哈希的计算成本，迭代次数越高，单次暴力猜测越慢。工程上，迭代次数应足够高（OWASP 推荐 SHA-256 时 ≥ 600000 次），以抵消 GPU 并行加速。但 PBKDF2 是"计算密集"而非"内存硬"，GPU/ASIC 可快速并行处理，因此同等安全目标下需更高迭代次数。工程上，PBKDF2 实现简单、兼容性好，但推荐改用 Argon2/scrypt 等内存硬方案，或结合 PBKDF2 与高迭代。

迭代次数是 PBKDF2 唯一的"成本旋钮"。工程上，需根据硬件性能与安全目标动态调整，并注意 CPU 负载与用户体验平衡。

• 内存硬的定义
• 抗 GPU/ASIC 扩增
• 参数 N/r/p

scrypt 是内存硬（memory-hard）的密钥派生函数，通过反复填充与读取大块内存（用参数 N 控制的伪随机序列）使计算需要大量内存，从而抵抗 GPU/ASIC 的并行加速——因为内存成本无法像计算那样并行摊薄。其参数 N（CPU/内存成本）、r（块大小）、p（并行化）决定内存与计算开销。工程价值在于：提高暴力破解的硬件成本，使大规模口令猜测不经济。scrypt 常用于口令哈希与加密密钥派生。

内存硬的核心是"内存带宽瓶颈"。工程上，scrypt 需设置足够大的 N 使内存占用超出 GPU 显存，同时参数需在服务器内存与延迟间权衡。

• TLS 1.3 的密钥调度
• Noise 的加密握手
• HKDF 的 Extract/Expand

HKDF 在 TLS 1.3 中用于密钥调度：从握手共享秘密（IKM）经 HKDF-Extract 提取主密钥，再经 HKDF-Expand 派生握手密钥、应用流量密钥等，并通过 info 区分各阶段。Noise Protocol 用 HKDF 从握手过程中的共享密钥提取并派生后续加密密钥，每个握手消息推进密钥状态。两者都依赖 HKDF 的"提取熵 + 扩展密钥"能力，以实现前向安全、密钥分离与多阶段密钥派生。工程上，HKDF 是这些协议密钥管理的统一基础。

HKDF 的核心价值是"把共享秘密变成结构化、上下文相关的多段密钥"。工程上，info 参数实现域分离，避免不同用途密钥复用。

• 两种 KDF 的来源
• 提取 vs 扩展
• 合规场景选择

HKDF（RFC 5869）是通用的 Extract+Expand KDF，面向"输入熵可能不均匀"的场景（如 DH 共享、口令），先提取再扩展。SP 800-108（NIST）是 Counter Mode KDF，直接对已提取的密钥（Key + Label + Context）做 PRF 迭代扩展，基于 CMAC/HMAC 计数器模式，用于从已均匀的秘密生成派生密钥。合规差异：SP 800-108 是 NIST 标准、适合已提取密钥的合规派生；HKDF 更通用、适合协议级提取。工程上，两者可结合：HKDF 提取、SP 800-108 扩展，以满足不同合规要求。

差异核心是"提取与否"。工程上，若输入已有足够熵（如已提取的密钥），用 SP 800-108；若输入熵不确定（如 DH、口令），用 HKDF 或先提取。

• 长度扩展攻击的原理
• HMAC 的双层填充
• 密钥不在消息内的设计

裸的 H(k‖m) 在 Merkle-Damgård 哈希（如 SHA-256）下易受长度扩展攻击：攻击者无需知道 k 即可从 H(k‖m) 计算 H(k‖m‖padding‖x)，从而在已知 m 和 k‖m 的摘要时伪造扩展消息的摘要，破坏认证。HMAC 用内外两层填充：先对 k 与 ipad 异或得到内层，把 m 放入内层哈希，再对 k 与 opad 异或得到外层哈希。这样密钥被分别置于内层与外层的首部，且内层哈希结果作为外层消息，形成"密钥包裹"结构，使长度扩展无法作用，同时满足底层压缩函数为 PRF 时 HMAC 是安全 MAC。工程上，HMAC 是消息认证的标准选择。

HMAC 的双层结构使攻击者无法在不破坏内层哈希的情况下计算扩展消息，且密钥不直接暴露在消息中。工程上，HMAC 是 TLS、JWT、API 认证的基石。

• SHAttered 的碰撞
• Chosen-prefix 碰撞
• Git 与 TLS 证书的影响

SHAttered（2017，Google 与 CWI）展示了两个不同 PDF 的 SHA-1 碰撞，表明 SHA-1 抗碰撞性已被打破。chosen-prefix 碰撞（preimage 可控前缀）使攻击者能构造两个有不同前缀但相同 SHA-1 的文档，可用于伪造 TLS 证书（如攻击 CA 的证书签名）。对 Git：内容寻址用 SHA-1 作为对象标识，碰撞可导致两个不同提交指向同一对象，造成仓库完整性混淆（Git 已迁移到 SHA-256 或采用 SHA-1 变体）。对 TLS 证书：碰撞可让攻击者构造两个相同 SHA-1 证书（一个合法、一个恶意），破坏证书信任。工程上已弃用 SHA-1 的签名与证书。

影响取决于"碰撞是否带来实际危害"。Git 的威胁是内容寻址混淆，TLS 的威胁是证书伪造。工程上，需迁移到 SHA-256/384 并弃用 SHA-1 签名。

• sponge 结构
• 抗长度扩展
• 可扩展输出

Keccak 采用 sponge（海绵）结构：吸收阶段把消息按块吸收进状态，挤压阶段输出任意长度的哈希。由于状态比特是"压缩"的且输出基于状态挤压，长度扩展攻击（针对 Merkle-Damgård 的拼接）无法直接作用——因为输出包含状态内部更多信息，且 padding 与速率设计避免扩展。结构灵活性上，sponge 天然支持可变长输出（可当 XOF）、可调安全参数（rate/capacity），并衍生出 cSHAKE、KMAC、TupleHash 等。工程上，SHA-3 适合需要抗长度扩展与可变输出的场景。

sponge 的优势是"单结构多用途 + 抗长度扩展"。工程上，SHA-3 的 rate/capacity 权衡、XOF 输出使它在需要可扩展输出的协议中更灵活。

• 三种性质的强弱
• 生日攻击
• 安全强度

抗原像（preimage resistance）：给定哈希值 y，找到 x 使 H(x)=y 困难，需 2^n 次。抗第二原像（second preimage）：给定 x，找到 x'≠x 使 H(x')=H(x) 困难，也需 2^n 次。抗碰撞（collision resistance）：找到任意 x≠x' 使 H(x)=H(x') 困难，只需 2^(n/2) 次（生日界）。生日界源于"找任意两个碰撞"的随机碰撞概率：约抽取 2^(n/2) 个值就有较高概率出现碰撞。因此碰撞安全强度是 n/2，而原像/第二原像是 n。工程上，128 位输出（如 MD5）的碰撞安全仅 64 位，已不满足要求。

三者强弱关系：抗碰撞最难，蕴含抗第二原像；抗第二原像蕴含抗原像（在常见情形）。工程上，安全等级按最弱需求设置，碰撞安全需 n/2 位强度。

• Merkle-Damgård 结构
• 长度扩展攻击原理
• 密钥前缀 MAC 的脆弱

Merkle-Damgård 结构把消息分成块，逐块用压缩函数 f(chain, block) 更新链状态，初始链为固定 IV，输出最终链状态。若用 H(k‖m) 做 MAC，攻击者知道 H(k‖m)（即内部链状态）后，可继续把攻击数据 x 作为新块送入压缩函数，得到 H(k‖m‖padding‖x)，无需知道 k。这是因为哈希输出直接暴露了内部状态，且 padding 可被预测。因此带密钥前缀的朴素 MAC 在 MD 结构下不安全。工程上，需用 HMAC 或抗长度扩展的哈希规避。

长度扩展源于"输出即内部状态 + 可预测 padding"。工程上，HMAC 通过双层包裹规避，SHA-3 sponge 通过构造规避。

• 密钥前缀的扩展攻击
• 密钥后缀的碰撞/选择前缀
• HMAC 的规避

直接对密钥拼接消息做哈希（如 H(k‖m) 或 H(m‖k)）作为 MAC 不安全。H(k‖m)（密钥前缀）在 MD 结构下受长度扩展攻击，可伪造扩展消息。H(m‖k)（密钥后缀）若底层哈希可碰撞或受 chosen-prefix 攻击，攻击者可构造两个相同哈希的消息，导致认证混淆；且密钥位置固定，可能被 Merkle 结构攻击。HMAC 用内外双层填充分离密钥与消息，规避了这两种风险，且在底层压缩函数为 PRF 时被证明是安全 MAC。工程上，HMAC 是标准做法。

"拼接后哈希"看似简单实则脆弱。工程上，任何直接拼接哈希的 MAC 都应用 HMAC 替代，以规避结构攻击。

• PRF 假设
• 可证明安全
• 双层结构

HMAC 的安全性可归约到"底层压缩函数是 PRF"的假设。在该假设下，内层 H((k⊕ipad)‖m) 把消息 m 映射为伪随机输出，外层 H((k⊕opad)‖·) 则把内层输出作为消息再映射，整个 HMAC 成为一个 PRF。由于 PRF 在计算上不可区分于随机函数，攻击者无法区分 HMAC 输出与随机值，也就无法伪造有效 MAC。工程上，SHA-256 的压缩函数被广泛视为 PRF，因此 HMAC-SHA256 是安全 MAC。这为 HMAC 提供了可证明的安全基础。

可证明安全的逻辑是"假设 PRF，则 HMAC 是 PRF 因而安全"。工程上，信任底层哈希的 PRF 性质（如 SHA-256）即可信任 HMAC。

• 碰撞 vs 密钥安全
• HMAC 的 PRF 性质
• 第二原像/原像安全

被弃用的是 SHA-1 的"抗碰撞"性质（约 2^63 次即可碰撞）。但 HMAC-SHA1 的安全性依赖的是"密钥前缀下的 PRF 性质"，而非抗碰撞。攻击者无法在没有密钥的情况下获得 HMAC 的查询预言机，因此无法利用公开的碰撞。即使可构造碰撞，HMAC 的双层结构使碰撞无法直接转化为密钥恢复或 MAC 伪造。因此 HMAC-SHA1 在未发现密钥相关攻击的前提下仍被认为可用（如 TLS 1.2 的 HMAC-SHA1）。但工程上仍建议逐步迁移到 HMAC-SHA256 以更保守。

区别在"公开碰撞 vs 密钥化认证"。工程上，HMAC-SHA1 的可用性基于其 PRF 性质未受攻击，但长期趋势仍迁移到更强的哈希。

• 字长与轮数
• 64 位平台的运算
• 压缩比

SHA-256 使用 32 位字、64 轮压缩，输出 256 位；SHA-512 使用 64 位字、80 轮压缩，输出 512 位。在 64 位平台上，SHA-512 的 64 位运算用 CPU 原生指令高效执行，而 SHA-256 的 32 位运算在 64 位寄存器上需额外处理，且 SHA-512 每次处理 128 字节块（比 SHA-256 的 64 字节块多），压缩比更高、每字节所需的轮数摊薄。因此对长消息，SHA-512 在 64 位平台上可能比 SHA-256 更快。这是 SHA-512 的"每字节开销更低"优势。

差异源于"字长匹配平台 + 块大小"。工程上，SHA-512 在 64 位平台处理长数据时吞吐更高，但输出更长。

• MD 的输出即状态
• sponge 的构造
• 抗扩展的根本原因

SHA-2 的 MD 结构输出就是压缩函数的最终链状态，且 padding 可预测，攻击者可从 H(k‖m) 继续送入新块得到 H(k‖m‖padding‖x)，因此存在长度扩展。SHA-3 的 sponge 结构在吸收后挤压输出，输出经过状态变换并可能包含更多内部信息，且 padding 与速率设计使攻击者无法从输出推导可继续扩展的状态；更根本的是，其输出与内部状态的关系不可倒推，无法从输出继续注入数据。因此 SHA-3 天然抗长度扩展。工程上，SHA-3 在需防扩展的上下文（如 MAC 构造）中更直接安全。

根本区别是"输出是否可逆地暴露内部状态"。工程上，SHA-3 免去 HMAC 的额外双层也能抗扩展，但 HMAC 仍可用于统一。

• Merkle 树证明
• 认证路径
• CT 日志的可审计性

Merkle 树把叶子（数据哈希）逐层两两哈希到根，根即为整棵树摘要。证明某条叶子属于树：提供从该叶子到根路径上的兄弟节点哈希（认证路径），验证者用这些哈希逐层重算根，与公布的根比对即可，只需 O(log n) 个哈希。证书透明（CT）日志用 Merkle 树维护所有证书的哈希，提供"包含证明"（证明某证书已在日志中）与"一致性证明"（证明日志未违规回溯），使任何人可审计日志的完整性而无需信任日志服务器。工程价值在于日志的可验证、可审计与不可篡改。

Merkle 树的优雅在于"对数级证明 + 单一根摘要"。工程上，CT 的 SCT（签名证书时间戳）与 STH（树头）依赖 Merkle 证明实现公开可审计。

• 盐与彩虹表
• 慢哈希与暴力破解
• 防御层次

盐（salt）是随机化哈希的输入，使每个口令的哈希都不同，从而抵御"彩虹表"（预计算口令哈希表）与"相同口令相同哈希"的跨用户攻击——攻击者无法用预计算表直接匹配。慢哈希（bcrypt/scrypt/Argon2）提高单次哈希计算成本，抵御"暴力破解与字典攻击"——即使攻击者拿到盐和哈希，逐个猜测口令的成本也极高。两者互补：盐消除预计算优势，慢哈希提高在线/离线猜测成本。工程上两者必须同时使用。

盐针对"预计算/批量"攻击，慢哈希针对"逐个猜测"攻击。工程上，口令存储标准是"随机盐 + 慢哈希 + 足够参数"。

• Keccak 的 XOF
• cSHAKE 的域分离
• KMAC/TupleHash 的用途

SP 800-185 定义了基于 Keccak 的派生函数：cSHAKE 是 SHAKE（XOF）的可定制化版本，通过函数名（function name）与自定义字符串（customization）实现"域分离"，使不同用途的派生互不干扰；KMAC 用 cSHAKE 构造键控 MAC，支持可变长输出；TupleHash 用 cSHAKE 对多个字符串（tuple）做哈希，提供结构化哈希。这些函数利用 Keccak sponge 的可变长输出与域分离能力，实现比标准哈希更灵活、可扩展的密码原语。工程价值在于：单一底层即可实现 MAC、哈希、派生密钥等多种用途。

域分离是防"跨用途"攻击的关键。工程上，cSHAKE 的参数化使不同协议/上下文使用不同派生，避免密钥复用。

• 蕴含关系
• 生日界
• 128 位输出

蕴含关系：抗碰撞蕴含抗第二原像（若不能找任意碰撞，更不能找指定的第二原像），抗第二原像通常蕴含抗原像（在常见情形）。因此抗碰撞是三者中最强的性质。生日界：找任意碰撞约需 2^(n/2) 次，所以 n 位输出的碰撞安全强度是 n/2。若 n=128，则碰撞安全仅 64 位，远低于现代安全要求（128 位）。因此 128 位输出（如 MD5）的碰撞安全不达标，现代最低要求 256 位输出（碰撞安全 128 位）。工程上，输出长度决定碰撞安全等级。

生日界把"碰撞安全强度"减半。工程上，128 位哈希（MD5、SHA-1 的 160 位）碰撞安全不足，标准用 SHA-256/384 等。

• HMAC 与 KMAC
• AEAD 的认证
• 适用边界

HMAC 是基于哈希的独立 MAC，密钥独立于加密，用于"仅认证"或"加密后认证"（如 Encrypt-then-MAC），与加密方案解耦。KMAC 基于 Keccak 的键控 MAC，提供域分离与可变长输出，适合需要统一 MAC 原语的场景。AEAD 的认证子密钥（如 GCM 的 GHASH 密钥）内嵌于加解密流程，一次性提供"加密 + 完整性认证"，密钥与加密强制绑定，适合需要同时机密与认证的传输。分工上：HMAC/KMAC 用于独立认证（如 API 签名、协商），AEAD 用于加密通信的认证。工程上按"是否需要与加密绑定"选择。

区别在"认证是否与加密耦合"。工程上，HMAC 用于纯认证或独立 MAC，AEAD 用于加密传输的端到端认证。

• RDP 的定义
• 隐私会计
• 组合分析

RDP（Rényi 差分隐私）通过 Rényi 散度量化隐私损失，其 accountant（隐私会计）可在多次查询/训练轮次下累计隐私预算。相比经典 (ε,δ)-DP 的强组合，RDP 提供更紧的复合界，支持 DP-SGD 训练中每轮加噪后的累计 ε 分析。TensorFlow Privacy 与 PRIME 等库使用 RDP accountant 精确计算训练多轮后的隐私预算，使 (ε,δ)-DP 保证可量化、可审计。工程价值在于：用更紧的界支撑更多训练轮次，同时保持可证明的隐私保证。

RDP accountant 的工程价值是"更紧的隐私预算估计"。工程上，DP-SGD 训练配合 RDP 累计可给出可信的 (ε,δ) 声明。

• CSPRNG 的种子
• 硬件熵源
• fork 后的重播种

基于 ChaCha20 的 CSPRNG（如 Linux 的 getrandom、DRBG）用少量高质量熵（种子）派生大量伪随机输出。种子来源包括 CPU 指令 RDRAND/RDSEED（硬件熵源）与系统熵池。工程价值：RDRAND/RDSEED 提供硬件真随机种子，增强 CSPRNG 的熵；fork 后子进程会继承父进程的 CSPRNG 状态，若不复播种，父子进程可能产生相同随机序列，导致密钥重复（安全灾难）。因此 fork 后必须重新播种（re-seed），确保子进程有独立随机状态。工程上，这是密钥生成的准确性与安全性关键。

seed 决定 CSPRNG 的熵，re-seed 保证进程私密。工程上，fork 后重播种、定期混合新熵是安全随机生成的标准实践。

• AEAD 的原子认证
• EtM 的分离
• 安全与实现

AEAD（如 AES-GCM）把加密与认证绑定为一个原子操作，输出密文与认证标签，由同一算法、同一密钥（经派生）处理，保证"改动任意密文即触发标签校验失败"。Encrypt-then-MAC（EtM）是组合方法：先加密，再用独立 MAC（如 HMAC）对密文做认证，将加密与认证分离。工程差异：AEAD 更简单、原子、无中间态、标准实现（如 TLS 1.3 用 AEAD），防"unauthenticated decryption"漏洞；EtM 灵活可控、可独立选择加密与 MAC，但需正确组合（先认证后解密）避免漏洞。工程上，AEAD 是首选，EtM 用于需自定义组合的场景。

关键差异是"原子 vs 分离"。工程上，AEAD 避免"先解密后认证"的经典漏洞，是 TLS 1.3 的标准。

• cost factor
• 迭代轮数
• 参数调优

bcrypt 的 cost factor（成本因子）是 2 的指数，表示内部 Blowfish 密钥扩展的迭代轮数（如 cost=12 表示 4096 轮）。cost 越高，单次哈希计算越慢，暴力破解成本越高。工程价值在于：cost 是 bcrypt 的"难度旋钮"，可按硬件性能与安全目标调整，使口令哈希在"可用性（用户等待时间）"与"安全性（抗暴力破解）"之间平衡。工程上，OWASP 推荐 cost ≥ 10（约 100ms 目标），随硬件升级逐年提高。

cost 直接控制计算成本。工程上，需在安全与用户体验间权衡，并随硬件迭代上调 cost。

• 侧信道特性
• 抗 GPU/ASIC
• 参数与实现

Argon2id 采用混合数据无关/相关访问，通过数据无关的初始阶段抵抗时序侧信道，同时用内存硬抵抗 GPU/ASIC；scrypt 的数据访问依赖数据（data-dependent），在特定攻击下可能受时序侧信道影响，但内存硬特性同样抗 GPU。工程取舍：Argon2id 是 PHC 获胜者、OWASP 推荐，对侧信道更稳健、参数更现代；scrypt 曾广泛使用（如加密货币、各系统），实现成熟但参数调优复杂。GPU 友好性上，两者都内存硬、不被 GPU 并行加速，但 Argon2id 的多 lane 并行在 CPU 上更高效。工程上优先 Argon2id。

取舍在"侧信道稳健性 vs 生态成熟度"。工程上，Argon2id 兼顾数据无关（抗侧信道）与内存硬（抗 GPU），是更优选择。

• HPKE 的 mode
• 认证与 PSK
• 应用场景

HPKE（RFC 9180）提供四种模式（base、psk、auth、psk-auth）：base 模式无认证，客户端用服务器公钥加密，适合匿名加密；psk 模式附加预共享密钥（PSK）作为认证，适合双方已有共享密钥；auth 模式由客户端认证（用客户端私钥），服务器可验证发送者身份；psk-auth 模式同时使用 PSK 与客户端认证。工程语义上，mode 决定"认证强度"与"密钥来源"：base 最简、psk 用于共享密钥、auth 用于身份认证、psk-auth 最强。工程上按威胁模型选择模式。

mode 是 HPKE 的"信任模型开关"。工程上，base 用于公开加密，auth 用于身份绑定，psk/psk-auth 用于预共享密钥场景。

• MLS 的密钥协商
• 树状组密钥
• HPKE 的角色

MLS（RFC 9420）是端到端加密的消息协议，用于组消息（如群聊）。HPKE 在 MLS 中用于"树状密钥协商"（KEM-based tree，KAT）：在 Ratchet Tree 中，每个成员用 HPKE 的 KEM 封装自己的密钥，父节点用 HPKE 组合子节点密钥，最终形成组共享密钥。HPKE 提供标准化的 KEM（如 X25519、ML-KEM）与对称派生，使 MLS 的密钥更新（add/remove 成员）高效且前向安全。工程价值在于：HPKE 统一了 MLS 的密钥封装与派生，支持成员变更时的组密钥更新。

HPKE 是 MLS 密钥协商的底层原语。工程上，MLS 用 HPKE 的 KEM 与哈希实现 Ratchet Tree 的密钥更新，实现前向/后向安全。

• 内容寻址
• 持久化引用
• 迁移成本

在区块链与版本控制中，哈希被持久化为内容寻址标识（如 Git 的 commit/blob 哈希、区块链的区块/交易哈希、Iceberg 的 manifest 哈希）。一旦哈希算法被攻破，迁移成本来自：所有历史对象/区块的哈希引用（链内嵌、数据库键、签名、索引）都需要重新计算与更新；链上/账本中的哈希不可变，需硬分叉或迁移协议；外部系统（签名、证书、依赖）引用的哈希需同步；以及双重验证、兼容性、归档数据的不可变性。这些持久化引用使"换哈希"成为全系统迁移，而非简单替换。工程上需提前规划算法迁移与双重哈希（如 Git 的 SHA-256 迁移、链的双哈希）。

内容寻址的"不可变引用"既是优势也是迁移陷阱。工程上，双哈希、迁移映射与兼容层是缓解手段。

• 自研哈希的风险
• PHC 获胜算法
• 审计与最佳实践

自研加盐拼接（如 salt + password 后用裸哈希）存在多种风险：可能使用弱哈希（如 MD5/SHA-1）、错误拼接、盐太短、无慢哈希、被长度扩展/时序攻击利用，且未经密码学审计。PHC 获胜算法（Argon2）及其经过审计的实现（如 libsodium、OWASP 推荐）已经过大量研究与场景验证，提供正确的盐、内存硬、参数化与抗 GPU 特性。选用审计实现避免"自己发明密码学"的常见漏洞，确保安全性建立在成熟标准上。工程上，口令哈希应使用 Argon2id 等 PHC 标准实现。

"不要自创密码学"是工程铁律。工程上，用库的实现（如 libsodium）避免手写哈希与拼接。

• BLAKE2/BLAKE3 的优化
• 软件实现速度
• 树形并行

BLAKE2/BLAKE3 基于 ARX（加法、旋转、异或）运算，无需查表且可充分利用现代 CPU 的向量指令（如 AVX2/AVX-512），而 SHA-256 的运算不利于向量化与并行。BLAKE3 在 BLAKE2 基础上采用 Merkle 树的树形结构，可对多个数据块并行哈希（多线程），并支持流式（XOF）、keyed 与上下文分离。这种树形并行带来额外能力：极高吞吐（多核可并行）、可验证的部分哈希、以及作为 PRF/MAC 的灵活性。工程上，BLAKE3 在软件性能上远超 SHA-256，适合高性能哈希需求。

ARX + 向量化 + 树形并行是 BLAKE3 的性能来源。工程上，BLAKE3 适合高性能内容寻址、文件哈希等，但标准化上 SHA-256/SHA-3 更通用。