自从《隐形蝾螈》论文发表以来，应用密码学领域的朋友和同事们悄然兴起了对使用带关联数据的认证加密（AEAD）构造系统的研究热潮，他们在理解这些系统对所基于的 AEAD 模式的保证所做的隐含假设，以及这些假设为假时的后果。

在博客中多次讨论了《隐形蝾螈》，从对AES-GCM和XMPP + OMEMO的批评，到在Threema中的漏洞披露。

《隐形蝾螈》发表五年后，作者发现许多软件开发人员并没有充分理解该论文中讨论的潜在问题，即使分享了简单的概念验证漏洞利用。

背景

基于多项式 MAC 的快速 AEAD 构造旨在为双方已协商一个共享对称密钥的系统中的明文数据提供机密性和完整性，以及可选的一些附加关联数据的完整性。采用这些 AEAD 构造的系统的完整性目标通常伴随着性能目标——通常是为了防止网络协议中的拒绝服务（DoS）攻击。验证需要非常快速且消耗最少的资源。AEAD 构造取得了巨大成功，但存在双方已就协议中使用的一个对称密钥达成一致的微小假设问题。

快速 MAC 不是密钥承诺：基于多项式 MAC 的 AEAD 构造往往做出相同假设，即使是像 AES-GCM-SIV 这样的抗误用模式和 XSalsa20-Poly1305 这样的扩展随机数构造也是如此。当讨论使用这些 AEAD 模式的系统中的只有一个有效密钥的隐含假设时，称这些模式不是密钥承诺的，因为可以用单个特制密文（带有认证标签）在多个不同密钥下解密，认证标签对所有密钥都有效，而明文不同。

实际中的表现：如作者的 GCM 漏洞利用，通过生成两个密钥，用它们分别加密明文块，计算碰撞块，返回密文和认证标签，在不同密钥下解密会得到不同的明文和垃圾数据，对于某些文件格式不是问题，还可通过预计算选择更有利的垃圾数据。《隐形蝾螈》论文还概述了更高级的变体（有概念验证）。之所以叫《隐形蝾螈》是因为论文中的概念验证涉及通过端到端加密消息应用发送一张蝾螈图片，接收者标记为滥用时，版主看到不同图片，选择“蝾螈”可能是受 Signal Protocol 原名“Axolotl”启发。

违反“一个密钥”假设的后果：取决于系统的功能，在《面向我们其他人的数据库密码学》中讨论了 AEAD 模式用于防止[混淆代理攻击]，但在支持多租户时需重新考虑，OPAQUE 的早期设计因基于非密钥承诺的 AEAD 模式而被分区预言机攻击破解，这表明相同弱点有不同影响。

他们不理解

《隐形蝾螈》问题在使用对称密钥加密且多个密钥可能有效的任何系统中都相关，包括多租户数据仓库、群组消息协议、带有多个包装密钥的信封加密方案、使用密钥 ID 的承载令牌等系统。可通过引入显式密钥承诺方案或使用承诺密码模式来缓解此问题，但大多时候这些建议未被重视。常见误解是没有报告滥用功能就不受影响，还举例说明了在数据丢失预防产品中的攻击场景，强调了隐形蝾螈问题可被攻击者创造性利用，且这种攻击与隐写术不同。

缓解技术

有多种缓解隐形蝾螈风险的方法，如使用 HMAC 或基于密码哈希函数的东西，使用以多接收者完整性为安全目标的 AEAD 密码，计算加密密钥的不可逆单向承诺等，并给出了简单的缓解示例代码，重要的是将承诺与密文一起存储而不是与密钥捆绑。

要吸取的教训

在使用 AEAD 通过不安全网络加密数据的网络协议中继续努力，如果在应用层做更复杂的事情，应考虑系统是否需要多个有效对称密钥，若答案是“是”，应在系统设计中明确添加密钥承诺机制，若不确定如何进行可聘请密码学家，作者认为直接解决隐形蝾螈问题比纠结其影响更重要，期待新的标准化 AEAD 模式提供密钥承诺。