{"id":"cdf3e675-01fd-4c4d-8527-005f501df0ee","arxiv_id":"2504.18974","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"The paper identifies a simple undetectable model-stealing attack in multikey encrypted ML inference and proposes a verification-slot protocol that, as described, reveals the verification slot positions to the client, undermining its own security claim.","lead":"A new attack, called Silver Platter, lets a malicious cloud server leak a private AI model to a client without the model owner detecting it. The paper's proposed fix adds hidden verification slots, but as written the fix leaks the slot positions to the client, so the collusion it claims to stop can still succeed.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Result-checking step leaks y-slot positions to the client (or is unexecutable), so Theorem 1's (d/(d+m))^k bound does not hold.","rationale":"I read the full paper and centered on Theorem 1, which is the strongest claim: a colluding client and server cannot steal model parameters with non-negligible probability because the server cannot guess which slots are verified. The proof of that theorem depends entirely on the y-slot positions remaining unknown to both client and server. But the result-checking mechanism requires the client to compute a hash of g'(y), which in turn requires the client to know which slots are y. The paper itself flags this tension in Section 4.3.1 and refers to a zero-knowledge approach that is never supplied. This is an internal inconsistency, not a disagreement with an external consensus. If the client is given the y positions (or an indicator mask), a colluding server learns them and can place stolen parameters in the unverified x slots, making the success probability 1. If the client is not given the y positions, the protocol cannot be executed by an honest client. Either way, the proof of Theorem 1 does not establish the claimed bound. I credit the Silver Platter attack analysis as plausible and the probability tables as conditionally correct under the stated assumption, but the assumption is incompatible with the protocol's own verification step. The reader's REJECT verdict is therefore supported; I recommend no change to that verdict.","tokens_in":12567,"tokens_out":10781,"duration_ms":115509,"concrete_test":"Run a line-by-line trace of Algorithm 1 with a small concrete instance (e.g., d=8, m=2, random permutation) and give an honest client exactly the messages of Step 9: dec_p(encc,p(perm(f'(x),g'(y)))) and encp(rand). Verify whether the client can produce h(q(g'(y))) in Step 11 without being told the y indices; the trace fails if it cannot. Then add the minimal message that makes Step 10 possible (an indicator vector for the y slots) and recompute the undetected-substitution probability for a colluding client and server in Section 4.4: if the server, knowing those slots, overwrites only x slots, the success probability becomes 1 rather than (d/(d+m))^k.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The protocol's central bound is conditional on an assumption that the protocol itself cannot maintain. Section 4.3.1 states: 'The security of our proposed protocol relies on the client and server not knowing the indices of the y values.' But in Algorithm 1, Step 10 requires C to compute q(g'(y)) after Step 9, at which point C holds only the provider's partial decryption of the masked result and the rand vector. These messages contain masked values in every slot but do not mark which slots are y; without that marking an honest C cannot compute the hash required by Step 11. If P supplies a mask or indicator selecting the y slots, then C, and therefore a colluding S after one extra message, learns exactly the positions that Section 4.3.1 requires to be secret. S can then overwrite an x slot with a model parameter while leaving the y slots correct, so the provider's check passes with probability 1, contradicting Theorem 1's (d/(d+m))^k bound. The promised 'zero-knowledge approach discussed later in this section' is never specified, and no other mechanism prevents the position leak. Thus Theorem 1's proof does not cover the protocol as written.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper identifies a model-stealing attack, called the Silver Platter attack, against multikey FHE-based oblivious neural network inference, in which a malicious server returns encryptions of model parameters to the client instead of the computed result, and proposes SONNI, a mitigation that dedicates some ciphertext slots to a provider-chosen verification function g(y). The paper's central claim is Theorem 1, which bounds the probability of successfully stealing k model parameters by (d/(d+m))^k + ε1 + ε2, and it further claims security even when the client and server collude. The protocol's result-checking mechanism relies on the client and provider comparing hashes of a masked verification value g'(y), with a promised but unspecified zero-knowledge step to prevent a malicious provider from choosing incorrect slots.","tokens_in":12805,"tokens_out":9467,"duration_ms":97253,"significance":"The Silver Platter attack is a genuinely interesting and valid observation about the baseline protocol of Chen et al., and the paper correctly identifies that provider privacy in outsourced MLaaS deserves more attention. The idea of adding verification slots is intuitive and could be a useful building block. However, the central security proof is unsound: the results-checking step as specified either cannot be executed by an honest client or leaks the y-slot positions to the client, and the promised zero-knowledge mechanism that would address the acknowledged provider-attack is never supplied. Because Theorem 1 is the load-bearing claim of the paper, the manuscript does not establish its main stated contribution. The attack description and the quantitative discussion of verification-slot tradeoffs remain useful, but the proposed protocol would require a substantially different results-checking mechanism to support the paper's claims.","major_comments":[{"comment":"The security of SONNI is stated in Section 4.3.1 to rely on the client and server not knowing the indices of the y values. However, the protocol as written cannot be executed honestly without revealing those indices: in Algorithm 1, Step 9, the client receives a partial decryption of the full masked result vector perm(f'(x),g'(y)), and Step 10 requires the client to compute q(g'(y)) in order to send hash1 in Step 11. Since the decrypted vector contains both permuted x-values and permuted y-values, an honest client cannot isolate the g'(y) entries unless the provider supplies a mask or index set identifying the y slots. Section 4.3.2's statement that the client 'uses the mask provided by the provider' confirms that such a mask is intended. Once supplied, the mask reveals the y-slot positions to the client and hence to a colluding server. The server can then overwrite one or more x slots with model parameters while leaving all y slots correct, so the provider's hash comparison in Steps 11–14 passes with probability 1 (up to ε1 and ε2), contradicting the (d/(d+m))^k bound in Theorem 1. The 'zero-knowledge approach' promised in Section 4.3 is never specified, and the hash comparison described in Section 4.3.2 does not compensate for this position leak.","section":"Section 4.3 / Section 4.4"},{"comment":"The paper itself acknowledges that a malicious provider could specify incorrect indices so that the client computes and hashes f'(x) instead of g'(y), and it states that this is prevented by 'a zero-knowledge approach discussed later in this section.' No such zero-knowledge protocol appears anywhere in the manuscript. The only mechanism actually described is a hash comparison in Steps 11–14, which does not prove that the client used the correct slot selection. Consequently, Theorem 2's claim that a provider colluding with the server can learn x or f(x) only by breaking the encryption or the hash is not established by the protocol as written. This is a second load-bearing gap in the security analysis.","section":"Section 4.3 / Section 4.4"}],"minor_comments":[{"comment":"The notation 'rand = [-1,1]^{d+m}' is ambiguous: Section 4.3.2 says rand is a vector of random nonzero real values, while the algorithm notation suggests entries chosen from the interval or set {-1,1}. Please specify the exact distribution and how it interacts with the quantization step.","section":"Algorithm 1, Step 7"},{"comment":"The phrase 'f′(y) = f (y) × rand' appears to be a typo; earlier in the same paragraph the notation is defined as f′(x) = f(x) × rand.","section":"Section 4.3.2"},{"comment":"The text says 'In Figure 3, we analyze Theorem 1 quantitatively,' but no Figure 3 appears in the manuscript; the authors should either include the figure or remove the reference.","section":"Section 4.4"}],"recommendation":"reject","confidential_remarks":null},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First thing you should know: the Silver Platter attack is a small real observation, and the SONNI mitigation does not work as written. The attack deserves a place in the discussion of multikey FHE inference; the protocol does not.\n\nWhat's actually new: the observation that in the Chen et al. multikey setup, a malicious server can simply compute an encryption of the model parameters and send it in place of the output. No one detects it because the provider only sees encrypted values. That's a clean, valid attack, and it's undetectable in the original protocol. The proposed response—split the ciphertext slots into real data slots and decoy slots carrying a random g(y), then have the provider verify a hash of g(y) before releasing the final partial decryption—is a sensible direction, and the overhead analysis (batching reduced by ~0.2% for their numbers) is straightforward.\n\nThe soft spot is load-bearing. The claimed Theorem 1 bound assumes the client and server never learn which slots hold y. But the protocol as written has no way for the client to compute and hash g'(y) without being told which slots those are. If the provider sends a selection mask or index set, the client learns the y positions, and a colluding client can just tell the server. Then the server overwrites one x-slot per ciphertext with a parameter, leaves the y slots intact, and the provider's check passes with probability 1. The alternative reading—that the client is supposed to know somehow without being told—makes the protocol unexecutable. Either way, Theorem 1's (d/(d+m))^k bound does not follow from the protocol as described. The paper even promises a zero-knowledge mechanism to prevent the provider from learning f'(x) when specifying indices, but that mechanism is never specified; it's just deferred with 'discussed later in this section' and never appears. That's not a minor omission; it's the crux of the collusion resistance claim.\n\nThe evaluation numbers are honest, and the citations look fine. This is not a case of circular fitting. It's an unsoundness in the central proof.\n\nWho gets value from this: anyone working on FHE-based MLaaS should know the Silver Platter attack. The SONNI protocol in this form isn't usable. I'd send it to peer review because the attack is real and the protocol gap is exactly what a serious referee should catch; the authors could potentially fix the mask mechanism and the missing ZK check. But as written, the main security claim fails.","headline":"The Silver Platter attack is a valid and useful observation, but SONNI's verification step leaks the decoy-slot positions, so the central collusion-resistance theorem doesn't hold.","tokens_in":13271,"tokens_out":3632,"would_cite":false,"duration_ms":33581,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper identifies an undetectable model-stealing attack on multikey encrypted neural network inference, the Silver Platter attack, and proves a results-checking protocol, SONNI, bounds its success by…","keywords":["fully homomorphic encryption","multikey encryption","oblivious neural network inference","model stealing","Silver Platter attack","results checking","machine learning as a service","client privacy"],"falsifier":"Concretely, attempt the attack with a colluding client that has received the step-9 partial decryption and the step-10 mask, and check whether the client can determine the $y$-slot positions from its view; if it can, the $(\\frac{d}{d+m})^k$ bound no longer holds and a client-server pair can steal parameters while passing the hash check.","tokens_in":12394,"feed_emoji":"🛡️","tokens_out":9414,"duration_ms":86624,"temperature":0.7,"pith_summary":"The paper claims that the standard outsourced setting for homomorphic encrypted neural network inference has a silent hole: a malicious server can pass the provider's encrypted model parameters directly to the client in place of the inference result, and the provider will never detect it. The authors call this the Silver Platter attack, and show it defeats multikey encryption, which only stops simple collusion. To close the hole, they propose SONNI, a results-checking protocol in which the provider hides random verification values in some ciphertext slots, computes a companion function on them, and checks a masked hash of the result before helping the client decrypt. If the check passes, the provider can be confident the server computed honestly, and the paper proves the probability of successfully stealing $k$ model parameters is at most $(\\frac{d}{d+m})^k+\\varepsilon_1+\\varepsilon_2$, with $\\varepsilon_1,\\varepsilon_2$ negligible encryption and hash failure terms.","feed_headline":"Secret check slots stop undetectable model theft in encrypted ML","feed_subtitle":"SONNI hides random verification values in unused slots, so a colluding server and client are caught before model parameters leak.","key_machinery":"The load-bearing mechanism is the verification-slot construction: the provider secretly permutes the concatenation of the client's $d$ data slots and $m$ provider-chosen random values $y$, then defines a random function $g$ of the same form as $f$ so that both $f(x)$ and $g(y)$ are evaluated together by the server. The check itself is a masked, quantized hash comparison: the provider multiplies the result by a random vector, sends a partial decryption to the client, and compares $h(q(g'(y)))$ from both sides, so the provider is convinced the computation was correct without ever seeing $f(x)$. This mechanism converts an undetectable attack into a detectable one and trades a small number of ciphertext slots for an exponentially small success probability.","core_discovery":"SONNI's central claim is that provider privacy in outsourced inference can be protected even when the server and client collude, by making the provider's final decryption help conditional on a verifiable dummy computation. The provider appends random values $y$ to the client's data, secretly permutes the combined vector, and defines a random function $g$ of the same algebraic form as the model $f$. The server computes both $f(x)$ and $g(y)$ in the same ciphertext; the provider then masks the whole result with a random vector and asks the client to return a hash of the masked $g(y)$ values after partial decryption. If the hash matches the provider's plaintext computation, the provider releases the mask needed to recover $f(x)$. A server that wants to leak parameters must guess which slots are unverified, giving the theorem's $(\\frac{d}{d+m})^k$ bound; under the same scheme, a provider-server collusion cannot learn $x$ or $f(x)$ without breaking the encryption or the hash.","pith_inferences":["The theorem's $(\\frac{d}{d+m})^k$ bound depends on the verification-slot indices staying secret from both the client and the server; the protocol's own result-checking step gives the client a mask and a partial decryption, and if those reveal which slots hold $g(y)$, a colluding client could instruct the server to replace only $f$-slots, bypassing the check entirely. In particular, Section 4.3.1 s","The quantitative claims assume a single-round attack steals all $k$ parameters at once; a patient adversary stealing one parameter per query pays per-query costs, so the practical security level depends on the provider's pricing and query limits, not just on the probability bound.","The same slot-verification idea should extend to any outsourced FHE computation that evaluates a vector-valued arithmetic circuit, not only neural networks, by replacing $f$ and $g$ with any same-form pair of functions.","An implementation measuring actual wall-clock time, communication, and ciphertext expansion would be needed to see whether the 0.2% batching reduction translates into acceptable latency at realistic security parameters."],"forward_implications":["The multikey oblivious inference protocol that SONNI builds on, if used without a results-checking step, permits a malicious server to leak the entire model to the client with probability 1, and the provider cannot observe the leak.","With SONNI's checking in place, a server that steals one parameter per inference over the 32,768-parameter benchmark model has success probability $1.51\\times10^{-28}$ when only two slots are used for verification, and batching capability drops by just 0.2%.","Increasing the number of verification slots makes the bound decay quickly: with $m=32$ verification slots in a 1024-slot vector, stealing 512 parameters succeeds with probability about $7.07\\times10^{-11}$.","The client's data and result remain hidden from a provider-server collusion: the only avenues for leakage are breaking the underlying homomorphic encryption or the hash function, both assumed negligible.","When a check fails, the protocol aborts but does not reveal whether the server or the client caused the failure, which the paper leaves as an open problem."],"supporting_citations":[{"why":"Provides the efficient multikey packed-ciphertext oblivious inference protocol that SONNI builds on and that the Silver Platter attack exploits.","marker":"(Chen et al., 2019b)"},{"why":"Defines the CKKS approximate homomorphic encryption scheme whose vector-slot operations and noise behavior the protocol assumes.","marker":"(Cheon et al., 2017)"},{"why":"Introduces two-round multiparty computation via multikey FHE, the underlying model for partial decryption and combine.","marker":"(Mukherjee and Wichs, 2016)"},{"why":"Supplies the 32,768-parameter projection-matrix model used to compute the attack probabilities and the 0.2% batching overhead.","marker":"(Sperling et al., 2022)"},{"why":"Motivates why the provider cannot simply inspect the decrypted result, establishing the need for a blind verification step.","marker":"(Mai et al., 2018)"}],"fun_headline_variants":["Dummy slot checks catch model thieves in encrypted ML","Silver Platter attack blocked by verified decryption","SONNI thwarts collusion to steal neural net weights","Client-server secrecy even with malicious majority"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The protocol's security rests on the client and server never learning which ciphertext slots hold the verification values; if the client can identify those slots from the mask it is sent during results checking, the probability bound collapses.","fun_headline_variants_meta":{"raw":{"variants":["Dummy slot checks catch model thieves in encrypted ML","Silver Platter attack blocked by verified decryption","SONNI thwarts collusion to steal neural net weights","Client-server secrecy even with malicious majority"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000335,"raw_usage":{"total_tokens":1877,"prompt_tokens":982,"completion_tokens":895,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":598,"completion_tokens_details":{"reasoning_tokens":835}},"tokens_in":598,"tokens_out":895,"duration_ms":9117,"temperature":1.0,"reasoning_tokens":835,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T10:06:14.799514+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Concretely, attempt the attack with a colluding client that has received the step-9 partial decryption and the step-10 mask, and check whether the client can determine the $y$-slot positions from its view; if it can, the $(\\frac{d}{d+m})^k$ bound no longer holds and a client-server pair can steal parameters while passing the hash check.","supporting_citations":[{"cited_title":"and Wichs, D","cited_arxiv_id":null,"evidence_quote":"Introduces two-round multiparty computation via multikey FHE, the underlying model for partial decryption and combine."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the 32,768-parameter projection-matrix model used to compute the attack probabilities and the 0.2% batching overhead."},{"cited_title":"C., and Jain, A","cited_arxiv_id":null,"evidence_quote":"Motivates why the provider cannot simply inspect the decrypted result, establishing the need for a blind verification step."}],"review_version":1}