Another way to achieve full commitment

[jedisct1]

Hashing the AD is mostly a workaround, and relies on an external primitive.

There's a more straightforward way to get full commitment, if required.

Right after initialization, and prior to absorbing the AD, call Update(0*), and use 128 bits of the output function as the commitment.

This is similar to the practice of adding a fixed block to the plaintext that works with AES-GCM, but not with AEGIS since a collision can happen before the plaintext. But unlike with GCM, side channels in the context of partitioning oracle attacks are not a concern here. Applications are only required to check both the commitment and the tag.

There would be a lack of explicit context separation between regular AEAD usage, and usage with the extra Update(0*) call. But in a nonce-respecting setting, that shouldn't be an issue, especially since the actual input sizes are included in the finalization step.

The downside is ciphertext expansion. But it may be acceptable. And that would only be necessary for protocols that actually require full commitment, including the AD.

It should be possible to document this in a single paragraph of the Security section.

Implementing this would be trivial, but may complicate APIs.

What do you think, @samuel-lucas6 ?

[samuel-lucas6]

That's an interesting idea. So, it would be the Enc() function getting called once to get an output before Absorb() for the associated data?

I think this could be documented as I agree with your points; however, I'm not sure many people are likely to use this. It would need to be clear that this is basically modifying the algorithm, unlike the padding fix with AES-GCM.

[jedisct1]

That's an interesting idea. So, it would be the Enc() function getting called once to get an output before Absorb() for the associated data?

Correct.

I think this could be documented as I agree with your points; however, I'm not sure many people are likely to use this. It would need to be clear that this is basically modifying the algorithm, unlike the padding fix with AES-GCM.

That can be especially useful when AEGIS is used as a MAC.

That extra step should not be mentioned in the rest of the document, only in the section on commitment, as an alternative to hashing the AD. And we have to make it clear that implementations are absolutely not required to support this.

[samuel-lucas6]

That can be especially useful when AEGIS is used as a MAC.

I hadn't thought about that, and the expansion is more reasonable with a 128-bit tag.

That extra step should not be mentioned in the rest of the document, only in the section on commitment, as an alternative to hashing the AD. And we have to make it clear that implementations are absolutely not required to support this.

Yes, exactly. Let's do it then. Do you want me to take a stab at it?

[jedisct1]

Thinking more about it... it would still be possible to find a { (k,n, ad), (k, n, ad') } pair causing a state collision. So that still wouldn't give us full commitment.

Let's forget about this, then. In real-world protocols, it's still fairly uncommon for an attack to have full control over the AD.

[samuel-lucas6]

Oh yeah, I didn't connect the dots either. The padding fix is limited to key commitment, which AEGIS already has when ad is fixed.

Do you think it's worth saying ad can be specified during key derivation (e.g., with HKDF) for full commitment? That's one alternative we could discuss.

[jedisct1]

Specifying ad during key derivation is indeed a good option, that would be worth documenting.

[samuel-lucas6]

I'll do a PR for this when I get a minute.

[jedisct1]

Thank you Samuel!