{"id":"8e059a1d-2c39-41fd-b51f-9effc13eec24","arxiv_id":"1908.09564","paper_version":2,"verdict":"REJECT","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"A design and analysis paper arguing that blockchain should only handle fairness and payments in searchable encryption, with dedicated servers doing the searching.","lead":"Searchable encryption hides data while allowing searches, and this paper examines what happens when the search server is replaced by a blockchain. It argues that fairness should live on the blockchain while actual searching stays on dedicated servers, and it proposes two frameworks to split the work that way.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Dispute resolution broadcasts the SSE index and trapdoor, letting any blockchain observer recover the query's access pattern; the claimed privacy preservation fails.","rationale":"The reader's REJECT verdict is sound, but the weakest assumption identified in the reader's report was the feasibility of executing the underlying SSE Search in a smart contract. This is a real concern, yet it is an implementation-level gap that could conceivably be repaired by choosing a simple SSE scheme or using verifiable computation. A more direct and structural flaw is that the dispute procedure publishes the encrypted index and a trapdoor on the blockchain, from which any observer can recompute the access pattern of the disputed query. Since the paper's central claim is that the improved framework preserves the privacy guarantee of the original searchable encryption scheme, and since Section 3.3 itself treats public access-pattern exposure as unacceptable, this contradiction is fatal to that claim even under ideal smart-contract execution. The proposed concrete test settles the issue by showing that the published dispute data is sufficient to recover the file identifiers, confirming that the framework fails its own privacy requirement.","tokens_in":13267,"tokens_out":10122,"duration_ms":106893,"concrete_test":"Instantiate the improved framework with a concrete SSE scheme (e.g., the Section 3.1 construction) and emulate the dispute on a public blockchain testbed: have the server publish I and Tw in the Dispute transaction. Then run the SSE Search algorithm off-chain using only I and Tw and confirm that it outputs the same ID_w that the contract would compute. This demonstrates that every blockchain observer can reconstruct the access pattern for the disputed query, contradicting the claim that the framework preserves the original scheme's privacy.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4.2's Dispute procedure (Retrieval and Validation Phase, steps ii and iv) requires the server to upload the signed encrypted index I and the trapdoor Tw to the smart contract, then runs the underlying Search over these inputs. These are blockchain transactions, and the paper explicitly argues that whether the blockchain is permissioned or permissionless does not affect the privacy guarantee. But in any SSE scheme matching the paper's own abstraction (Section 1.1), the trapdoor is precisely the value that, together with the encrypted index, enables Search to recover the file identifiers ID_w. Any party that can read the blockchain can take the public I and Tw, run the public Search algorithm locally, and reconstruct the exact access pattern for the disputed query. The original scheme's privacy guarantee tolerates this leakage only to the designated server; the dispute phase broadcasts it to all blockchain readers. Section 3.3 itself identifies access-pattern exposure to all blockchain participants as a central privacy failure of the [4,10] designs, so the improved framework is internally inconsistent with its own analysis when it claims that publishing the encrypted index and one trapdoor 'will not cause any privacy problem.' A malicious server can force a dispute, so this disclosure cannot be dismissed as a rare or voluntary event. This failure is independent of whether smart-contract execution of Search is technically feasible, making it the more load-bearing obstacle to the central claim.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper examines blockchain-based searchable encryption, focusing on two prior constructions that replace the traditional search server with a smart contract. It argues that this direct replacement causes high operational cost, security vulnerabilities, and — most importantly — amplifies privacy leakage: access and search patterns are exposed to all blockchain participants. The paper then proposes two modular frameworks in which dedicated server(s) perform the SSE search and the blockchain is used only for fairness (deposits, commitments, signatures, and dispute resolution). The initial framework uses multiple servers and commitments; the improved framework uses signed indexes/trapdoors, deposits, encrypted results, and a smart-contract Dispute function. The paper claims that the improved framework achieves the same fairness as prior blockchain solutions while preserving the privacy guarantee of the underlying SSE scheme.","tokens_in":13480,"tokens_out":5215,"duration_ms":53379,"significance":"If the central claim held, the modular design would be a valuable contribution: it correctly identifies a real tension between blockchain transparency and SSE privacy, and the critique of prior schemes is reasonable and useful. The paper also has the merit of explicitly limiting the blockchain's role and separating fairness from search execution. However, the claimed privacy/fairness guarantee of the improved framework is undermined by the dispute-resolution mechanism, which publicly exposes the very information that SSE is designed to protect. The paper does not provide formal definitions or proofs, and its feasibility claim for executing SSE search inside a smart contract is unsubstantiated. The conceptual contribution (that blockchain is not a drop-in replacement for the SSE server) is sound, but the proposed frameworks do not deliver the advertised property.","major_comments":[{"comment":"The dispute-resolution procedure requires the server to upload the encrypted index I and the trapdoor Tw to the blockchain, and the smart contract then runs the underlying Search algorithm on these inputs (step iv). In any SSE scheme matching the abstraction in Section 1.1, the pair (I, Tw) is precisely what enables recovery of the file-identifier set ID_w. Any party able to read the blockchain can download I and Tw and run the public Search algorithm locally, thereby obtaining the same access pattern that the original scheme only exposes to the designated server. This is exactly the leakage escalation the paper itself criticizes in Section 3.3 for permissioned and permissionless blockchains. The paper's statement in Section 4.2 that publishing 'only the encrypted index and one trapdoor' will not cause a privacy problem is therefore incorrect: that pair is the definition of what reveals the query's access pattern. Moreover, since a malicious server can force a dispute by returning an incorrect ciphertext, the disclosure is not a rare or voluntary event. This refutes the paper's central claim that the improved framework preserves the privacy guarantee of the underlying SSE scheme.","section":"Section 4.2, Retrieval & Validation Phase, Dispute steps ii and iv"},{"comment":"The Dispute function assumes that the smart contract can execute the Search procedure of the underlying SSE scheme on the uploaded encrypted index and trapdoor. The paper asserts this is possible for 'most existing searchable encryption schemes,' but no instantiation or feasibility analysis is provided. Many SSE constructions rely on data structures (e.g., hash tables, inverted indexes, trees, or ORAM-based layouts) or on client-specific state that cannot be efficiently or correctly implemented inside a smart contract under realistic gas limits, deterministic execution, and block-time constraints. Since the fairness guarantee depends on the contract performing this step correctly and completely, the claimed genericity of the framework is not established. If Search cannot be executed in the contract, the Dispute function cannot resolve disputes fairly, and the fairness property collapses.","section":"Section 4.2, Dispute step iv"}],"minor_comments":[{"comment":"There is a typo in 'infact' (should be 'in fact'), and the abstract uses 'Distributed Leger Technologies' instead of 'Ledger'; these and similar small errors should be corrected.","section":"Section 1.2"},{"comment":"The claim that a simulation-based secure SSE scheme leaks the same amount under collusion of all servers as under a single server is presented as a conjecture, not a proof; this should be clearly flagged as future work rather than being listed as an achieved property.","section":"Section 4.1, privacy discussion"},{"comment":"The suggestion to 'not send K2 to the smart contract and instead the client decrypts d by itself' is under-specified; the manuscript should explain how the client performs this decryption without the smart contract observing the intermediate plaintext, given that the contract must still process the search.","section":"Section 3.3, last paragraph"}],"recommendation":"reject","confidential_remarks":"The analysis of existing blockchain-based SSE solutions is a useful critical contribution, and the modular principle (blockchain for fairness, dedicated server for search) is worth articulating. However, the improved framework's dispute-resolution phase publicly reveals the encrypted index and trapdoor, which is exactly the information that discloses the query's access pattern; this directly contradicts the paper's central privacy claim. This is a load-bearing design flaw, not a local presentation issue: repairing it would require a fundamentally different dispute-resolution protocol (e.g., based on succinct arguments or a different trust model), which is beyond the scope of a light revision. The second major issue — the assumption that any SSE Search is executable in a smart contract — further undermines the claimed genericity. I therefore recommend rejection, though a substantially revised version that either drops the privacy-preservation claim or redesigns dispute resolution could be reconsidered."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe one thing to know: the paper's critique of existing blockchain-based searchable encryption is worth reading, but the improved framework's central privacy claim does not survive contact with its own dispute resolution. When the smart contract runs the Search procedure, it publishes the encrypted index and trapdoor on-chain; any observer can run Search and recover the access pattern, which is exactly the privacy amplification the paper condemns in Section 3.3.\n\nWhat is genuinely new: the analysis of [4,10] is solid. The paper correctly points out cost, forking, and the fact that permissionless blockchain exposes search pattern and access pattern to everyone. The modular architecture—blockchain only for deposits, commitments, signatures, and dispute resolution, with dedicated servers doing the search—is a sensible direction. The initial framework with n servers and commitments is a reasonable starting point, though it needs at least one honest server and offline dispute handling.\n\nThe soft spots are load-bearing. The improved framework (Section 4.2) tries to remove the honest-server assumption by making the client sign the trapdoor and index, and by having the smart contract arbitrate disputes via step iv of the Retrieval and Validation Phase. That step requires the smart contract to execute the underlying SSE Search on the public index and trapdoor. Two things go wrong. First, most SSE schemes' Search algorithms are not designed to run inside a smart contract; gas limits and data structure complexity make it impractical, and the paper gives no evidence it can be done. Second, and decisively, executing Search on-chain broadcasts the index and one trapdoor to every blockchain reader. Since the trapdoor is exactly what enables recovering the file identifiers, any observer can compute the query result and learn the access pattern. The paper claims this \"will not cause any privacy problem\" because only one trapdoor is exposed, but that is wrong: one trapdoor plus the index is sufficient to recover the matched IDs. A malicious server can force a dispute, so this is not a rare event.\n\nThere is also no formal model of fairness or privacy, and no proofs. The paper is honest about the malicious-client issue in the initial framework, but the improved framework's fix depends on the very on-chain execution that breaks privacy. I don't see a way to patch this without a different dispute mechanism.\n\nWho should read this: anyone working on blockchain-applied cryptography. The critique of prior work is useful; the framework designs are not ready for use. It deserves a serious referee to push the authors to either drop the dispute-via-smart-contract claim or redesign the arbitration so it does not leak the index/trapdoor. I would not desk-reject, but I would expect major revision or eventual withdrawal of the main claim.","headline":"The critique of existing blockchain-based searchable encryption is solid, but the improved framework's dispute resolution leaks the query's access pattern to every blockchain reader, breaking its core privacy claim.","tokens_in":14014,"tokens_out":5843,"would_cite":true,"duration_ms":57555,"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 claims that fairness in blockchain-enabled searchable encryption does not require putting search on the blockchain: keep the server, and use the blockchain as a deposit-holding arbiter.","keywords":["searchable encryption","blockchain","fairness","privacy","smart contracts","symmetric searchable encryption","verifiable search","cryptographic deposits"],"falsifier":"Take a concrete symmetric searchable encryption scheme whose Search involves operations a typical smart contract cannot perform, such as large random-access memory lookups or expensive cryptographic pairings, and instantiate the improved framework; if the Dispute function cannot complete within the gas limit or produces results different from the server's, the claimed fairness guarantee collapses.","tokens_in":13011,"feed_emoji":"🔐","tokens_out":4392,"duration_ms":42963,"temperature":0.7,"pith_summary":"The paper argues that using a blockchain as the search server in searchable encryption is a poor trade: it multiplies cost, exposes search and access patterns to everyone who can read the chain, and inherits blockchain security risks. Its central claim is that fairness can be achieved without those losses by keeping the search on a dedicated server and using the blockchain only to enforce payment and resolve disputes. Two generic frameworks are proposed, and the improved one is claimed to match the fairness of prior blockchain-based solutions while preserving the privacy guarantee of the underlying searchable encryption scheme. A sympathetic reader would take this as a design recipe: separate the search computation from the fairness enforcement.","feed_headline":"Fair private search needs a server plus a blockchain judge","feed_subtitle":"Directly replacing the server with a blockchain leaks search patterns; a dispute-only chain preserves privacy.","key_machinery":"The load-bearing mechanism is the separation of duties: a dedicated server runs the underlying searchable encryption Search, while the blockchain runs a fairness contract that manages deposits and holds signatures. The enabling identity is the virtual identifier $id^*_w = H(K_w\\|ID_w)$, an HMAC-like check value added to every keyword's file-identifier list; it lets the client verify search results locally and gives the contract a deterministic condition for judging disputes. The smart contract's Dispute function is the part that carries the fairness guarantee: it checks the signed trapdoor, verifies the signed index, checks a zero-knowledge proof tying the client's claimed results to the ciphertext, and then re-executes Search.","core_discovery":"The paper's core claim is that a carefully engineered blockchain-enabled searchable encryption solution can have both fairness and privacy: the encrypted index and trapdoors never go on-chain in normal operation, search stays with the original server, and the blockchain stores only deposits, signatures, commitments, hashes, and encrypted search results. The improved framework adds a virtual identifier $id^*_w = H(K_w\\|ID_w)$ to each keyword's file set and has the client sign the index and trapdoors, so a misbehaving server cannot deny its outputs; the smart contract resolves disputes by re-running the Search procedure on the signed index and trapdoor. If this is right, the fairness level matches existing blockchain-based solutions while the privacy leakage stays the same as the original scheme.","pith_inferences":["If smart contracts eventually execute searchable encryption Search efficiently, the improved framework's Dispute step becomes practical; until then the fairness guarantee is conditional on a capability the paper does not demonstrate.","The same deposit-and-dispute pattern may transfer to other outsourced computations where the client can generate a compact check value analogous to the virtual identifier, but full re-execution remains the arbiter.","The privacy claim under colluding servers relies on simulation-based security definitions; for schemes that are only indistinguishability-secure, running multiple server copies in the initial framework may leak more, a caveat the author flags as future work.","A testable extension would instantiate the improved framework with an SSE scheme whose Search is not trivially expressible in a smart contract and measure whether the Dispute function's gas cost stays within the deposited budget."],"forward_implications":["If the improved framework is sound, existing symmetric searchable encryption schemes can gain fairness without redesigning their search algorithms, just by adding signatures, a virtual identifier, deposits, and a dispute contract.","Because the chain sees only hashes, ciphertexts, and signatures during normal operation, permissionless and permissioned blockchains present the same privacy exposure; the client no longer depends on controlling who can read the chain.","The framework's overhead in the happy path is low: blockchain involvement is deposits, signature storage, and a final payment, with expensive dispute resolution triggered only when cheating is suspected.","The analysis draws a design boundary: directly transplanting the server role into a smart contract is not viable, so future blockchain-based search designs should treat the blockchain as an arbiter, not as the search engine."],"supporting_citations":[{"why":"One of the two existing blockchain-based searchable encryption solutions whose cost, privacy, and security flaws are analyzed; it also defines the fairness level the improved framework claims to match.","marker":"[4]"},{"why":"The other analyzed solution, providing the concrete construction where the smart contract performs the search and manages rewards.","marker":"[10]"},{"why":"Supplies the simulation-based security definition for searchable symmetric encryption used to argue that colluding servers leak no more than a single server.","marker":"[7]"},{"why":"Provides the commitment scheme used in the initial framework to commit to hashed search results on the blockchain.","marker":"[14]"},{"why":"Defines the symmetric searchable encryption setting and basic Setup/Search workflow that the proposed frameworks build on.","marker":"[16]"}],"fun_headline_variants":["Server + blockchain judge keeps search private and fair","Blockchain alone leaks search; add a server for privacy","Fair search needs a server, not a blockchain replacement","Privacy-preserving search: blockchain as dispute referee","Don't swap server for blockchain; keep both for fairness"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The fairness guarantee in the improved framework assumes that the smart contract can run the underlying searchable encryption scheme's Search on the uploaded encrypted index and signed trapdoor, correctly and at affordable cost.","fun_headline_variants_meta":{"raw":{"variants":["Server + blockchain judge keeps search private and fair","Blockchain alone leaks search; add a server for privacy","Fair search needs a server, not a blockchain replacement","Privacy-preserving search: blockchain as dispute referee","Don't swap server for blockchain; keep both for fairness"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00019,"raw_usage":{"total_tokens":1345,"prompt_tokens":959,"completion_tokens":386,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":575,"completion_tokens_details":{"reasoning_tokens":310}},"tokens_in":575,"tokens_out":386,"duration_ms":4086,"temperature":1.0,"reasoning_tokens":310,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T11:08:29.676225+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take a concrete symmetric searchable encryption scheme whose Search involves operations a typical smart contract cannot perform, such as large random-access memory lookups or expensive cryptographic pairings, and instantiate the improved framework; if the Dispute function cannot complete within the gas limit or produces results different from the server's, the claimed fairness guarantee collapses.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"One of the two existing blockchain-based searchable encryption solutions whose cost, privacy, and security flaws are analyzed; it also defines the fairness level the improved framework claims to match."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"The other analyzed solution, providing the concrete construction where the smart contract performs the search and manages rewards."},{"cited_title":"Curtmola, J","cited_arxiv_id":null,"evidence_quote":"Supplies the simulation-based security definition for searchable symmetric encryption used to argue that colluding servers leak no more than a single server."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the commitment scheme used in the initial framework to commit to hashed search results on the blockchain."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the symmetric searchable encryption setting and basic Setup/Search workflow that the proposed frameworks build on."}],"review_version":1}