Read on Twitter
Random Saturday morning thought: Naive HKDF-AES-CTR-HMAC-SHA256 is not a committing AEAD scheme.
(Thread)
(Thread)
First, what is a committing AEAD? Getting a valid ciphertext in any AEAD scheme famously proves that the endpoint that constructed that message knew the key that you're using to decrypt it.
However, what it doesn't prove is that the sender doesn't know another key under which the same ciphertext is also a valid message.
As an example, Eve tries to send Bob a message, with Bob using Trent to screen the plaintext for dangerous material (For example an XSS)
As an example, Eve tries to send Bob a message, with Bob using Trent to screen the plaintext for dangerous material (For example an XSS)
Eve tries to send Bob a dangerous plaintext, while convincing Trent that the plaintext is harmless. Both Bob and Trent agree on the ciphertext, but Eve has one chance to trick them: She can tell Trent and Bob different keys
Most AEAD schemes are vulnerable in this sort of scenario, which makes sense given that committing isn't a property an AEAD is expected to have.
The easiest example is Encrypt-Then-Authenticate with separate keys for encryption and authentication:
The easiest example is Encrypt-Then-Authenticate with separate keys for encryption and authentication:
Simply change the encryption key, leaving the authentication key they same, and you get a valid ciphertext that decrypts to two different plaintexts.
(UHF based schemes like GCM are also very vulnerable to this, but I'll talk about that later)
(UHF based schemes like GCM are also very vulnerable to this, but I'll talk about that later)
If you don't want to expand the ciphertext, the solution is fairly straightforward: Use a key derivation function to derive the encryption and authentication keys from common keying material.
However, as alluded to in the first tweet, you have to be careful here: If you derive the keys using a common pseudo-random stream and derive the authentication key before the encryption key, you can still break the commitment:
Eve tells Trent that the first 31 bytes of the HKDF stream are the authentication key, and the next 16 the encryption key, and Bob that the first 32 bytes of the stream are the authentication key and the next 16 the encryption key.
They then brute force nonces until HKDF(key, nonce)[32] = 0
HMAC will fill short keys with zeroes, which means Trent and Bob arrive at the same authentication key, but have an encryption key shifted by one byte.
HMAC will fill short keys with zeroes, which means Trent and Bob arrive at the same authentication key, but have an encryption key shifted by one byte.
Ways to solve this is for example using proper domain separation between the derivation streams (for example prefixing the info element with a 0 for the auth key and a 1 for the enc key, followed by the nonce) or my favorite solution, using the full key as IKM for the HKDF.
"Full key" here means the key including all algorithm choices, not just the raw key, in this case in particular the HMAC key size, proving once again that a cryptographic key is not just the raw key material, but also all parameter choices made in the algorithm.
