Back to taxonomy
Constrained decryption oracle FHE-compatible

SA

Semi-Active Security

Introduced In

Relations

Implied By

vCCA

Implies

CPA

Overview

Semi-Active (SA) security, introduced by Walter, is an FHE security notion tailored to deployments in which the client (secret-key holder) keeps full control over which inputs are encrypted and which function the server is asked to evaluate. In such a client-server application, the client already knows the input ciphertexts and the function it wants executed, so it is in a position to check any ciphertext returned by the server against those inputs. SA formalises this “the client has state” setting, and Walter uses it to pin down exactly what extra privacy the client gains by pairing an IND-CPA FHE with a SNARG that proves correct evaluation. Walter’s paper focuses on the symmetric-key case because it simplifies the discussion, but the game itself works identically in the public-key and private-key settings — only whether the evaluation key is revealed to the adversary changes.

Compared to CPAD, the SA decryption oracle accepts externally computed ciphertexts: the adversary submits a ciphertext alongside a function and a list of indices into the encryption state, and the game decrypts provided the claimed computation does not itself reveal the challenge bit. The motivation is that in an FHE+SNARG application, the server returns an arbitrary ciphertext and the SNARG pins down how it was allegedly derived; SA models that pin-down as a constraint checked inside the decryption oracle. Unlike vCCA, no witness extractor is assumed — the adversary itself declares the derivation.

Walter proved that SA sits strictly between IND-CPA and IND-vCCA, and is incomparable with IND-CCA1, IND-CCVA, IND-CCA1.5, and funcCPA. In particular, none of these four notions implies SA and SA implies none of them — SA is a separate axis of strengthening, not a point on the classical CPA CCA1 CCA2 ladder.

Formal Definition

SA is defined for an FHE scheme whose decryption function is extended to take a ciphertext together with the function and input ciphertexts used to produce it, i.e. . The game is a multiple-challenge game structured like the IND-CPAD game, and it maintains an initially empty state of triples together with a hidden bit :

  1. Key generation. Run and give to . The game works identically in the private-key setting, where is not revealed to .

  2. Encryption request. On query : compute , return to , and set .

  3. Challenge request. On query with : compute , return to , and set .

  4. Decryption request. On query :

    • If any , return .
    • Let and .
    • If , return .
    • Otherwise return .
  5. Guessing stage. After polynomially many interleaved encryption, challenge, and decryption requests, outputs ; wins if .

The advantage is , and is IND-SA secure if this advantage is negligible for all PPT adversaries.

Two features are worth highlighting. First, the decryption oracle accepts an arbitrary ciphertext — the adversary is not restricted to submitting indices of ciphertexts produced by a game-internal , as in CPAD. Second, the indices must point into the encryption state; the ciphertexts threaded into are always fresh encryptions from the encryption/challenge requests, not intermediate evaluations. This single-hop structure is what keeps the game checkable without the game itself having to run .

Attacks & Relevance

Walter’s main reason to define SA is to answer the question “does a SNARG for correct evaluation actually buy any input privacy on top of the IND-CPA FHE it wraps?”. Under a CPA-secure FHE alone, a malicious server could tamper with the returned ciphertext and a decryption failure could leak information. The SNARG forces the server to commit to a function and input ciphertexts, which the client checks against what it sent; the SA game abstracts exactly this check into the test. Walter’s Lemma 6 formalises the positive result: an IND-CPA FHE paired with a sound SNARG for the “correct evaluation” relation is IND-SA secure.

Walter also establishes the following relational picture (§4 of the paper):

  • CPA SA vCCA (Lemma 1): SA is strictly stronger than CPA and strictly weaker than vCCA.
  • SA and CCA1 are incomparable. is Walter’s Lemma 3, instantiated by the §5 FHE+SNARG construction — essentially the [VKH23] scheme that Manulis and Nguyen showed not to be IND-CCA1 secure. The reverse follows from Lemma 2 combined with the trivial implication .
  • SA and CCVA are incomparable (Lemma 4 for the direction; the other direction follows from Lemma 2 and ).
  • SA and CCA1.5 are incomparable (Lemma 2 for ; Lemma 3 via gives the other direction since CCA1.5 CCA1).
  • SA and FuncCPA are incomparable (Lemma 5).

The practical takeaway is that SA is the right security target for a client-authoritative FHE+SNARG deployment, but is not a substitute for CCA1, CCVA, or CCA1.5 in settings where those apply — it sits on a different axis of the hierarchy.

Achieving This Notion

Walter’s Lemma 6 is the headline positive result. Let be an IND-CPA secure FHE scheme for function family with ciphertext space , and let be a sound SNARG for the relation

Define by having output where , and by having first run and return if verification rejects. Then is IND-SA secure. Crucially, the proof only needs ordinary SNARG soundness — no simulation-extractability, straightline extraction, or other non-black-box properties — which is a key practical advantage over the vCCA construction of Manulis and Nguyen.

Further Reading

The SA notion was introduced by Walter (ePrint 2024/1207). A presentation of SA alongside the rest of the FHE security landscape can be found in Renard (PhD thesis, 2025), §2.3.4. For the contrast with vCCA and the stronger notion it implies, see Manulis and Nguyen (Eurocrypt 2024). The state-tracking structure that SA inherits originates in the IND-CPAD game of Li and Micciancio (Eurocrypt 2021).