3

I'm trying to find evidence of use of the associated data (authenticated cleartext associated with the encrypted and authenticated data) feature offered by AEAD (Authenticated Encryption with Associated Data) construction in a real world protocol. My current understanding is that neither TLS nor SSH (secsh) make use of it, which makes sense as the protocols can also work with cipher suites not offering the feature, and only use the authenticated encryption part of AEAD.

I was unable to find any other candidate, but that may well be a me problem.

Has anyone seen use of associated data in the wild?

1

2 Answers 2

1

I've designed a system or two that used AEAD. I borrowed it as good practice from smarter crypto guys than me.

For instance, it's very useful to tie cipher text in a key:value datastore to it's key through AEAD so the system can detect if that cipher text was borrowed from elsewhere. As an attack vector, an attacker knows the value of one key and wants another key to be that value.

The LUKS manpage mentions a (experimental) mode which uses AEAD.

Edit:

Just hit me you maybe want a communication protocol. In which case,

  • Signal uses AEAD in it's double ratchet protocol.
  • Noise protocol specifies AEAD modes for AES and ChaCha
3
  • I kinda assumed it would happen in some communication protocol, but happy to see it made it in LUKS. For Noise I read "Transport messages are then encrypted and decrypted by calling EncryptWithAd() and DecryptWithAd() on the relevant CipherState with zero-length associated data." which I guess wouldn't count as using the AD in AEAD. Apr 29 at 15:06
  • 1
    It's used in the handshake portion. "Encryption with k uses some AEAD cipher mode (in the sense of Rogaway [1]) and uses the current h value as associated data which is covered by the AEAD authentication." -Noise protocol spec, section 2.2
    – foreverska
    Apr 29 at 15:09
  • I see it now thanks a lot! Apr 29 at 15:18
3

Yes, absolutely. TLS uses the additional data to authenticate the packet header (RFC 8446 § 5.2). TLS 1.2 included sequence number in the additional data computation because doing so prevents replay attacks, which is now done by predictable nonces in TLS 1.3. In fact, this is the ideal situation for additional data: tying additional public data to the encrypted data to prevent tampering or replays.

2

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.