7

Authenticated encryption (AE) and authenticated encryption with associated data (AEAD, variant of AE) is a form of encryption which simultaneously provides confidentiality, integrity, and authenticity assurances on the data.

Source: Wikipedia

I recently noticed that several SSL checkers started to point out AEAD. But, what is the difference between AE and AEAD and what is the purpose of “associated authenticated data” to an encrypted connection? Why not encrypt it all, instead of “authenticate” it only?

  • @schroeder i know it’s additional authenticated data. But what value does “authenticated” add to a feature which main goal is “encryption”. Why not encrypt it all? Maybe my question should more be like “What is the purpose of adding unencrypted/authenticated data to an encrypted connection?” – Bob Ortiz Feb 7 '18 at 0:10
  • Or rather, the question might be, "what does AE not encrypt?" ? – schroeder Feb 7 '18 at 0:23
12

As a very general rule, the purpose of associated data (hereafter "AD") is to bind a ciphertext to the context where it's supposed to appear, so that attempts to "cut-and-paste" a valid ciphertext into a different context can be detected and rejected.

For example, suppose I'm encrypting the values that I insert into a key/value database, and I use the record key as AD. What does that do? Well, first of all, mechanically it means now that whenever I decrypt the value, I must present the same key as AD or otherwise the decryption will fail with an authenticity error. So my application will have to perform that step in order to decrypt any of the data correctly.

Second, and more deep, is that by using the key as AD, I've thwarted one sort of attack an insider—say, the database administrator—could conceivably carry out against my application: take two records in the database and swap their values. Without the AD, the application would happily decrypt these, and blindly assume that it read the correct value for those keys. With the key as AD, instead the application would immediately notice that the values are not authentic—even though the attacker never actually modified them—because they're occurring in the wrong context. That's just one example out of many possible, but applications of associated data tend to have that flavor.

One important detail that people often miss from examples is that the associated data doesn't necessarily have to be stored or transmitted with the ciphertext. Any context-dependent non-secret values that the honest parties are both able to correctly infer can be useful as associated data. For example, if the parties are executing a complex protocol that's been formulated in terms of a state machine, such that every correct party can always tell their own state and that which an honest counterparty should be in, then those states—even though they're implicit to the protocol—can be used as AD. This is the sort of thing that makes AEAD suites so attractive to designers of protocols like TLS—it's a tool that can be used to cut down on the complexity of a secure protocol.

  • 1
    Follow on question... the wikepedia article mentions: Encryption -- Input: plaintext, key, and optionally a header in plaintext that will not be encrypted, but will be covered by authenticity protection. Is it correct to infer that the optional header is the "Associated Data" portion of the AEAD? Which is to say, if no header is provided (and 100% of the plaintext is secured), we have simply AE? – Eddie May 28 '18 at 20:56
  • 2
    @Eddie: Yes, sometimes people call the associated data a "header," a term which I think is excessively specific and thus apt to mislead; headers are a good candidate for use as associated data, but by no means the only such candidates. Sometimes people say "metadata" instead. – Luis Casillas May 30 '18 at 20:05
  • 1
    Brilliant. I had been searching for a while to understand what the AD portion of AEAD was, and your answer (and comment) finally solidified it in my head. Thank you! – Eddie May 30 '18 at 20:09
2

From RFC 5116 - An Interface and Algorithms for Authenticated Encryption:

Authenticated encryptionBN00 is a form of encryption that, in addition to providing confidentiality for the plaintext that is encrypted, provides a way to check its integrity and authenticity.

Authenticated Encryption with Associated Data, or AEADR02, adds the ability to check the integrity and authenticity of some Associated Data (AD), also called "additional authenticated data", that is not encrypted.

And from 2.1 - Authenticated Encryption:

The associated data A is used to protect information that needs to be authenticated, but does not need to be kept confidential. When using an AEAD to secure a network protocol, for example, this input could include

  • addresses,
  • ports,
  • sequence numbers,
  • protocol version numbers,
  • and other fields that indicate how the plaintext or ciphertext should be handled
  • forwarded
  • or processed.

In many situations, it is desirable to authenticate these fields, though they must be left in the clear to allow the network or system to function properly. When this data is included in the input A, authentication is provided without copying the data into the plaintext.

In 2002, Phillip Rogaway noted:

Authenticated-Encryption with Associated-Data

Oʀɪɢɪɴ ᴏꜰ ᴛʜᴇ ᴘʀᴏʙʟᴇᴍ. The need to handle associated-data when using an integrated AE mode was first pointed out to the author by Burt Kaliski [16]. Several more individuals soon communicated the same sentiment. Those attuned to this problem were involved in standardization efforts that needed to bind to a ciphertext some cleartext data, such as an IP address. People wanted a cheap and secure way to do this when using an AE-mode such as OCB

It's stuff that you want to go with the encrypted data, and be sure it hasn't been altered, but needs (or can) remain visible.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.