Introduced In
- What Have SNARGs Ever Done for FHE?
Michael Walter (2024)
Relations
Implied By
Implies
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
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
Formal Definition
SA is defined for an FHE scheme
-
Key generation. Run
and give to . The game works identically in the private-key setting, where is not revealed to . -
Encryption request. On query
: compute , return to , and set . -
Challenge request. On query
with : compute , return to , and set . -
Decryption request. On query
: - If any
, return . - Let
and . - If
, return . - Otherwise return
.
- If any
-
Guessing stage. After polynomially many interleaved encryption, challenge, and decryption requests,
outputs ; wins if .
The advantage is
Two features are worth highlighting. First, the decryption oracle accepts an arbitrary ciphertext
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
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
Define
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).