3

The partition oracle attacks exploits the non-committing AEAD schemes.

Informally, a committing encryption scheme is one for which it is computationally intractable to find a pair of keys and a ciphertext that decrypts under both keys. AES-GCM and ChaCha20-1305 fail on this so they are non-committing.

As a countermeasure to the partition oracles, it is advised to use Encrypt-then-HMAC with one key since HMAC is committing. I.e. the key for encryption and HMAC are the same. Normally, we don't advise using a key for two different purposes. This, however, advised in the paper.

This question is specific to HMAC. Is there any published attack on a scheme that uses the same key for encryption and HMAC? Or any article that shows its security exists?

kelalaka
  • 48,443
  • 11
  • 116
  • 196

1 Answers1

2

I can't find any published attack, but CodesInChaos and Thomas Pornin both said no structural interference is known between AES and HMAC back in 2013. The same should be true of ChaCha20 and HMAC. I've never heard anything different.

However, it's noteworthy that you can have a committing Encrypt-then-MAC implementation using separate keys for encryption and authentication, which would be more sensible than the single key approach. All that's required for commitment is:

  1. Both keys are derived from the same input keying material using a secure KDF (e.g. HKDF or BLAKE2/BLAKE3). [Source: email correspondence with a partitioning oracle attack author ages ago]
  2. The authentication tag is 256 bits or larger for collision resistance. [Source]

As such, I'm not sure why they recommended Encrypt-then-HMAC with a single key.

samuel-lucas6
  • 1,783
  • 7
  • 17