Committing authenticated encryption

Traditionally, AEAD modes have been non-committing. In simple terms, this means it is possible to craft a ciphertext that authenticates under multiple keys. Indeed, in a scenario where your keys are inherently low-entropy (i.e., password-based) or are adversarially controlled, this is a problem. Because of this, some would have you believe that creating or using non-committing modes at this point is unacceptable. In this article, I will go against the hype train and argue why non-committing modes will continue to serve a dominant role in the symmetric cryptography space.

When to commit

If your application uses keys that are derived from passwords, then you should prefer a committing AEAD mode. This is because an adversary can craft a ciphertext that authenticates under multiple passwords, and can then perform a single online query to test multiple passwords at once. This is a problem since passwords are inherently low-entropy, resulting in a much smaller search space. In effect, the decryption oracle is acting as a partition oracle.
If your keys are adversarially controlled, then you should prefer a committing AEAD mode. This is because an adversary can trick a user into decrypting with a different key, resulting in a different (potentially malicious) authentic plaintext.

If either of the above cases applies to your application, then you should absolutely be using a committing AEAD mode.

Due diligence

If you know your nonces will never repeat, would you sacrifice performance to use a mode resistant to nonce misuse? Of course not, this would be silly. If you are using a mode that can authenticate the ciphertext before decrypting it, would you throw away performance to use a mode resistant to the release of unverified plaintext? Heck no. If your keys are generated uniformly at random and are not under adversarial control, would you give up performance to use a committing mode? Absolutely not.

Always put forth due diligence when selecting a mode for your application. List out the exact requirements of your application, and select a mode that satisfies those requirements. It is perfectly safe to use a non-committing mode if you know you do not need it. Additionally, keep in mind that using cryptographic keys derived from low-entropy passwords will always be insecure, regardless of the committing property. The industry is actively moving away from passwords; once passwords are obsolete, it is difficult to justify the added complexity and performance overhead of committing AEAD.

The committing property is just one in a long list of existing properties (nonce misuse resistance, RUP resistance, etc.). My opinion is that the pendulum has swung too far in the direction of committing modes, and once passwords become less common, the pendulum will swing back to a more sane position. As always, put due diligence ahead of hype and FUD. Continue to avoid paying for features you do not need.