{"id":"bfe47b78-a45f-49ad-9faf-f60bc8ac1b05","arxiv_id":"2505.16059","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A garbled-circuit implementation of STL robustness monitoring lets a system and a monitor compute a robustness score while keeping both the trace and the formula secret.","lead":"This paper builds a privacy-preserving correctness monitor for drones and other cyber-physical systems using garbled circuits, where the system and the monitor each keep their data secret and both learn only a robustness score. The authors show it can work and measure when it is fast enough for design testing, offline analysis, and online monitoring.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Variable clock-cycle count leaks formula information: the reported implementation does not meet the claimed privacy guarantee; cycle padding is mandatory but absent.","rationale":"The reader's weakest assumption — that the Verilog circuit may not correctly implement Algorithm 1 / STL robustness — is real and worth verifying, but it is not the single most load-bearing concern about the paper's central claim. If the circuit computes a wrong robustness value, the protocol is still privacy-preserving but the monitoring result is wrong; that is a correctness gap, not a direct refutation of the privacy theorem. The variable-cycle issue is more direct: the paper's own Fig. 6 and Sec. 6 admit that the number of clock cycles depends on the formula, and in garbled-circuit execution that term is observable to both parties. Yao's security definition compares the real protocol to an ideal functionality in which the parties learn only the output and input lengths; a protocol that additionally reveals the number of evaluation cycles does not realize that ideal functionality as stated. This is not a matter of consensus or style; it is an internal inconsistency between the claimed guarantee and the described implementation. The proposed fix, running for a fixed maximum number of cycles, is standard and straightforward, and the feasibility results would need to be re-measured under that padding. Because the defect is fixable and does not invalidate the overall approach, the conditional verdict is appropriate rather than outright rejection. The reader's correctness concern should remain as a condition as well, and an end-to-end differential test of the RTL against a reference implementation should be a prerequisite for acceptance.","tokens_in":14716,"tokens_out":8135,"duration_ms":79140,"concrete_test":"Run the synthesized netlist (or TinyGarble) on a fixed trace length N=100 and formula depth 3, using two formulas of the same depth with different temporal intervals, e.g., φ1 = ◇_{[0,∞)} p and φ2 = ◇_{[1e6,2e6)} p, on the same trace. Record the number of clock cycles from RTL simulation or TinyGarble execution. If the counts differ, the implementation leaks formula information through execution time. Then re-run with cycle padding to the maximum observed cycle count; if the padded version has a constant cycle count across all formulas of that depth and trace length, the privacy claim can be restored, but only with the padded runtime reported as the true cost.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central privacy claim — 'the system learns nothing about the formula' — is not satisfied by the implementation as presented, because the number of clock cycles the sequential circuit executes depends on the formula and the trace. Section 4.2 describes an FSM whose control path varies with the formula's operator types and temporal intervals (e.g., the U_ZERO_UNB branch for [0,∞) vs. bounded intervals), and Fig. 6 explicitly reports cycle counts that differ across formulas of the same depth for the same trace length. In a TinyGarble-style sequential garbled circuit, each clock cycle is a distinct garbled-evaluation step, and the number of such steps is observable to both parties through execution time and/or communication volume. The paper's own ideal-world model (Sec. 2.3) allows the parties to learn only the output and maximum input lengths, not the actual number of evaluation rounds. Thus the real protocol leaks more than the intended functionality. The paper acknowledges this in Sec. 6 ('To avoid leaking information about the provided formula through the number of clock cycles, an industrial implementation would run for a fixed number of cycles regardless of the formula'), but the reported implementation does not do this. This is a direct, self-admitted gap in the central privacy guarantee. A secondary concern is the unverified equivalence between the RTL circuit and DP-TALIRO, which would make the output the wrong function; however, the variable-cycle leak is more load-bearing because it refutes the privacy claim even if the circuit is functionally correct.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a privacy-preserving runtime monitoring protocol in which a Designer holds a timed trace and a Verifier holds an STL formula, and both parties learn only the robustness of the trace with respect to the formula. The protocol is based on garbled circuits: DP-TALIRO is implemented as a parameterized Verilog sequential circuit that accepts both the trace and the formula as inputs, the netlist is synthesized with Synopsys Design Compiler, and the resulting circuit is garbled and evaluated with TinyGarble. The paper reports circuit sizes, clock-cycle counts, software runtime, peak memory, and synthesis time for traces up to length 500 and formulas of depth 3 and 4, and concludes that the approach is feasible for design testing and offline monitoring and for short traces in online monitoring. The authors state that security is inherited from standard garbled-circuit security, and that correctness of the underlying algorithm is inherited from DP-TALIRO.","tokens_in":14988,"tokens_out":7587,"duration_ms":69677,"significance":"If the result holds, this is the first garbled-circuit implementation of STL robustness monitoring over timed state sequences, and it is a useful feasibility baseline for private runtime verification. The paper has real strengths: security is inherited from the standard Bellare-Hoang-Rogaway garbled-circuits model rather than from an ad hoc primitive; the circuit is parameterized by maximum trace length and formula depth, so the formula is an input rather than compiled per formula; and the experimental evaluation makes concrete, falsifiable claims about runtime, clock cycles, memory, and synthesis time. However, the strongest privacy claim is not met by the reported implementation because the number of clock cycles varies with the formula, and the correctness of the synthesized circuit relative to DP-TALIRO is asserted rather than demonstrated. Both issues are fixable, but they are load-bearing for the central contribution.","major_comments":[{"comment":"The implementation as reported does not realize the claimed guarantee that the system 'learns nothing about the formula.' The controller in §4.2 is an FSM whose control path depends on the formula's operator types and temporal intervals (e.g., the U_ZERO_UNB branch for [0,∞) and the looping branch for general [a,b) intervals), and Fig. 6 explicitly shows different clock-cycle counts for different formulas of the same depth and trace length. In a TinyGarble-style sequential garbled circuit, each clock cycle is a separate garbled-evaluation step, so the number of cycles is observable to both parties through execution time and communication volume. The ideal-world model in §2.3 allows leakage only of maximum input lengths and the output, not of the actual number of evaluation rounds. The paper itself acknowledges in §6 that 'an industrial implementation would run for a fixed number of cycles regardless of the formula,' confirming that the reported implementation is not constant-cycle. To meet the stated privacy claim, the protocol must fix a maximum cycle count and pad all evaluations to that count; the security statement and all reported measurements must then refer to the padded circuit.","section":"§4.2, §5.1, §6 (Fig. 6)"},{"comment":"The paper provides no correctness evidence that the Verilog RTL computes DP-TALIRO and hence the STL robustness function. Correctness of DP-TALIRO is cited to [29], and the RTL is described informally as a controller/datapath implementation of Algorithm 1, but there is no equivalence proof between Algorithm 1 and the RTL, no systematic test suite covering all operator types and interval boundary cases, and no theorem about the 32-bit fixed-point integer scaling introduced in §6 (signal values, timestamps, formula thresholds, and interval endpoints are all scaled by 10^5). If the synthesized circuit computes a different function than the true robustness, the privacy guarantee is vacuous because both parties learn the output of the wrong computation. A revision should add a formal or at least rigorous differential verification of the RTL and synthesized netlist against a reference DP-TALIRO implementation, including overflow behavior of the scaled arithmetic.","section":"§4.1–4.2, §6"},{"comment":"The paper's claim that runtime 'scales exponentially with the size of the inputs' and that 'execution time in software scales exponentially with the trace length' is not supported by its own complexity model. Section 5.2 bounds the total work and communication by O(C·cc·κ), Fig. 9 reports circuit size C as linear in trace length, and DP-TALIRO is a dynamic program over N_x·M table entries, so even a conservative bound on the clock-cycle count cc is polynomial in N_x and formula depth for the bounded loops used in this implementation. The steep increase visible in Fig. 5 may reflect implementation overheads or fitting artifacts, but the paper gives no fitted functional form or confidence bounds. Please replace the exponential claim with a precise statement about the measured clock-cycle scaling, or with fitted curves and their error measures, and adjust the practicability discussion in §6 and §7 accordingly.","section":"§5.2, §6 (Fig. 5), §7"},{"comment":"The empirical evaluation is the basis for the feasibility claims, but the manuscript provides no code, Verilog sources, synthesized netlists, or raw data. Without these artifacts, the reported runtimes, memory usage, and synthesis times cannot be reproduced, and the claimed equivalence of the synthesized circuit to DP-TALIRO cannot be checked beyond the illustrative example in Table 3. I request that the artifacts be made available with the revision; if this is impossible, the empirical claims should be explicitly marked as preliminary and the paper should state what would be needed to reproduce them.","section":"§6"}],"minor_comments":[{"comment":"In the Until robustness definition, the left-hand side uses the evaluation time variable t while the right-hand side uses the index i inside t^{-1}(t(i)+I); please make the notation consistent.","section":"§2.1, Eq. (5)"},{"comment":"Algorithm 1 returns R[1,1], while the text says 'the final value located at entry[0,0]'; Table 3 also uses row index 0. Please standardize the indexing convention.","section":"§4.1"},{"comment":"The fitted curves in Figs. 5–7 are described only as 'best fit'; please report the fitted functional forms and error measures, since the exponential-vs-polynomial interpretation in the text hinges on those curves.","section":"§6"},{"comment":"The sentence 'We show that privacy-preserving monitoring or CPS is indeed feasible' appears to contain a typo; it should likely read 'of CPS.'","section":"§1"},{"comment":"The claim that padding a shorter formula with 1-bits 'does not impact the robustness calculation' depends on the circuit's formula decoder treating padded subtrees as neutral for every operator encoding; please state this design invariant explicitly.","section":"§5.1"}],"recommendation":"major_revision","confidential_remarks":"The garbled-circuit machinery itself is standard and the construction is credible, but the variable-cycle-count leak is a genuine gap in the strongest privacy claim. I view it as fixable by constant-cycle padding and by re-running the evaluation with that padding, which is why I recommend major revision rather than rejection. I would also make artifact release a condition of acceptance, because the feasibility conclusions are empirical and the circuit-to-algorithm equivalence cannot be checked without the Verilog and netlists. The 'exponential runtime' wording should be corrected, as it is not justified by the paper's own complexity model."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis paper is the first to build a garbled-circuit monitor for STL robustness, and that is a genuine step. Prior work privatized safety-only LTL via FHE/DFA, which cannot handle STL's real-valued robustness and interval operators. The authors take DP-TALIRO, encode it as a sequential Verilog circuit that takes both trace and formula as inputs, and run it through TinyGarble. That yields a real cost model: runtime, memory, circuit size for trace lengths up to 500. The security argument is inherited from standard garbled-circuit security (Bellare-Hoang-Rogaway), and the authors are appropriately careful about what the ideal model does and does not leak. The paper is honestly written and the empirical evaluation is useful.\n\nThe soft spots are real but mostly fixable. The load-bearing one is the variable clock-cycle count. In a sequential garbled circuit, the number of evaluation rounds is visible to both parties, and the paper's own Fig. 6 shows cycle counts differing across formulas of the same depth. That means the implemented protocol leaks more than the ideal functionality: the Verifier's formula structure is partially revealed through runtime or communication volume. The paper acknowledges this in Sec. 6 and says an industrial implementation would run for a fixed number of cycles, but the reported experiments and the advertised privacy guarantee do not include that fix. This needs to be handled before the central claim \"the system learns nothing about the formula\" is defensible.\n\nSecond, the correctness of the Verilog circuit as an implementation of DP-TALIRO is taken on trust. There is no formal equivalence proof, no test suite over the formula space, and no discussion of the 32-bit fixed-point scaling's effect on robustness values. If the circuit computes the wrong function, privacy is preserved but the monitoring result is meaningless. This is addressable with a few pages of testing or a proof sketch.\n\nMinor: the claim that software runtime scales exponentially is not supported by the stated complexity model, which is O(C·cc·κ) with C linear in trace length and cc plausibly linear; the raw data may show super-linear behavior, but the text overstates it.\n\nOverall, the core idea is sound and the evaluation is a solid first cost model. The variable-cycle leak is a serious gap in the current implementation, but it is a known and fixable one. I would send this to review, with a clear request to address the cycle-count leak and the circuit-verification gap. The paper deserves referee time.","headline":"First garbled-circuit STL robustness monitor, but the variable-clock-cycle leak undercuts the privacy claim until a fixed-cycle implementation is used.","tokens_in":15518,"tokens_out":2177,"would_cite":true,"duration_ms":18307,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Garbled circuits can make runtime verification of cyber-physical systems privacy-preserving, so a monitor checks a system's timed trace against a secret specification and both parties learn only the robustness score.","keywords":["runtime verification","privacy-preserving monitoring","garbled circuits","multi-party computation","signal temporal logic","robustness semantics","cyber-physical systems","dynamic programming"],"falsifier":"Compare the circuit's output against a trusted reference implementation of DP-TALIRO on a large random corpus of traces and formulas; any input pair for which the sign or numeric value of $\\rho(x,\\varphi,0)$ differs would refute the claim that the circuit is a faithful robustness monitor.","tokens_in":14534,"feed_emoji":"🔒","tokens_out":9967,"duration_ms":83295,"temperature":0.7,"pith_summary":"This paper tries to establish that runtime verification of cyber-physical systems can be made privacy-preserving without giving up the quantitative information that engineers use: the robustness score. The proposed protocol lets a system owner (for example a drone operator) and a monitor (for example a traffic authority) jointly evaluate a Signal Temporal Logic formula on a timed trace, so that each party learns only the final robustness value at time zero. The monitor never sees the trace, and the system never sees the formula. The construction uses garbled circuits over a synthesized logic circuit that implements the DP-TALIRO dynamic program, and the experiments map where that construction is practical: feasible in software for short traces and shallow formulas, and promising in hardware for larger workloads. The authors answer their two research questions affirmatively: private robustness monitoring is implementable with garbled circuits, and it is practical under identifiable conditions.","feed_headline":"Garbled circuits make private runtime checks feasible","feed_subtitle":"Each side learns only the verdict, not the other party's formula or trace.","key_machinery":"The load-bearing object is a synthesizable hardware implementation of DP-TALIRO, a dynamic program that computes STL robustness by filling an $N_x \\times M$ table: one column per sub-formula, one row per trace sample, starting at the end of the trace and ending at $\\rho(x,\\varphi,0)$. The circuit is written as a controller-plus-datapath design in Verilog, with a finite-state machine handling the formula's syntax and a BOUNDS module computing the index ranges for temporal intervals; after synthesis the netlist is evaluated inside a sequential garbled-circuit protocol, which is what turns a public computation into a private two-party one. Because the formula itself is an input to the circuit, the same netlist serves any formula up to a fixed depth, so the circuit size does not leak the formula; only the agreed maximum depth and trace length are common knowledge. Sequential gates (flip-flops) keep the circuit small, and the protocol's communication complexity is $O(C \\cdot cc \\cdot \\kappa)$ bits for circuit size $C$, clock cycles $cc$, and security parameter $\\kappa$, while memory is $O(C\\cdot\\kappa)$.","core_discovery":"The central discovery is that the robustness-monitoring computation itself—not just satisfiability—can be run inside a garbled circuit, so the quantitative verdict is private by construction. The protocol has two parties: the Designer, who holds a finite timed trace of samples, and the Verifier, who holds an STL formula. They agree on a circuit that accepts both as inputs and outputs the robustness value $\\rho(x,\\varphi,0)$; following the garbled-circuit protocol, each party learns this value and nothing else beyond input lengths, with formulas padded to a fixed maximum depth to hide their true length. The circuit implements the DP-TALIRO dynamic program, which fills a table of robustness values indexed by trace positions and sub-formulas, and a BOUNDS subroutine that finds the timestamps inside a temporal interval. The paper reports that a gate-level netlist synthesized from Verilog, evaluated through a sequential garbled-circuit engine, computes robustness for traces up to length 500 and formulas of depth 4, with memory use linear in trace length and runtime growing roughly exponentially in trace length in software, while the number of hardware clock cycles suggests that a hardware implementation would be much faster. The authors take this as evidence that private monitoring is feasible today for testing and offline monitoring, and would be practical online once garbled circuits run in hardware.","pith_inferences":["The paper leaves implicit that padding formulas and traces to fixed maxima converts the protocol's known input-length leakage into merely an upper bound, so a deployment could pad beyond the actual values and reveal even less than the nominal lengths.","The semi-honest threat model is what the measurements target; hardening the protocol against a malicious system owner or monitor would require additional proofs or zero-knowledge machinery, and the added overhead is not included in the reported runtimes.","A hardware garbled-circuit engine is the natural next experiment: running the same netlist on such an engine would directly test the authors' conjecture that online monitoring becomes practical, and would let engineers measure whether the 19 ms estimate holds at full circuit scale."],"forward_implications":["In software, the private monitor is fast enough for short inputs: a trace of length 10 with a depth-3 formula takes about one second, which is acceptable in a testing loop when simulation of the system under test dominates the cost.","Peak memory grows linearly with trace length, so a device with 1 GB of RAM can in principle handle a trace of 500 samples and a depth-4 formula, making embedded deployment plausible on the memory axis.","Because the synthesized circuit is independent of the particular formula and trace, it can be synthesized once, offline, on a powerful machine and then reused for arbitrary monitoring sessions, amortizing the high synthesis cost.","If garbled circuits are implemented directly in hardware, the measured clock-cycle counts indicate online monitoring could become practical; the paper estimates 40,000 cycles at 2.1 GHz as 19 ms, which is in the range of real-time control loops."],"supporting_citations":[{"why":"It supplies the DP-TALIRO dynamic-programming algorithm whose correctness the circuit inherits.","marker":"[29]"},{"why":"It provides the foundational definition and proof that garbled circuits hide everything except inputs and output, the paper's privacy guarantee.","marker":"[3]"},{"why":"It supplies the sequential garbled-circuit engine used to evaluate the synthesized netlist, which the feasibility claim depends on.","marker":"[19]"},{"why":"It defines the robustness semantics for temporal logic over continuous signals that the quantitative verdict is based on.","marker":"[11]"},{"why":"It introduces the Signal Temporal Logic over analog and timed traces that the monitor evaluates.","marker":"[15]"},{"why":"It provides the hardware garbled-circuit baseline and benchmark sizes against which the paper judges the practicality of a hardware implementation.","marker":"[13]"}],"fun_headline_variants":["Garbled circuits keep specs and traces private during monitoring","Only the verdict is shared in this privacy-preserving monitor","Private runtime verification: each side learns just the robustness","Monitor in the dark: garbled circuits hide both formula and data","Feasible private monitoring with garbled circuits, says study"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole practical claim rests on the synthesized circuit computing exactly the same robustness values as DP-TALIRO on fixed 32-bit scaled integers; the paper gives no formal equivalence proof between the Verilog and the algorithm, so a silent bug in the circuit would produce a wrong verdict while still satisfying the privacy guarantee.","fun_headline_variants_meta":{"raw":{"variants":["Garbled circuits keep specs and traces private during monitoring","Only the verdict is shared in this privacy-preserving monitor","Private runtime verification: each side learns just the robustness","Monitor in the dark: garbled circuits hide both formula and data","Feasible private monitoring with garbled circuits, says study"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000254,"raw_usage":{"total_tokens":1600,"prompt_tokens":1009,"completion_tokens":591,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":625,"completion_tokens_details":{"reasoning_tokens":508}},"tokens_in":625,"tokens_out":591,"duration_ms":6697,"temperature":1.0,"reasoning_tokens":508,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T15:07:11.312157+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Compare the circuit's output against a trusted reference implementation of DP-TALIRO on a large random corpus of traces and formulas; any input pair for which the sign or numeric value of $\\rho(x,\\varphi,0)$ differs would refute the claim that the circuit is a faithful robustness monitor.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It supplies the DP-TALIRO dynamic-programming algorithm whose correctness the circuit inherits."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It supplies the sequential garbled-circuit engine used to evaluate the synthesized netlist, which the feasibility claim depends on."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It introduces the Signal Temporal Logic over analog and timed traces that the monitor evaluates."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It provides the hardware garbled-circuit baseline and benchmark sizes against which the paper judges the practicality of a hardware implementation."}],"review_version":1}