Most developers assume a ciphertext can only be read by the key that made it, and that any other key just produces garbage or a failed tag. A key commitment attack shows that assumption is false for the authenticated encryption modes in wide use today. With modest effort an attacker can craft a single ciphertext that decrypts to one valid message under key A and a different valid message under key B. The encryption never commits to a single key, and that gap enables message franking abuse and the fast password cracking of a partitioning oracle. It sits inside the broader family of cryptographic oracle attacks.
What a key commitment attack breaks
An AEAD mode, authenticated encryption with associated data, promises two things. Confidentiality: without the key you cannot read the plaintext. Integrity: you cannot change the ciphertext without the tag check failing. Both hold here. The attack does not touch either one.
The property it breaks is a third one that many people assume comes for free but does not: commitment. A committing scheme guarantees that a given ciphertext and tag authenticate under at most one key. A non committing scheme makes no such promise, and the popular modes are non committing. You can hold a ciphertext that is perfectly valid under two keys you chose, each decrypting to a clean, attacker selected message.
Why the common modes are not committing
Take a widely used mode that builds its tag as a polynomial over the ciphertext, evaluated at a secret point derived from the key, then masked by another key derived value. The tag check passes when that computation lands on the tag attached to the message. For two different keys there are two different secret points and two different masks, but the attacker has free bytes in the message to play with. By choosing those free bytes, the attacker can solve a small equation so the tag computation lands on the same value under both keys at once. Nothing about this forges a tag without a key. The attacker owns both keys and is building a message that happens to satisfy both tag equations.
This is the same structural weakness that shows up in AES GCM nonce reuse: the tag is algebra over known values, and algebra can be solved when the attacker controls enough of the inputs.
Authentication proves a message was not altered by someone without the key. It does not prove which key that was, and a key commitment attack lives in the difference.
What the gap enables
A missing commitment looks harmless until you find a system that depends on one ciphertext meaning one key.
Message franking abuse
Some encrypted messaging systems let a recipient report an abusive message so a moderator can verify it really was sent. This relies on the ciphertext committing to its content under the message key. If an attacker can craft one ciphertext that decrypts to a harmless message under the key shown to the moderator and to an abusive message under the key the victim actually uses, the reporting system can be fooled. The abuse is real but the evidence does not hold up, or an innocent message is made to look abusive. Commitment is exactly the property franking needs, and non committing AEAD does not provide it.
Partitioning oracles
The same multi key ciphertext is the engine of the partitioning oracle attack. If one ciphertext can authenticate under a thousand candidate keys, a single accept answer from a server rules in a thousand guesses at once, collapsing a slow password search into a fast one. No commitment means the attacker can build that multi collision. Commitment makes it impossible.
How to fix it
The goal is to bind the ciphertext to exactly one key. Several approaches do this.
- Use a committing AEAD construction. Newer modes are designed so a ciphertext authenticates under one key only. When your library offers a committing mode, prefer it for anything where keys are guessable or where a ciphertext must prove its origin.
- Add an explicit key commitment. A generic transform computes a short commitment value from the key, a hash of the key or a derived tag, and stores it with the ciphertext. On decryption you recompute it and reject any mismatch. Now only the true key verifies.
- Encrypt then MAC with a key bound MAC. Run a MAC whose output depends on the key over the ciphertext, and check it first. If the MAC genuinely binds the key, a foreign key fails before decryption.
- Do not reuse one ciphertext across trust boundaries. If a design assumes a ciphertext means one sender or one key, make that assumption true with a commitment rather than hoping the mode provides it.
For where this fits among common cryptographic usage bugs, see vulnerability basics.
The assumption that breaks
The root mistake is treating integrity and commitment as the same property. They are not. A mode can guarantee that a message was not tampered with while saying nothing about which key authenticated it. Spotting this means understanding what a system expects from its encryption, then checking whether the mode actually delivers that expectation, rather than matching a list of weak calls. That assumption testing is what an autonomous researcher like UnboundCompute is built to do. Read more on our about page.
Frequently asked questions
What is a key commitment attack?
It is an attack that exploits the fact that common authenticated encryption modes do not commit to a single key. An attacker can craft one ciphertext that decrypts to a valid message under key A and a different valid message under key B. The attacker owns both keys and builds a message that satisfies both tag checks at once.
Does a key commitment attack break confidentiality or integrity?
Neither. Without a key you still cannot read the plaintext, and you still cannot alter a ciphertext without the tag check failing. The attack breaks a separate property called commitment, which is the guarantee that a ciphertext authenticates under only one key. Many people assume that comes for free, but the popular modes do not provide it.
What damage does missing key commitment cause?
Two main harms. It enables message franking abuse, where a crafted ciphertext reads as harmless to a moderator and abusive to the victim, so abuse reporting can be fooled. It also powers a partitioning oracle, where one ciphertext valid under many keys lets an attacker rule in many password guesses per query.
How do you fix missing key commitment?
Bind the ciphertext to one key. Use a committing AEAD construction where available, add an explicit commitment value computed from the key and checked on decryption, or run a key bound MAC over the ciphertext and verify it first. Do not reuse one ciphertext across trust boundaries without such a commitment.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.