4 ms·

Can someone explain what use the AD is, if we have to decrypt the message to authenticate the AD? If I'm decrypting the message already just to authenticate it,

Can someone explain what use the AD is, if we have to decrypt the message to authenticate the AD? If I'm decrypting the message already just to authenticate it, why wouldn't I encrypt the AD as well?

tptacek 2y ago
Because you need it outside the context of encryption/decryption. https://news.ycombinator.com/item?id=43827342 https://news.ycombinator.com/item?id=43827342 Honestly, the classic "message routing" example most things give for AEAD is not very useful. Context binding is a much better primer for intuition.
- stavros 2y ago
  Hm, I understand the use cases, but I don't understand this: The only way to get the AD is to decrypt the ciphertext, right? Otherwise the data is unauthenticated, so I assume it's a big no-no to access it. If you need to decrypt the ciphertext to access the AD, why do you care if it was encrypted or not? Basically, I'm not sure why `encrypt(key, nonce, (data, associated data))` (ie adding the AD to your ciphertext, with the encryption framework being unaware of it) is that different from `encrypt(key, nonce, data, associated data)` (ie the AD being a first-class citizen). EDIT: I saw your other message, and this makes it click for me: > authenticated data can include data that doesn't even appear in the message, but rather is derived from the context at the time the message is encrypted and decrypted So the AD can be an additional envelope-level thing at encryption/decryption time, that helps a lot, thanks!
  - tptacek 2y ago
    This is why message routing headers are kind of a fucky example (you can make it make sense but it begs for this confusion). Instead, just take the chunked large-file encryption use case I gave in that comment. The chunk offset isn't recorded anywhere in the ciphertext. It's derived contextually while you decrypt the file. The AD ensures that the decryption will explode if you try to cut and paste chunks of the file into different positions.
    - stavros 2y ago
      Yeah, you're right, I was thinking about it in a case where the implementation had the ciphertext being `(block data, chunk offset)` so it did make it part of the message, but it's more elegant for the associated data to be separate from the ciphertext.
      - tptacek 2y ago
        It's a really good question, because, in order to verify the AD, you have to have the same key you need to decrypt it.
        stavros 2y ago
        Yep, that's the part that throws me. Is it fair to say that it's a more elegant way to include metadata in the ciphertext, without really messing with the plaintext itself? Ie it's basically "just" a way to distinguish the message from its metadata?
        edoceo 2y ago
        Does that make it like some kind of HMAC?
        hxtk 2y ago
        Yes, in fact, one construction of the AEAD primitive is to use AES-CTR with HMAC to "bolt on" authentication after the fact (AES-CTR on its own is an unauthenticated stream cipher). You can find an implementation of AES-CTR-HMAC (at a high level where AES-CTR and HMAC are both given) here: https://github.com/tink-crypto/tink-go/blob/main/aead/aesctrhmac/aead.go#L75 https://github.com/tink-crypto/tink-go/blob/main/aead/aesctr...
      - firesteelrain 2y ago
        Message headers have a tendency to want to mutate so it makes the problem more complicated to solve for but decrypting chunks in the right order is a good example to grasp because it’s referring to essential metadata that needs to stay open so readers of the data know what to do with it. AD is bound to the cipher text.
- dadrian 2y ago
  I dunno why you say it isn't useful. It is inherently plaintext, but still worth authenticating. If you just used an AEAD but didn't put e.g. the session identifier or connection ID or sequence number in the AD, it would be entirely unauthenticated, but the decryption of, say, the message body would still succeed.
  - tptacek 2y ago
    I'm not saying it isn't useful, I'm saying it's not a useful example for getting people to understand the concept. Everyone runs aground on "but you need the decryption key to authenticate the plaintext anyways".
rendaw 2y ago
IIUC you don't have to decrypt the message - the outermost primitive is the authentication. The point I got is that both the encrypted data and unencrypted data are authenticated.

Can someone explain what use the AD is, if we have to decrypt the message to authenticate the AD? If I'm decrypting the message already just to authenticate it, why wouldn't I encrypt the AD as well?

tptacek 2y ago

Because you need it outside the context of encryption/decryption. https://news.ycombinator.com/item?id=43827342 https://news.ycombinator.com/item?id=43827342 Honestly, the classic "message routing" example most things give for AEAD is not very useful. Context binding is a much better primer for intuition.

stavros 2y ago
Hm, I understand the use cases, but I don't understand this: The only way to get the AD is to decrypt the ciphertext, right? Otherwise the data is unauthenticated, so I assume it's a big no-no to access it. If you need to decrypt the ciphertext to access the AD, why do you care if it was encrypted or not? Basically, I'm not sure why `encrypt(key, nonce, (data, associated data))` (ie adding the AD to your ciphertext, with the encryption framework being unaware of it) is that different from `encrypt(key, nonce, data, associated data)` (ie the AD being a first-class citizen). EDIT: I saw your other message, and this makes it click for me: > authenticated data can include data that doesn't even appear in the message, but rather is derived from the context at the time the message is encrypted and decrypted So the AD can be an additional envelope-level thing at encryption/decryption time, that helps a lot, thanks!
- tptacek 2y ago
  This is why message routing headers are kind of a fucky example (you can make it make sense but it begs for this confusion). Instead, just take the chunked large-file encryption use case I gave in that comment. The chunk offset isn't recorded anywhere in the ciphertext. It's derived contextually while you decrypt the file. The AD ensures that the decryption will explode if you try to cut and paste chunks of the file into different positions.
  - stavros 2y ago
    Yeah, you're right, I was thinking about it in a case where the implementation had the ciphertext being `(block data, chunk offset)` so it did make it part of the message, but it's more elegant for the associated data to be separate from the ciphertext.
    - tptacek 2y ago
      It's a really good question, because, in order to verify the AD, you have to have the same key you need to decrypt it.
      - stavros 2y ago
        Yep, that's the part that throws me. Is it fair to say that it's a more elegant way to include metadata in the ciphertext, without really messing with the plaintext itself? Ie it's basically "just" a way to distinguish the message from its metadata?
        edoceo 2y ago
        Does that make it like some kind of HMAC?
        hxtk 2y ago
        Yes, in fact, one construction of the AEAD primitive is to use AES-CTR with HMAC to "bolt on" authentication after the fact (AES-CTR on its own is an unauthenticated stream cipher). You can find an implementation of AES-CTR-HMAC (at a high level where AES-CTR and HMAC are both given) here: https://github.com/tink-crypto/tink-go/blob/main/aead/aesctrhmac/aead.go#L75 https://github.com/tink-crypto/tink-go/blob/main/aead/aesctr...
    - firesteelrain 2y ago
      Message headers have a tendency to want to mutate so it makes the problem more complicated to solve for but decrypting chunks in the right order is a good example to grasp because it’s referring to essential metadata that needs to stay open so readers of the data know what to do with it. AD is bound to the cipher text.
dadrian 2y ago
I dunno why you say it isn't useful. It is inherently plaintext, but still worth authenticating. If you just used an AEAD but didn't put e.g. the session identifier or connection ID or sequence number in the AD, it would be entirely unauthenticated, but the decryption of, say, the message body would still succeed.
- tptacek 2y ago
  I'm not saying it isn't useful, I'm saying it's not a useful example for getting people to understand the concept. Everyone runs aground on "but you need the decryption key to authenticate the plaintext anyways".

rendaw 2y ago

IIUC you don't have to decrypt the message - the outermost primitive is the authentication. The point I got is that both the encrypted data and unencrypted data are authenticated.