3 ms·

It sounds like the source of confusion is in terminology. I would consider AES-CBC+HMAC to be an AEAD construction, and I would consider whatever "secret key" y

by hxtk 1y ago

It sounds like the source of confusion is in terminology. I would consider AES-CBC+HMAC to be an AEAD construction, and I would consider whatever "secret key" you pass into HMAC along with the ciphertext to be the "associated data". AES-GCM is an AEAD construction that gives you the MAC organically as part of the cipher, but that is not what makes it AEAD as I understand it. If you are using an AEAD cipher mode, then you always have AD, but sometimes that AD might be the empty string. In that case, the advantage to using contextual AD as opposed to using the empty string as AD and then doing additional verification on the decrypted object is that it prevents some kinds of timing attacks, because cryptographic libraries will often implement AEAD constructions to fail in constant time, where as your scheme will take longer if post-decryption validation of contextual data encoded in the plaintext fails compared to if decryption fails.

vlovich123 1y ago
> I would consider AES-CBC+HMAC to be an AEAD construction OK fair. > and I would consider whatever "secret key" you pass into HMAC along with the ciphertext to be the "associated data" The secret key isn't associated data. You take your base HKDF key and expand new crypto for an authenticated cipher from the offset as info (+ maybe other parameters like file name). That key is then used to decrypt. If you squint I guess you could call that AD but it's functionally a very different role. > because cryptographic libraries will often implement AEAD constructions to fail in constant time, where as your scheme will take longer if post-decryption validation of contextual data encoded in the plaintext fails compared to if decryption fails. I think you've misunderstood what I said. As I repeat above, the AEAD key is derived from the offset. There's no post-decryption validation of contextual data because the plaintext is empty. HKDF derivation is constant time and authenticated decryption is constant time. Once decrypted you have a valid block at that location. There's nothing extra left to validate (or perhaps the decrypted contents, but that's irrelevant for cryptographic purposes). My broader point is that I have yet to encounter a use-case for a non-empty AD string.
- tptacek 1y ago
  There are several of them on this thread. For example: encrypt a 10 gigabyte file. You'll need to chunk it; each chunk will exist at an offset. Encode the chunk offset into the Associated Data. Notice that you never store this Associated Data; you simply have it in the context of encrypting and decrypting the file. But the AEAD MAC captures it, and now you can't cut and paste chunks of a ciphertext.
  - vlovich123 1y ago
    Or alternatively, as I said, derive a new key for each chunk where the offset is part of the info used to derive the key and have an empty AD. Same effect.
    - tptacek 1y ago
      I may be missing a subtlety here but it seems like you've essentially reinvented Associated Data but with an extra KDF extraction and an AES key expansion for every chunk.
    - hxtk 1y ago
      It sounds like you have constructed a way to encrypt data such that it can only be decrypted by someone who has the same (secret) key and (non-secret) associated data that was used to encrypt it, or else decryption fails. As you said, same effect: the scheme you have described is not an alternative to AEAD. It is an example of AEAD. You're still using the offset as associated data, you just happen to be composing your AEAD scheme out of another AEAD scheme into which you pass an empty string as associated data. Other than differences in the limit to the number of messages you can encrypt before nonce exhaustion or the number of bits of secrecy or authentication strength provided, the external interface and use case of your system perfectly matches that of AES-GCM or other popular AEAD constructions.
      - vlovich123 1y ago
        > Other than differences in the limit to the number of messages you can encrypt before nonce exhaustion or the number of bits of secrecy or authentication strength provided, the external interface and use case of your system perfectly matches that of AES-GCM or other popular AEAD constructions. Ahh, but that’s not a trivial part of the design and why this is strictly better than using a single AES-GCM key with AD. And also it’s more generic across whatever type of key you choose to derive.

by hxtk 1y ago

vlovich123 1y ago

> I would consider AES-CBC+HMAC to be an AEAD construction OK fair. > and I would consider whatever "secret key" you pass into HMAC along with the ciphertext to be the "associated data" The secret key isn't associated data. You take your base HKDF key and expand new crypto for an authenticated cipher from the offset as info (+ maybe other parameters like file name). That key is then used to decrypt. If you squint I guess you could call that AD but it's functionally a very different role. > because cryptographic libraries will often implement AEAD constructions to fail in constant time, where as your scheme will take longer if post-decryption validation of contextual data encoded in the plaintext fails compared to if decryption fails. I think you've misunderstood what I said. As I repeat above, the AEAD key is derived from the offset. There's no post-decryption validation of contextual data because the plaintext is empty. HKDF derivation is constant time and authenticated decryption is constant time. Once decrypted you have a valid block at that location. There's nothing extra left to validate (or perhaps the decrypted contents, but that's irrelevant for cryptographic purposes). My broader point is that I have yet to encounter a use-case for a non-empty AD string.

tptacek 1y ago
There are several of them on this thread. For example: encrypt a 10 gigabyte file. You'll need to chunk it; each chunk will exist at an offset. Encode the chunk offset into the Associated Data. Notice that you never store this Associated Data; you simply have it in the context of encrypting and decrypting the file. But the AEAD MAC captures it, and now you can't cut and paste chunks of a ciphertext.
- vlovich123 1y ago
  Or alternatively, as I said, derive a new key for each chunk where the offset is part of the info used to derive the key and have an empty AD. Same effect.
  - tptacek 1y ago
    I may be missing a subtlety here but it seems like you've essentially reinvented Associated Data but with an extra KDF extraction and an AES key expansion for every chunk.
  - hxtk 1y ago
    It sounds like you have constructed a way to encrypt data such that it can only be decrypted by someone who has the same (secret) key and (non-secret) associated data that was used to encrypt it, or else decryption fails. As you said, same effect: the scheme you have described is not an alternative to AEAD. It is an example of AEAD. You're still using the offset as associated data, you just happen to be composing your AEAD scheme out of another AEAD scheme into which you pass an empty string as associated data. Other than differences in the limit to the number of messages you can encrypt before nonce exhaustion or the number of bits of secrecy or authentication strength provided, the external interface and use case of your system perfectly matches that of AES-GCM or other popular AEAD constructions.
    - vlovich123 1y ago
      > Other than differences in the limit to the number of messages you can encrypt before nonce exhaustion or the number of bits of secrecy or authentication strength provided, the external interface and use case of your system perfectly matches that of AES-GCM or other popular AEAD constructions. Ahh, but that’s not a trivial part of the design and why this is strictly better than using a single AES-GCM key with AD. And also it’s more generic across whatever type of key you choose to derive.