2 ms·

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 2y 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 2y 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 2y 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.
  - tptacek 2y ago
    Whatever else using a KDF to mix Associated Data into your key might be, it's not "strictly better" than GCM. I'm not sure there's much wrong with it (it's the same approach XAES uses for extended nonces) other than how slow it is, but there's a reason cryptographers don't design all the AEADs to work this way.

tptacek 2y 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 2y 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 2y 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.
- tptacek 2y ago
  Whatever else using a KDF to mix Associated Data into your key might be, it's not "strictly better" than GCM. I'm not sure there's much wrong with it (it's the same approach XAES uses for extended nonces) other than how slow it is, but there's a reason cryptographers don't design all the AEADs to work this way.