作为一个非常普遍的规则，关联数据（以下简称“AD”）的目的是将密文绑定到它应该出现的上下文，以便尝试将有效的密文“剪切并粘贴”到不同的上下文中被检测和拒绝。

例如，假设我正在加密插入到键/值数据库中的值，并且我使用记录键作为 AD。那有什么作用？嗯，首先，从机械上讲，这意味着每当我解密该值时，我必须提供与 AD 相同的密钥，否则解密将失败并出现真实性错误。因此，我的应用程序必须执行该步骤才能正确解密任何数据。

其次，更深层次的是，通过使用密钥作为 AD，我挫败了一种内部人员（例如数据库管理员）可能对我的应用程序进行的攻击：获取数据库中的两条记录并交换它们的值. 如果没有 AD，应用程序会很高兴地解密这些密钥，并盲目地假设它读取了这些密钥的正确值。使用作为 AD 的密钥，应用程序会立即注意到这些值是不真实的——即使攻击者从未真正修改过它们——因为它们发生在错误的上下文中。这只是众多可能中的一个示例，但关联数据的应用程序往往具有这种风格。

人们经常从示例中遗漏的一个重要细节是，相关数据不一定必须与密文一起存储或传输。诚实方都能够正确推断的任何依赖于上下文的非秘密值都可以用作关联数据。例如，如果各方正在执行一个复杂的协议，该协议是根据状态机制定的，这样每个正确的一方总是可以告诉他们自己的状态以及诚实的交易对手应该处于什么状态，那么这些状态——即使他们re 隐含在协议中——可以用作 AD。这就是 AEAD 套件对 TLS 等协议设计者如此有吸引力的原因——它是一种可用于降低安全协议复杂性的工具。

来自RFC 5116 - An Interface and Algorithms for Authenticated Encryption（2008 年 1 月）：

认证加密^BN00是一种加密形式，除了为加密的明文提供机密性之外，还提供了一种检查其完整性和真实性的方法。

带有关联数据的身份验证加密或 AEAD ^R02增加了检查某些未加密的关联数据 (AD) 的完整性和真实性的能力，也称为“附加身份验证数据”。

强调我的

从2.1 - Authenticated Encryption：

关联数据A用于保护需要认证但不需要保密的信息。例如，当使用 AEAD 保护网络协议时，此输入可能包括

• 地址，
• 港口，
• 序列号，
• 协议版本号，
• 以及指示应如何处理明文或密文的其他字段
• 转发
• 或处理。

在许多情况下，需要对这些字段进行身份验证，尽管它们必须保持清晰以允许网络或系统正常运行。当该数据包含在输入 A 中时，无需将数据复制到明文中即可提供身份验证。

强调我的

2002 年，Phillip Rogaway 指出：

带有关联数据的认证加密

Oʀɪɢɪɴ ᴏꜰ ᴛʜᴇ ᴘʀᴏʙʟᴇᴍ。Burt Kaliski [16] 首次向作者指出，在使用集成 AE 模式时需要处理关联数据。很快又有几个人表达了同样的情绪。那些适应这个问题的人参与了需要将一些明文数据（例如 IP 地址）绑定到密文的标准化工作。当使用诸如 OCB 之类的 AE 模式时，人们想要一种廉价且安全的方式来做到这一点

[16] B.卡利斯基。个人通讯，2001 年 5 月。

这是您想要与加密数据一起使用的东西，并确保它没有被更改，但需要（或可以）保持可见。