REVIEW 3 major objections 5 minor 6 references
Towards a DSL for hybrid secure computation
T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash
Pith's one-line read This paper proposes a DSL whose single abstract syntax tree can run on both FHE and TEE backends, letting one codebase serve hybrid secure computation.
desk verdict A plausible but seriously underspecified draft: the hybrid DSL idea is genuinely new, but the paper's central consistency claim rests on an AST semantics that is never actually defined. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The central object is the unified abstract syntax tree (AST) produced by parsing the DSL program, which is then executed by backend-specific interpreters. The design choices that make a single AST executable everywhere are the explicit encrypted/cleartext distinction in the language and the FHE-compatible control structure: if-else statements written as single-expression branches, and loops restricted to known-size vectors with no encrypted-data-dependent branching. The AST abstraction carries the portability argument because the program text no longer references any particular cryptography or hardware mechanism, and each backend's interpreter is responsible for mapping the tree to its own execution model.
What would settle it
Run the published covariance program on both backends with the same logical input values and program parameters, including edge cases such as empty vectors, length-one vectors, and values near the integer limit. Any mismatch in the output contexts, or any program that one backend executes while the other rejects, would falsify the claim of consistent behavior across backends.
Extended reading notes
Core claim
The central claim is that a unified abstract syntax tree can serve as a common representation for secure computation across FHE and TEE backends, so that the same source code does not have to be rewritten for each technology. The DSL distinguishes encrypted data from clear data, restricts control flow to forms FHE can support (each branch of an if-else holds a single expression, loop conditions must be known, and encrypted data cannot drive branching), and asserts consistent behavior on every backend. Execution is done by an interpreter in the chosen backend that imports an encrypted context containing inputs and returns an encrypted context containing outputs. The covariance example is presented as evidence that this design can express a realistic aggregation-style computation once and run it on both backends.
Load-bearing premise
The load-bearing premise is that the same abstract syntax tree has identical meaning in the TEE and FHE backends, so any program that runs correctly on one also runs correctly on the other; the paper asserts this consistency without a formal grammar, execution semantics, or proofs, and illustrates it with only one small covariance example.
Editorial extensions
If this is right
- A developer can keep a single source program and choose the FHE or TEE backend at deployment time based on available hardware or trust requirements.
- The set of programs that can be portable is exactly the set that respects the FHE constraints: single-expression branches, fixed-size loops, and no encrypted branching.
- The proposed DSL fills a gap left by single-technology DSLs and transpilers, which each require the developer to commit to one secure-computation technique.
- The measured covariance example shows that the TEE backend adds little overhead compared with the unprotected baseline, while the FHE backend remains far slower, so backend choice will still dominate runtime cost.
Reading between the lines
- A formal semantics for the AST would turn the DSL from a proof of concept into an interchange format: two parties could agree on one program text and each run it on their own backend, with the encrypted context as the interface.
- The same interpreter-over-AST design could plausibly extend to further backends, such as secure multiparty computation, because nothing in the architecture is specific to enclave hardware or to a particular homomorphic scheme.
- The consistency claim should be tested beyond the covariance example with a conformance suite that runs many programs on both backends and compares output contexts; a single example leaves semantic drift between backends undetected.
- Because vector-size metadata is deliberately outside the protection scope, the DSL is best suited to workloads with fixed or known shapes, not to streaming data where sizes themselves are sensitive.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper proposes a domain-specific language (DSL) for hybrid secure computation, with the goal of letting developers write a single codebase that can be executed on either a fully homomorphic encryption (FHE) backend or a trusted execution environment (TEE) backend. The proposed architecture parses a script into a unified abstract syntax tree (AST), which is then interpreted by the selected backend, and the paper gives one running example: computing the covariance of two integer arrays. Preliminary performance measurements show the TEE backend running close to a baseline, while the FHE backend is significantly slower. The related work section contrasts the proposal with single-backend DSLs and transpilers. The paper is explicitly preliminary and lists several future-work items.
Significance. If the central claim holds, the paper addresses a real and timely engineering problem: maintaining separate codebases for FHE and TEE in hybrid secure-computation workflows. The proposed single-DSL architecture is plausible and clearly communicated, and the covariance example gives a concrete, though tiny, demonstration of the intended programming style. The preliminary benchmark data points (TEE overhead near baseline, FHE roughly three orders of magnitude slower) would be a useful contribution if fully documented. The paper is honest about its preliminary status and gives hardware/software details for reproducibility. However, the manuscript does not currently substantiate its core claim: the language is not defined precisely enough to guarantee consistent behavior across backends, the example is too small to demonstrate expressiveness and contains an error, and the benchmark omits essential implementation details. The contribution is therefore better read as a vision statement than as a validated system proposal.
major comments (3)
- [Section 3 (Architecture)] The central claim is that a single DSL program, parsed into a unified AST, has 'consistent behavior across the different backends.' This claim is load-bearing but unsupported: the paper gives no grammar, typing rules, or operational semantics for the DSL, and no specification of what each AST node (arithmetic, division, comparison, if-expression, bounded loop, len, indexing, type conversion, declassification) denotes in each backend. Without this specification, two independent implementations of the FHE and TEE backends could disagree on, for example, integer overflow or division-by-zero semantics, and the single-codebase benefit would collapse. Please provide a precise language definition and a shared semantics, or explicitly narrow the claim to a specified subset and demonstrate that both backend interpreters implement that common semantics.
- [Section 3 and Figure 2] The only illustrative program, the covariance example in Figure 2, is too limited to establish the expressiveness of the DSL and contains a likely typo: line 10 uses 'len(xVec)' to compute yMean, where 'len(yVec)' is presumably intended; if the two arrays are not guaranteed to have equal length, the program is incorrect. Moreover, the example exercises only loops and basic arithmetic; it does not demonstrate the DSL's treatment of if-expressions, cleartext/encrypted type distinctions, or bounded loops, which are the language features claimed in Section 3. Please correct the typo and provide additional examples covering these constructs.
- [Section 4 and Figure 3] The benchmark is not reproducible as reported. The paper does not state which FHE scheme or library the 'tfhe' backend uses (e.g., Concrete/TFHE), the encryption parameters, the encoding of integers (signed/unsigned, bit-width), how division and 'len' are realized under encryption, or how an input context is fed to each backend. The figure also mixes units on the same chart (microseconds for baseline/TEE, milliseconds for TFHE), which obscures the comparison. Please document the backend implementations and present the performance data with consistent units and error bars.
minor comments (5)
- [Section 2] The first sentence uses 'interpretor'; this should be 'interpreter.'
- [Section 3] The paragraph on the tool says the AST is 'executed by the chosen backend' and later that all backends include an interpreter; please clarify whether the AST is interpreted, compiled, or both, since the terminology is ambiguous.
- [Section 4] The sentence 'the give algorithm' should be 'the given algorithm,' and the y-axis label in the TFHE panel of Figure 3, 'Time (m)', is ambiguous; use 'Time (ms)' or 'Time (s)' as appropriate.
- [Section 5] There is a typo, 'Howeover', which should be 'However'.
- [Section 5] The related-work section focuses on single-backend DSLs and transpilers but does not compare with general-purpose secure-computation interfaces (e.g., MPC frameworks or existing hybrid FHE/TEE orchestration efforts); discussing such work would help position the contribution.
Circularity Check
No significant circularity: the paper is a system/DSL proposal with an empirical demonstration, not a derivation from fitted inputs or self-citation chains.
full rationale
The manuscript proposes a DSL and reports a covariance example executed on TEE and FHE backends. There is no derivation chain in which a result is defined in terms of the very quantity it claims to predict, and no parameter is fitted to a subset of data and then relabeled as a prediction. The only self-reference is citation [2], the author's prior work on secure aggregation, which is used as contextual related work and does not supply any load-bearing assumption, equation, or uniqueness theorem for the DSL design or its evaluation. The paper's central limitation, noted by a skeptical reading, is that the unified AST semantics are asserted rather than formally specified, so cross-backend consistency is unproven; however, that is a correctness/soundness gap, not circularity. Because the paper makes no prediction derived by construction from its inputs, the appropriate circularity score is 0.
Assumptions & free parameters
assumptions (5)
- domain assumption Semi-honest (honest but curious) adversarial model
- domain assumption Metadata such as vector size is excluded from protection scope
- domain assumption Standard TEE adversary model where privileged OS is under adversary control, except the CPU
- domain assumption Presence of public-key infrastructure and secure communication primitives
- domain assumption FHE does not allow data-dependent branching
Cite this review
Pith. "Pith review of Towards a DSL for hybrid secure computation." pith.science (2026). https://pith.science/paper/RL4RIORU
@misc{pith2026250520912,
author = {Pith},
title = {Pith review of: Towards a DSL for hybrid secure computation},
year = {2026},
howpublished = {\url{https://pith.science/paper/RL4RIORU}},
note = {Machine review of arXiv:2505.20912}
}
read the original abstract
Fully homomorphic encryption (FHE) and trusted execution environments (TEE) are two approaches to provide confidentiality during data processing. Each approach has its own strengths and weaknesses. In certain scenarios, computations can be carried out in a hybrid environment, using both FHE and TEE. However, processing data in such hybrid settings presents challenges, as it requires to adapt and rewrite the algorithms for the chosen technique. We propose a domain-specific language (DSL) for secure computation that allows to express the computations to perform and execute them using a backend that leverages either FHE or TEE, depending on what is available.
Figures
Reference graph
Works this paper leans on
-
[1]
Eric Crockett, Chris Peikert, and Chad Sharp. 2018. ALCHEMY: A Language and Compiler for Homomorphic Encryption Made easY. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (Toronto, Canada) (CCS ’18) . Associ- ation for Computing Machinery, New York, NY, USA, 1020–1037. doi:10.1145/3243734.3243828
arXiv 2018
-
[2]
Romain de Laage, Peterson Yuhala, François-Xavier Wicht, Pascal Fel- ber, Christian Cachin, and Valerio Schiavoni. 2025. Practical Secure Aggregation by Combining Cryptography and Trusted Execution Envi- ronments. arXiv:2504.08325 [cs.CR] https://arxiv.org/abs/2504.08325
work page Pith review arXiv 2025
-
[3]
S. Gorantala et al. 2021. A General Purpose Transpiler for Fully Ho- momorphic Encryption. Cryptology ePrint Archive, Paper 2021/811. https://eprint.iacr.org/2021/811 Towards a DSL for hybrid secure computation
work page 2021
-
[4]
Abhiroop Sarkar, Robert Krook, Alejandro Russo, and Koen Claessen
-
[5]
Zama. 2022. Concrete: TFHE Compiler that converts python programs into FHE equivalent. https://github.com/zama-ai/concrete
work page 2022
-
[2023]
HasTEE: Programming Trusted Execution Environments with Haskell. In Proceedings of the 16th ACM SIGPLAN International Haskell Symposium (Seattle, WA, USA) (Haskell 2023). Association for Com- puting Machinery, New York, NY, USA, 72–88. doi:10.1145/3609026. 3609731
doi:10.1145/3609026 2023
Reviewed August 7, 2026 · model on record in the stance chip above.
Discussion (0). Sign in to comment.