YoloMultiHash
在Trail of Bits的审计工作中，YoloMultiHash是最常见的危险构造。当客户需要处理复杂数据结构或值数组时，常误用这种构造来实现Fiat-Shamir转录。
错误构造
给定哈希函数H和消息集合M̂ = {M1,M2,…,Mn}，选择分隔符S，计算YoloMultiHash(M̂) = H(M1‖S‖M2‖S‖…‖S‖Mn)。
致命缺陷
核心问题在于编码模糊性。若消息Mi包含分隔符S，可将Mi拆分为M′i‖S‖M′′i，此时不同语义的输入M̂和M̃会产生相同哈希值，直接破坏哈希函数的抗碰撞性。该漏洞已被实际利用攻陷多个主流库。
正确方案
- 采用专为多值哈希设计的TupleHash（SP800-185标准）
- 或使用BLAKE3的"状态化哈希对象"特性
- 结构化数据推荐Protocol Buffers/CBOR/BCS等无损序列化格式（注意JSON可能因空格/元素顺序导致哈希不一致）
YoloMAC
错误构造
给定密钥K和消息M，计算YoloMAC(K,M) = H(K‖M)，有时会加入盐值S变为H(K‖S‖M)。
双重漏洞
- 长度扩展攻击：对于SHA256等Merkle-Damgård结构哈希，攻击者可在未知K的情况下构造有效YoloMAC(K,M‖X)
- 编码模糊性：即使使用SHA3/BLAKE3仍存在风险。例如256位密钥K=K1‖K2时，YoloMAC(K1,K2‖M)会与YoloMAC(K,M)产生相同MAC值，导致密钥/消息对的可否认性攻击（类似AES-GCM标签漏洞）
特别警告
Keccak官网虽声明"可直接将密钥前置作为MAC"，但未明确密钥长度/格式要求，实际应用中仍存在风险。
正确方案
- SHA2家族：必须使用HMAC（Python标准库已内置）
- SHA3家族：优先选择KMAC（支持XOF模式、输出长度绑定等特性）
- BLAKE2/3：直接使用内置密钥哈希模式
YoloPBKDF
错误构造
给定密码P和盐值S，计算K = H(S‖P)或迭代版本Ki = H(S‖Ki-1)。
灾难性缺陷
- GPU集群可实现每秒千亿次破解尝试
- 防御成本呈线性增长：用户若将迭代次数增加10倍，攻击者仅需多投入10倍资源
- 完全无法抵抗彩虹表、时空权衡等经典攻击手段
内存硬函数优势
以Argon2d的64MB内存需求为例：
- 合法用户仅消耗0.8%内存（8GB设备）
- 攻击者若想实现每秒百万次尝试，需每秒处理64TB数据
正确方案
- 首选Argon2/scrypt等内存硬函数
- FIPS合规场景可采用PBKDF2+HKDF组合方案（需注意PBKDF2非内存硬特性）
核心建议
- 拒绝重复造轮子：BLAKE3原生支持密钥哈希/MAC，SHA3库普遍实现KMAC/TupleHash
- 参数化设计：密钥长度、消息格式等细节必须严格规范
- 资源权衡：密码学方案选择应使合法用户操作成本远低于攻击成本
密码学领域有句名言：“设计自己的加密协议就像设计自己的降落伞——你尽可以尝试，但千万别在第一次试跳时就用它。”