IND-CCA2 and IND-CPA
IND-CPA and IND-CCA2 are the two security notions that pin down exactly what “secure encryption” means, and the difference between them is what a real attacker is allowed to do. IND-CPA, indistinguishability under chosen-plaintext attack, is the baseline: an attacker who can get things encrypted still cannot tell which of two messages a ciphertext hides. IND-CCA2, indistinguishability under adaptive chosen-ciphertext attack, is the strong, deployment-grade notion: even an attacker who can also submit ciphertexts of their choosing and learn whether they decrypt still learns nothing. Real protocols face adaptive, interactive attackers, so IND-CCA2 is the bar a key-encapsulation mechanism like ML-KEM must clear. ML-KEM reaches it by taking an IND-CPA-secure encryption scheme and wrapping it in the Fujisaki-Okamoto transform, which upgrades the weaker guarantee into the stronger one.
Source: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 13, 2024; IND-CCA2 as ML-KEM’s target and the FO transform’s role per Wikipedia, “Kyber”.
The short version:
- IND-CPA is the baseline. An attacker who can obtain encryptions of messages still cannot distinguish which of two chosen messages a given ciphertext encrypts. It assumes the attacker cannot probe your decryption.
- IND-CCA2 is the strong notion. The attacker can additionally submit ciphertexts and see whether or how they decrypt, adaptively, and still learns nothing. This models the interactive attacker real protocols face.
- “IND” means indistinguishability, the game-based standard where security means an attacker cannot tell two encryptions apart better than a coin flip.
- ML-KEM targets IND-CCA2, because a KEM’s output keys real traffic, and an adaptive attacker who could poke at decapsulation must gain nothing.
- The Fujisaki-Okamoto transform is how it gets there. ML-KEM builds an IND-CPA scheme first, then applies the FO transform to reach IND-CCA2, which was introduced by Fujisaki and Okamoto in 1999.
Picture a sealed-bid auction. IND-CPA is the guarantee that an outsider watching sealed envelopes go in cannot tell whose bid is whose, even if they were allowed to submit their own bids to see what a sealed envelope looks like. That is real protection, but it assumes the outsider can only watch and submit, never tamper and probe. IND-CCA2 is the stronger guarantee for a world where the outsider can slip doctored envelopes into the box and watch how the auctioneer reacts, adjusting each new forgery based on the last reaction. If the scheme survives that, it survives the way real attackers actually behave, which is by probing a live system and adapting. ML-KEM is built to survive the second and harsher game, which already contains the first.
What is IND-CPA?
IND-CPA, indistinguishability under chosen-plaintext attack, is the baseline security notion for an encryption scheme, and it is defined through a game. The attacker picks two messages of equal length and hands them to a challenger, who encrypts one of the two at random and returns the ciphertext. The scheme is IND-CPA-secure if the attacker cannot guess which message was encrypted with meaningfully better than 50-50 odds, even though the attacker is allowed to encrypt any messages they like along the way (the “chosen-plaintext” power). That power is automatic for public-key schemes, since anyone with the public key can encrypt, which is why IND-CPA is the natural floor for public-key encryption.
Source: IND-CPA and IND-CCA2 as standard game-based notions in the Bellare-Rogaway lineage, referenced by NIST, FIPS 203, August 13, 2024, and NIST glossary, “IND-CCA2”.
The limitation of IND-CPA is that it says nothing about an attacker who can interact with the decryption side. In practice, many protocols will decrypt attacker-supplied data and behave observably differently depending on the result, whether by returning an error, timing out, or acting on the decrypted content. An IND-CPA-secure scheme can be completely broken by such an attacker, because the guarantee simply does not cover that avenue. That gap is exactly why a stronger notion is needed for real deployment.
What is IND-CCA2, and why is it stronger?
IND-CCA2, indistinguishability under adaptive chosen-ciphertext attack, is the same distinguishing game as IND-CPA but with the attacker handed a far more powerful tool: a decryption oracle. Before and after receiving the challenge ciphertext, the attacker may submit ciphertexts of their choosing and learn their decryptions, adaptively, meaning each query can depend on the answers to earlier ones. The only restriction is that they cannot ask for the challenge ciphertext itself to be decrypted. A scheme is IND-CCA2-secure if, even with that decryption oracle, the attacker still cannot tell which of the two messages the challenge encrypts.
Source: NIST glossary, “IND-CCA2”; IND-CCA2 as ML-KEM’s target per Wikipedia, “Kyber”.
The reason this matters is that it models the real world. A network attacker can inject modified ciphertexts into a live protocol and observe how the receiver responds, which is precisely the decryption-oracle capability the CCA2 game grants. The “adaptive” qualifier, the “2” in CCA2, is what makes it match reality, because a real attacker tunes each next attempt based on what the system just revealed. An IND-CPA-only scheme has no defense against this; an IND-CCA2 scheme is proven to leak nothing even under it. That is why IND-CCA2 is the security bar for any encryption or key-establishment primitive that will run in an interactive protocol.
Why does ML-KEM target IND-CCA2?
ML-KEM targets IND-CCA2 because it is a key-encapsulation mechanism whose whole purpose is to produce a shared secret that then keys real, live traffic, and that setting is adversarial and interactive. A KEM sits in protocols like TLS where an attacker can send crafted encapsulations to a server and observe the outcome, so anything less than adaptive chosen-ciphertext security would leave an exploitable opening. NIST specifies ML-KEM to meet IND-CCA2 for exactly this reason, so that a shared secret established with it stays secret even against an attacker probing the decapsulation side.
Source: NIST, FIPS 203, August 13, 2024; IND-CCA2 target per Wikipedia, “Kyber”.
This is a sharper requirement than key exchange used to state explicitly, and it is a deliberate strengthening in the post-quantum transition. The underlying lattice encryption inside ML-KEM, resting on Module-LWE, is naturally IND-CPA-secure. On its own that would not be safe to deploy, because a chosen-ciphertext attacker could exploit the decapsulation oracle. The standard therefore does not ship the raw IND-CPA scheme; it ships the CCA2-hardened version, which is the point of the transform described next.
How does the Fujisaki-Okamoto transform get from IND-CPA to IND-CCA2?
The Fujisaki-Okamoto transform is a generic recipe for upgrading a weakly secure encryption scheme into a chosen-ciphertext-secure one, and it is the exact tool ML-KEM uses to turn its IND-CPA lattice encryption into an IND-CCA2 KEM. The core trick is to make decryption self-checking. The transform derives the encryption randomness deterministically from the message itself, so that after decrypting, the receiver can re-encrypt the recovered message and confirm the result matches the ciphertext it was handed. A ciphertext that was tampered with fails this re-encryption check and is rejected outright, which slams the door on the chosen-ciphertext attacker: submitting a doctored ciphertext yields only a rejection, revealing nothing useful.
Source: Fujisaki-Okamoto transform introduced by Eiichiro Fujisaki & Tatsuaki Okamoto, “Secure Integration of Asymmetric and Symmetric Encryption Schemes,” CRYPTO 1999, DBLP record; ML-KEM’s use of an FO-transform variant per Wikipedia, “Kyber”.
For a KEM specifically, ML-KEM applies a modern variant of this transform. It starts from the IND-CPA public-key encryption scheme, then the FO machinery both hardens it against chosen-ciphertext attacks and packages it as key encapsulation, so the output is a shared secret rather than an encrypted message. Like the Fiat-Shamir analysis on the signature side, the security proof relies on the random oracle model, treating the hash functions inside the transform as ideal, and the post-quantum analysis uses the quantum version of that model to account for an attacker who can query hashes in superposition. The practical takeaway is that ML-KEM’s IND-CCA2 guarantee is not a property of the raw lattice math alone; it is the lattice math plus the FO transform, and both are essential.
Common misconceptions
- “IND-CPA security is enough for deployment.” It is not, for interactive protocols. An IND-CPA scheme can be broken by an attacker who probes the decryption side, which is why ML-KEM targets the stronger IND-CCA2.
- “IND-CCA2 is about hiding the message content, IND-CPA is about something else.” Both are about the same thing, indistinguishability, meaning an attacker cannot tell which of two messages a ciphertext hides. The difference is what powers the attacker gets: IND-CCA2 additionally grants an adaptive decryption oracle.
- “ML-KEM is secure because Module-LWE is hard, full stop.” Module-LWE hardness gives the raw scheme IND-CPA security. The IND-CCA2 guarantee that makes ML-KEM safe to deploy comes from wrapping that scheme in the Fujisaki-Okamoto transform. Both pieces are load-bearing.
- “The FO transform is a lattice-specific invention.” It is a generic construction from 1999, predating the lattice standards by decades, that upgrades many kinds of IND-CPA schemes to IND-CCA. ML-KEM applies a modern KEM variant of it.
- “These notions only matter to cryptographers.” They are what a vendor claim of “quantum-safe encryption” actually has to mean. A KEM that only met IND-CPA would be a real weakness, so knowing the target is IND-CCA2 is part of evaluating whether an implementation is doing the right thing.
Questions people ask
What does IND-CCA2 mean in plain terms? It means an encryption scheme hides which message a ciphertext contains even from an attacker who can submit their own ciphertexts to the decryption process and adapt their next attempt based on what they see. It is the strong, realistic security bar for encryption running in a live protocol.
How is IND-CCA2 different from IND-CPA? Both require that an attacker cannot distinguish which of two messages a ciphertext hides. IND-CPA gives the attacker only the ability to encrypt messages of their choosing. IND-CCA2 additionally gives them an adaptive decryption oracle, which models a real network attacker probing a live system, making it the stronger and more realistic notion.
Why does ML-KEM need IND-CCA2 rather than just IND-CPA? Because ML-KEM is a key-encapsulation mechanism used in interactive protocols where an attacker can send crafted encapsulations and watch the server’s response. Only IND-CCA2 guarantees the shared secret stays safe under that adaptive chosen-ciphertext probing, so it is the required bar.
What is the Fujisaki-Okamoto transform? It is a generic method, introduced by Fujisaki and Okamoto in 1999, for turning a weakly secure (IND-CPA) encryption scheme into a chosen-ciphertext-secure one. It makes decryption self-checking by deriving the encryption randomness from the message, so tampered ciphertexts are detected and rejected. ML-KEM uses a KEM variant of it to reach IND-CCA2.
Is ML-KEM’s security just Module-LWE hardness? No. Module-LWE hardness gives the internal scheme its IND-CPA security. The IND-CCA2 security that makes ML-KEM safe to deploy comes from applying the Fujisaki-Okamoto transform on top, with the analysis done in the quantum random oracle model. The hardness assumption and the transform are both necessary.
Do I need to understand these notions to migrate to ML-KEM? Not to operate it, since the guarantees are built into the standard and the library. Understanding them helps you read vendor claims critically, because “quantum-safe” for a KEM specifically means IND-CCA2, and it clarifies why ML-KEM is more than raw lattice math bolted into a protocol.
Everything here is the map, given freely. When your team needs its key-establishment stack understood and sequenced onto the post-quantum standards, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.