funcCPA

Overview

Functional CPA (funcCPA) security, introduced by Akavia, Gentry, Halevi, and Vald, extends the standard CPA game with a functional re-encryption oracle that models settings where a server performing FHE computations is allowed to interactively delegate part of the computation back to the client (who holds the secret key). In the funcCPA game, the adversary can submit a ciphertext and a function to a recryption oracle, which decrypts , applies , and returns a fresh encryption of the result.

The motivation comes from practical FHE deployments where bootstrapping - the most expensive operation - can be replaced by a cheaper interactive protocol: the server sends a masked ciphertext to the client (or a local trusted proxy such as a secure enclave), which decrypts and re-encrypts it, and the server removes the mask homomorphically. The funcCPA notion captures the security requirement in this setting: even with access to this re-encryption oracle, the adversary should not be able to break indistinguishability.

The key result is that funcCPA is strictly stronger than CPA. Intuitively, the re-encryption oracle is weaker than a full decryption oracle because it only returns encryptions of function outputs, never raw plaintexts. Akavia et al. provided construction blueprints to turn CPA-secure FHE schemes into funcCPA-secure ones.

Formal Definition

Given a public-key encryption scheme and a family of functions , the funcCPA game proceeds as follows:

1. The challenger generates and gives to .
2. has access to a recryption oracle which, on input with and , returns .
3. outputs two messages .
4. The challenger samples , computes , and sends to .
5. retains access to .
6. outputs a guess .

The scheme is funcCPA-secure if the advantage is negligible for all PPT adversaries. A multi-input variant, funcCPA, where the oracle accepts multiple ciphertexts and a multi-variate function, has been shown equivalent to the baseline notion by Shinozaki, Tanaka, Tezuka, and Yoshida (ePrint 2024/1166).

Attacks & Relevance

The canonical deployment scenario is an FHE server that outsources bootstrapping to the client or to a secure enclave. Even though the enclave only sees masked values, the funcCPA model captures the adversary’s ability to adaptively choose which ciphertexts get refreshed and through which functions.

Some CPA-secure schemes become insecure when the adversary gains re-encryption access.

Fontaine, Renard, Sirdey, and Stan (ePrint 2025/2036) further showed that funcCPA-style extensions of CCA1 and vCCA (denoted CCA1R, CCA1M, vCCAR, vCCAM) all collapse back to their base notions. This means that the gap between CPA and funcCPA does not propagate to stronger notions: once a scheme is CCA1 or vCCA secure, adding recryption or multiplication oracles does not weaken it.

Achieving This Notion

Akavia, Gentry, Halevi, and Vald provided blueprints for constructing funcCPA-secure schemes from CPA-secure FHE. Any vCCA-secure scheme trivially achieves funcCPA. For concrete constructions, the “two-ciphertexts” construction based on Paillier, which achieves vCCA under a CPA + Linear-Only Homomorphism assumption, also achieves funcCPA as vCCA implies funcCPA.

Further Reading

The funcCPA notion was introduced by Akavia, Gentry, Halevi, and Vald (JoC 2025). The equivalence between funcCPA and funcCPA was established by Shinozaki, Tanaka, Tezuka, and Yoshida (ePrint 2024/1166). Dodis, Halevi, and Wichs (TCC 2023) further studied the setting where delegation targets a local client proxy. For the collapse of funcCPA-style CCA variants onto their base notions, see Fontaine, Renard, Sirdey, and Stan (ePrint 2025/2036).