Towards Blockchain-enabled Searchable Encryption

Qiang Tang

REVIEW 2 major objections 3 minor 19 references

Towards Blockchain-enabled Searchable Encryption

T0 review · 2 major / 3 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 1908.09564 v2 pith:X5IQ4VFA submitted 2019-08-26 cs.CR

Qiang Tang This is my paper · ORCID

classification cs.CR

keywords searchableencryptionblockchainfairnessprivacysmartcontractssymmetricverifiablesearchcryptographicdeposits

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

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.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

The 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.

What 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.

The 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.

There 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.

Who 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.

Referee Report

2 major / 3 minor

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.

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 (2)

[Section 4.2, Retrieval & Validation Phase, Dispute steps ii and iv] 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 4.2, Dispute step iv] 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.

minor comments (3)

[Section 1.2] 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 4.1, privacy discussion] 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 3.3, last paragraph] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the frameworks' fairness and privacy claims are argued from stated protocol construction and standard cryptographic abstractions, not from fitted inputs or self-citation chains.

full rationale

The paper does not present a derivation in which an output quantity is defined in terms of the claimed result, nor does it fit parameters to data and then rename the fit as a prediction. The central claims are construction-based: fairness is argued from deposits, signatures, commitments, and dispute-resolution steps, while privacy preservation is argued from the fact that, outside disputes, the blockchain stores only signatures, encrypted search results, and public keys, and that the underlying SSE scheme's Search and Setup are unchanged apart from the addition of a virtual identifier. The analysis of the prior blockchain-based solutions [4,10] is independent and does not rely on a self-citation chain. The only self-citations in the paper (e.g., reference [1] on asymmetric searchable encryption) are background and not load-bearing for the new frameworks' guarantees. The questionable step in the improved framework—exposing the encrypted index and trapdoor during dispute resolution—is a potential privacy flaw in the protocol's security analysis rather than a circularity: it is an asserted, under-justified claim about what information can be made public, not a reduction of the claimed conclusion to its own inputs. Therefore, no circular step matching the enumerated patterns is present, and the appropriate finding is a score of 0.

Assumptions & free parameters 1 free parameters · 6 assumptions · 1 invented entities

The central claims rest on standard cryptographic assumptions (signature, encryption, hash, consensus) plus two load-bearing assumptions specific to this paper: that any SSE Search can be executed in a smart contract, and that a signed trapdoor from the client is a correct trapdoor. The latter is contradicted by the paper's own discussion of malicious clients.

free parameters (1)

n (number of servers in initial framework)
Design parameter chosen by the client to satisfy the assumption that not all n servers collude; the paper gives no guidance on how to set it, and the fairness and privacy analysis depends on it.

assumptions (6)

domain assumption The underlying symmetric searchable encryption scheme has a deterministic Search procedure that returns a canonical ID_w for a given trapdoor and index.
The improved framework's dispute resolution (Section 4.2, Dispute step iv) re-executes Search on-chain and compares results; randomized or representation-dependent search would break verification.
ad hoc to paper The smart contract can execute the Search procedure of any underlying SSE scheme.
The Dispute function runs the SSE Search inside a smart contract; no implementation or complexity analysis is provided, and many SSE schemes use data structures that are expensive or impossible to execute on-chain. Location: Section 4.2, Dispute step iv.
domain assumption There exists an efficient zero-knowledge proof P1 proving that (id*_w, ID_w) is the plaintext of ciphertext C_w, and the smart contract can verify it.
The Dispute function relies on P1 to let the client prove the content of the ciphertext; no construction is given. Location: Section 4.2, Retrieval and Validation Phase.
domain assumption Only legitimate entities can write to the smart contract (unilateral integrity assumption).
Stated at the start of Section 4: there is no secure channel between entities and the blockchain, but only the legitimate entity can communicate with the smart contract, meaning a channel with integrity protection only.
domain assumption Blockchain consensus is secure under the standard semi-honest miner assumption, e.g., a majority of hash power for PoW is semi-honest.
Inherited from Section 2.2; the fairness guarantees rely on miners following the protocol and not colluding.
domain assumption The hash function H is modeled as a random oracle for privacy claims about H(ID||r) and id*_w.
The claim that the blockchain learns only random values relies on H behaving as a random oracle; Section 4.1: 'if H is modelled as a random oracle'.

invented entities (1)

Virtual identifier id*_w = H(K_w||ID_w)
purpose: Allows the client to verify that the server returned the correct file identifiers for keyword w during dispute resolution.
A new value introduced by the improved framework, defined in terms of the client's per-keyword key and the file identifiers; it has no falsifiable handle outside the protocol itself.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Towards Blockchain-enabled Searchable Encryption." pith.science (2026). https://pith.science/paper/X5IQ4VFA

@misc{pith2026190809564,
  author       = {Pith},
  title        = {Pith review of: Towards Blockchain-enabled Searchable Encryption},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/X5IQ4VFA}},
  note         = {Machine review of arXiv:1908.09564}
}

read the original abstract

Distributed Leger Technologies (DLTs), most notably Blockchain technologies, bring decentralised platforms that eliminate a single trusted third party and avoid the notorious single point of failure vulnerability. Since Nakamoto's Bitcoin cryptocurrency system, an enormous number of decentralised applications have been proposed on top of these technologies, aiming at more transparency and trustworthiness than their traditional counterparts. These applications spread over a lot of areas, e.g. financial services, healthcare, transportation, supply chain management, and cloud computing. While Blockchain brings transparency and decentralised trust intuitively due to the consensus of a (very large) group of nodes (or, miners), it introduces very subtle implications for other desirable properties such as privacy. In this work, we demonstrate these subtle implications for Blockchain-based searchable encryption solutions, which are one specific use case of cloud computing services. These solutions rely on Blockchain to achieve both the standard privacy property and the new fairness property, which requires that search operations are carried out faithfully and are rewarded accordingly. We show that directly replacing the server in an existing searchable encryption solution with a Blockchain will cause undesirable operational cost, privacy loss, and security vulnerabilities. The analysis results indicate that a dedicated server is still needed to achieve the desired privacy guarantee. To this end, we propose two frameworks which can be instantiated based on most existing searchable encryption schemes. Through analysing these two frameworks, we affirmatively show that a carefully engineered Blockchain-based solution can achieve the desired fairness property while preserving the privacy guarantee of the original searchable encryption scheme simultaneously.

Figures

Figures reproduced from arXiv: 1908.09564 by the authors.

**Figure 1.** Inverted Index Example 3. Using the private key(s), the client encrypts the inverted index and obtains an encrypted form of it. Note that the encryption here means not only the hiding of keyword and identifier information but also can be the hiding of other pattern information such as the ordering of the encrypted keywords and identifiers. Finally, the encrypted index is stored on the server. In the Search stage, if… view at source ↗

**Figure 2.** Blockchain Structure As the core characteristic of Blockchain, repeatedly, a certain number of new data entries (e.g. transactions) will be packed into a new block and appended to the existing (longest) chain. In the case of Bitcoin Blockchain, a new block also includes the hash value of the last block of the current chain. The block is formed with some specific features, e.g. a proof of work needs to be carried out… view at source ↗

**Figure 3.** Initial Design – Search† Stage: Given any keyword w, the search operation goes with the following phases. 1. Request phase: The client deposits a certain amount of money on the Blockchain. The money should cover the cost of search operations of the servers and the operational cost of Blockchain for the whole workflow (i.e. this and next phases). Simultaneously, the client chooses a random number r and sends it to al… view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Improved Design – For each keyword w ∈ W, besides the associated file identifier set IDw, the client generates a private key Kw and adds an additional virtual identifier id∗ w = H(Kw||IDw) where H is a cryptographic hash function and IDw denotes the concatenation of fi…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

19 extracted references · 17 canonical work pages

[1]

Arriaga, Q

A. Arriaga, Q. Tang, and P . Ryan. Trapdoor privacy in asymmetric searchable en- cryption schemes. In D. Pointcheval and D. Vergnaud, editors,Progress in Cryptology – AFRICACRYPT 2014, volume 8469 of LNCS, pages 31–50. Springer, 2014

work page 2014
[2]

Boneh, G

D. Boneh, G. Di Crescenzo, R. Ostrovsky, and G. Persiano. Public Key Encryption with Keyword Search. In C. Cachin and J. Camenisch, editors,Advances in Cryptology — EUROCRYPT 2004 , volume 3027 of LNCS, pages 506–522. Springer, 2004

work page 2004
[3]

Chai and G

Q. Chai and G. Gong. Veriﬁable symmetric searchable encryption for semi-honest- but-curious cloud servers. In Proceedings of IEEE International Conference on Commu- nications, ICC 2012, pages 917–922, 2012. 19

work page 2012
[4]

L. Chen, W. Lee, C. Chang, K. R. Choo, and N. Zhang. Blockchain based searchable encryption for electronic health record sharing.Future Generation Comp. Syst., 95:420– 429, 2019

work page 2019
[5]

Cheng, F

R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. M. Johnson, A. Juels, A. Miller, and D. Song. Ekiden: A platform for conﬁdentiality-preserving, trustworthy, and performant smart contracts. In IEEE European Symposium on Security and Privacy, EuroS&P 2019, pages 185–200, 2019

work page 2019
[6]

A. R. Choudhuri, M. Green, A. Jain, G. Kaptchuk, and I. Miers. Fairness in an unfair world: Fair multiparty computation from public bulletin boards. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security , pages 719–728, 2017

2017
[7]

Curtmola, J

R. Curtmola, J. Garay, S. Kamara, and R. Ostrovsky. Searchable symmetric encryp- tion: improved deﬁnitions and eﬃcient constructions. In Proceedings of the 13th ACM conference on Computer and Communications Security , pages 79–88. ACM, 2006

work page 2006
[8]

Diedrich

H. Diedrich. Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralised Au- tonomous Organisations. CreateSpace Independent Publishing Platform, 2016

work page 2016

Show all 19 references

[9]

Goldwasser and S

S. Goldwasser and S. Micali. Probabilistic encryption. J. Comput. Syst. Sci., 28(2):270– 299, 1984

1984
[10]

S. Hu, C. Cai, Q. Wang, W. Cong, X. Luo, and K. Ren. Searching an encrypted cloud meets blockchain: A decentralized, reliable and fair realization. In 2018 IEEE Conference on Computer Communications, INFOCOM 2018, pages 792–800. IEEE, 2018

2018
[11]

Nakamoto

S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf, 2008

2008
[12]

Narayanan, J

A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder. Bitcoin and Cryp- tocurrency T echnologies: A Comprehensive Introduction . Princeton University Press, 2016

2016
[13]

Narayanan and J

A. Narayanan and J. Clark. Bitcoin’s Academic Pedigree. Commun. ACM, 60(12):36– 45, November 2017

2017
[14]

T. P . Pedersen. Non-interactive and information-theoretic secure veriﬁable secret sharing. In Proceedings of the 11th Annual International Cryptology Conference on Ad- vances in Cryptology, pages 129–140, 1992

1992
[15]

M. Saad, J. Spaulding, L. Njilla, C. A. Kamhoua, S. Shetty, D. Nyang, and A. Mohaisen. Exploring the attack surface of blockchain: A systematic overview. http://arxiv.org/abs/1904.03487, 2019

1904 arXiv
[16]

D. X. Song, D. Wagner, and A. Perrig. Practical Techniques for Searches on Encrypted Data. In IEEE Symposium on Security and Privacy, pages 44–55. IEEE Computer Society, 2000

2000
[17]

M. Swan. Blockchain: Blueprint for a New Economy . O’Reilly, 2015

2015
[18]

D. Yaga, P . Mell, N. Roby, and K. Scarfone. Blockchain Technology Overview. https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf, 2018

2018
[19]

Zavodovski, S

A. Zavodovski, S. Bayhan, N. Mohan, W. Wong P . Zhou, and J. Kangasharju. Decloud: Truthful decentralized double auction for edge clouds. In International Conference on Distributed Computing Systems (ICDCS) , page to appear, 2019. 20

2019

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [1]

Arriaga, Q

A. Arriaga, Q. Tang, and P . Ryan. Trapdoor privacy in asymmetric searchable en- cryption schemes. In D. Pointcheval and D. Vergnaud, editors,Progress in Cryptology – AFRICACRYPT 2014, volume 8469 of LNCS, pages 31–50. Springer, 2014

work page 2014

[2] [2]

Boneh, G

D. Boneh, G. Di Crescenzo, R. Ostrovsky, and G. Persiano. Public Key Encryption with Keyword Search. In C. Cachin and J. Camenisch, editors,Advances in Cryptology — EUROCRYPT 2004 , volume 3027 of LNCS, pages 506–522. Springer, 2004

work page 2004

[3] [3]

Chai and G

Q. Chai and G. Gong. Veriﬁable symmetric searchable encryption for semi-honest- but-curious cloud servers. In Proceedings of IEEE International Conference on Commu- nications, ICC 2012, pages 917–922, 2012. 19

work page 2012

[4] [4]

L. Chen, W. Lee, C. Chang, K. R. Choo, and N. Zhang. Blockchain based searchable encryption for electronic health record sharing.Future Generation Comp. Syst., 95:420– 429, 2019

work page 2019

[5] [5]

Cheng, F

R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. M. Johnson, A. Juels, A. Miller, and D. Song. Ekiden: A platform for conﬁdentiality-preserving, trustworthy, and performant smart contracts. In IEEE European Symposium on Security and Privacy, EuroS&P 2019, pages 185–200, 2019

work page 2019

[6] [6]

A. R. Choudhuri, M. Green, A. Jain, G. Kaptchuk, and I. Miers. Fairness in an unfair world: Fair multiparty computation from public bulletin boards. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security , pages 719–728, 2017

2017

[7] [7]

Curtmola, J

R. Curtmola, J. Garay, S. Kamara, and R. Ostrovsky. Searchable symmetric encryp- tion: improved deﬁnitions and eﬃcient constructions. In Proceedings of the 13th ACM conference on Computer and Communications Security , pages 79–88. ACM, 2006

work page 2006

[8] [8]

Diedrich

H. Diedrich. Ethereum: Blockchains, Digital Assets, Smart Contracts, Decentralised Au- tonomous Organisations. CreateSpace Independent Publishing Platform, 2016

work page 2016