Fidelis: Veriﬁable Keyword Search with No Trust Assumption

Laltu Sardar

1 a

and Subhra Mazumdar

2 b

Institute for Advancing Intelligence, TCG-CREST, Kolkata, India

TU Wien and Christian Doppler Laboratory Blockchain Technologies for the Internet of Things, Vienna, Austria

Keywords:

Searchable Encryption, Keyword Search, Fair Payment, Smart Contract, No-Trust Assumption.

Abstract:

A searchable encryption (SE) scheme allows a client to outsource its data to a cloud service provider (CSP)

without the fear of leaking sensitive information. The latter can search over the outsourced data based on the

client’s query. Such a scheme prevents a malicious CSP from sending incorrect results. However, a malicious

client can deny receipt of the correct result and wrongly blame the CSP. Existing SE schemes fail when the

client acts maliciously.

In this paper, we have studied searchable encryption schemes where none of the parties trust each other. We

propose Fidelis, a novel blockchain-based SE scheme, with keyword-search functionality, that is veriﬁable

by both parties. None of the parties can cheat, and an honest CSP gets payment upon providing the result.

We implement and evaluate an instance of the protocol on real-life data using Ethereum as the blockchain

platform, deploying it in the Ropsten test network. Upon comparing with existing schemes, we observe that

our protocol is efﬁcient and scalable.

1 INTRODUCTION

Outsourcing storage, as well as computation to a

cloud service provider (CSP), has acquired signiﬁ-

cant popularity among Small and Medium-sized En-

terprises (SMEs). Outsourcing increases security ef-

fectiveness and reduces maintenance costs. However,

directly uploading the data in plaintext form to cloud

service providers (CSP) is subject to risk. An unau-

thorized person can misuse or steal the data stored in

the cloud. To counter the issue, a different encryption

technique called searchable encryption (SE) is used.

SE allows a user to outsource its data in an encrypted

form to a cloud service provider. The cloud can per-

form any number of queries over that encrypted data

at the request of the client. In this process, the client

reveals some controlled amount of information about

the data to the CSP. Thus, privacy of such schemes

is determined by the amount of leakage upon query-

ing over the encrypted database. A malicious server

may not return the correct result, but the users should

have the ability to check whether the result is com-

plete and derived from the actual state of the database.

This is possible only when the client can verify an SE

scheme. A client can be malicious and try to cheat

https://orcid.org/0000-0002-7433-0497

https://orcid.org/0000-0002-3089-2535

CSP. If the client is the only one involved in veriﬁca-

tion, it can intentionally claim that it got an incorrect

result to avoid paying the CSP. So, when none of the

parties are trusted, we need an SE scheme that is ver-

iﬁable by both parties. Blockchain provides service

integrity for storage as well as computation. In ad-

dition, by using Ethereum-based smart contracts (Bu-

terin, 2020), all operations can be executed automat-

ically and trustfully. It efﬁciently makes data sharing

convenient (Jiang et al., 2019).

However, it is a challenging task to outsource

data in an untrusted distributed environment without

leaking a signiﬁcant amount of information about the

dataset and queries. In most of the previous works

(Fan et al., 2020),(Wang et al., 2018),(Sardar and Ruj,

2019), the client is assumed to be honest. Some recent

work, such as Jiang et al. (Jiang et al., 2019) consider

a fully-malicious setup where the client can behave

maliciously from the beginning of the protocol. They

used cloud storage to store encrypted ﬁles and smart

contracts to store encrypted indexes for a single key-

word search. However, the actual result of a search

is not returned. Secondly, the blockchain is simply

used as veriﬁable storage, incurring a high cost. Guo

et al. (Guo et al., 2020) used the smart contract to

store the veriﬁcation tag. Thus, in both cases, most

of the computation is done either by the client (Jiang

698

Sardar, L. and Mazumdar, S.

Fidelis: Veriﬁable Keyword Search with No Trust Assumption.

DOI: 10.5220/0012082700003555

In Proceedings of the 20th International Conference on Security and Cryptography (SECRYPT 2023), pages 698-703

ISBN: 978-989-758-666-8; ISSN: 2184-7711

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

et al., 2019) or by the server (Guo et al., 2020), and

the blockchain is used for storage purposes.

In another work (Guo et al., 2022), the authors

have proposed a solution where both the cloud server

and the client are malicious, but their schemes con-

sider the client to be quasi-malicious. The assump-

tion is used for all existing schemes, including (Li

et al., 2020), (Guo et al., 2020), (Miao et al., 2022)

etc. These schemes fail when the client uploads in-

correct encrypted data and/or manipulated encrypted

search index. If the pre-computed search results and

veriﬁcation information are incorrect, there is no way

for the CSP to check. Such a client can cheat and deny

payment to the cloud, even if the latter has performed

the search correctly. Our aim is to suggest a scheme

that addresses all these shortcomings.

Our Contribution: We propose a novel single key-

word search scheme called Fidelis that aims to pro-

vide veriﬁability without requiring any trust assump-

tions. To achieve this goal, we utilize the Ethereum

blockchain platform to enable fair interactions be-

tween the cloud and the client. Unlike other schemes,

we do not store any data on the blockchain except

for certain constant-size information that is crucial

for valid search and result veriﬁcation. Our proto-

col ensures fairness and conﬁdentiality even in the

presence of fully malicious participants. Addition-

ally, we develop prototypes and test them on the Rop-

sten test network using real-world data. Our experi-

mental analysis indicates that our proposed scheme is

highly efﬁcient and feasible to implement, making it

a promising solution for practical use cases.

Organization: Section 2 presents necessary back-

ground knowledge. Section 3 provides detailed de-

scription of Fidelis. In Section 4, we evaluate the efﬁ-

ciency of Fidelis. We conclude the paper in Section 5.

2 PRELIMINARIES

System and Adversarial Model: There are three enti-

ties - owner, server and user.

The owner of the database Owner (O) is fully-

malicious and may follow two strategies: (a) correctly

uploading data and search index but falsely blaming

the cloud to obtain search results without payment,

or (b) manipulating the data initially to obtain search

results without payment.

Server (S) stores encrypted data and search index, and

provides storage and computation services. It may in-

tentionally provide incomplete or incorrect results to

reduce its costs, and is considered fully malicious.

User (U) is a client who uses the database. The owner

can also be one of the users. It is fully-malicious as

owner. We assume, the owner and the users belong

to the same organization, a user trusts the owner, and

the owner will never collude with the server to cheat

a user.

Apart from these, Blockchain (B) used here is a public

blockchain (e.g. Ethereum) that helps to verify the

execution of the search protocol. The client may act

as an owner of the database as well as the user.

TSet: A tuple set TSet (Cash et al., 2013) is a

data structure consisting of a tuple of algorithms

(TSetSetup,TSetGetTag,TSetRetrieve) brieﬂy

described as follow.

• TSetSetup takes as input a security parameter λ

and an array T of lists of equal-length bit strings in-

dexed by the elements of W . It outputs a pair (TSet,

) where TSet is a tuple set data structure and K

is a key. Thus TSetSetup initiates the tuple set data

structure TSet and chooses a key K

at random.

• TSetGetTag takes as input the key K

and a key-

word w and outputs a search trapdoor stag

∈{0,1}

• TSetRetrieve takes the TSet and a search trap-

door stag

as input and returns a list of strings.

We say that a TSet is correct if for all W , T,

and any w ∈W , TSetRetrieve(TSet,stag

) =T[w]

when (TSet,K

) ← TSetSetup(T) and stag

←

TSetGetTag(K

,w).

Interval based Sorted Merkle Tree (IbSMT): Since

we only require non-membership proof, we take

interval-based sorted Merkle tree (IbSMT). IbSMT is

the same as SMT (as Sorted Merkle Tree) (Dahlberg

et al., 2016) except for the leaves. For example, given

a sorted set S = {x

,... ,x

}, SMT keeps x

s in the

leaf node. However, IbSMT uses elements of

S =

,... ,y

} as its leaf node, where y

= x

||x

i+1

The two additional elements, x

and x

n+1

, are the

minimum and maximum bound and ∀i ∈ [1,n],x

∈

n+1

). x

and x

n+1

can be taken as bit-strings of

all 0 and 1 respectively. An IbSMT data structure con-

sists of three algorithms - BuildTree, NMSearch and

NMVerify:

• IbSMT ←BuildTree(S): It takes a set S and outputs

the sorted Merkle tree IbSMT where the leaves are the

intervals constructed as above, i,e., elements from

• pf

← NMSearch(IbSMT,x): Given an element x,

the algorithm ﬁnds two x

and x

i+1

such that x

< x <

i+1

and outputs the membership proof pf

for the

interval y

←x

||x

i+1

S. p f

is the non-membership

proof of x in S.

• b ← NMVeri f y(IbSMT.root, pf

,x): It outputs

membership veriﬁcation bit b result for x and the

Fidelis: Veriﬁable Keyword Search with No Trust Assumption

699

proof pf

. The veriﬁcation is done with the help of

the root of IbSMT.

Deﬁnitions and Terminologies: We deﬁne a ver-

iﬁable keyword search scheme VKS as a tuple of

algorithms (KeyGen, Build, SrchTknGen, Search,

VerifySrch) brieﬂy described as follows.

• K ← KeyGen(1

): is a Probabilistic Polynomial

Time (PPT) algorithm run by the O that takes a se-

curity parameter 1

and outputs secret key K.

• (EDB,ξ,α) ← Build(DB,K): O runs this PPT al-

gorithm that takes the dataset DB and the secret key

K as input and outputs an encrypted database EDB,

an encrypted index ξ, and auxiliary data α. α consists

of two parts α

and α

that are stored by the owner

and the server, respectively.

• τ

← SrchTkn(w, K): O runs this PPT algorithm

that generates an encrypted search trapdoor τ

for a

keyword w with the help of K.

•(R

, pf

) ←Search(ξ,α

,τ

): with this PPT algo-

rithm, S searches over ξ for τ

and returns the search

result R

to the client together with a proof pf

• b

← VerifySrch(R

, pf

,α

): Given the result

, proof p f

and auxiliary data α

, U runs this PPT

algorithm, interacting with cloud, and outputs the ver-

iﬁcation bit b

Correctness: Given a security parameter λ ∈N, a ver-

iﬁable keyword search scheme is said to be correct, if

for any key K generated using KeyGen(1

) and for all

sequences of search operations, the algorithm Search

outputs the correct set of identiﬁers, except with a

negligible probability, and for each received correct

result, the result will be veriﬁed correctly by the algo-

rithm VerifySrch.

3 OUR PROPOSED SCHEME

The steps of the protocol Fidelis are encoded in the

smart contract. Owner shares the encrypted database

with the cloud server and sends the keyword space to

the user. The latter needs to pay the cloud server for

retrieval of data against a query. This is enabled by

locking coins, denominated in the native currency of

the blockchain, in the smart contract. User sends a

query to the server and the latter returns the result. If

the server has performed his actions correctly, it gets

the coins, else the coins are refunded to the user. The

outline of the protocol is provided in Fig. 1.

Initialization: A tuple of keys, K = (K

), is

generated by the owner. K

is a λ-bit string, taken

at random, used to encrypt the keywords that a user

Cloud

User

Smart

Contract

4. Complain

If User malicious

Initialized

Locked

Complain not valid

Complain valid

Server

Initialization

Query

Validity

Response

Payout

Complain valid

Refund on Lock

Pay on Reveal

Complain valid

9. Reveal

If response

not correct

Owner

Figure 1: Outline of the protocol.

intends to query.

is a λ-bit string, taken at ran-

dom, used to compute veriﬁcation tags corresponding

to each queried keyword. A pseudo-random function

(PRF) F : {0,1}

×{0,1}

→ {0, 1}

is used for en-

cryption using keys K

and

. Different hash func-

Algorithm 1: Fidelis.Init(DB).

−→ {0,1}

for PRF F

Parse DB as {id

,... ,id

}

Find {W

,... ,W

}

W ← ∪

i=1

; StgSET = φ; T = φ

for w ∈ W do

Initialize t to be an empty list

Set K

← F(K

,w); vtag

← H

(

,w)

for i = 1 to n

= |DB(w)| do

← Sym.Enc(K

,id

)

append e

to t.

end

← H

(vtag

||e

||... ||e

)

append h

to t.

Set T[w] ← t.

end

(TSet,K

) ← TSetSetup(T).

for each w ∈ W do

stag

← TSetGetTag(K

,w)

StgSET ← StgSET ∪{stag

}

end

IbSMT = BuildTree(StgSET)

O keeps K = (K

)

O sends EDB, ξ = TSet,IbSMT to S.

SECRYPT 2023 - 20th International Conference on Security and Cryptography

700

tions H

, H

, and H

are used for generating commit-

ments. Each of them is a cryptographic one-way hash

function {0,1}

∗

→ {0,1}

. The owner uses a sym-

metric encryption Sym to encrypt each ﬁle in DB and

generates EDB. We assume every encrypted ﬁle f

can be accessed with the identiﬁer id

, and the owner

gives this encryption key to the users.

We use the TSet (see Section 2) data structure

to construct encrypted index for the database DB =

{id

: i = 1,..., d}. Let W = ∪

i=1

be the set of

keywords present in DB where W

is the set of key-

words in the ﬁle with identiﬁer id

. For each keyword

w ∈ W , a list t = [e

,... ,e

] is generated by

the owner. We deﬁne DB(w) ⊂ DB as the set of ﬁle

identiﬁers that contain the keyword w and n

is the

cardinality of DB(w). e

← Sym.Enc(K

,id

),1 ≤

i ≤n

is the encrypted identiﬁers of the ﬁles contain-

ing w and h

←H(vtag

||e

||... ||e

) is the hash

value that binds the set of identiﬁers and vtag

. Here

vtag

= H

(

,w) is the veriﬁcation tag used to ver-

ify the correctness of search results. An array T of

length W is used to store the list t for each keyword,

i.e., T[w] =t. Finally, TSet for the array T is gener-

ated as (TSet,K

) ← TSetSetup(T).

We encrypt each keyword w ∈ W using key K

generate stag

, and store it in StgSET. The encryp-

tion is done by TSetSetup. An IbSMT is built for

StgSET. The key K = (K

) and root of IbSMT,

deﬁned α

= IbSMT.root, are shared with the user.

The encrypted search index ξ = TSet is outsourced

to the cloud along with α

= IbSMT. Algo. 2 de-

scribes the initialization which is generating the keys

and building the encrypted database.

Query: To query a keyword w, user computes search

token τ

= stag

and sends it to the server. It ini-

tializes the smart contract SC

with the root of IbSMT

(see Algo. 3). The user calls StoreandLock in SC

where it locks P

coins for time T

and stores stag

On receiving stag

, the server checks if the

value exists in IbSMT. If stag

/∈ IbSMT, the server

generates a proof of non-membership, p f

, using

IbSMT.root and submits it to SC

. Upon evaluation,

if the proof p f

is found to be correct, then the server

receives P

coins, and the protocol aborts. If the proof

is not valid, then the server does not get any payment,

gets unlocked, and the protocol is aborted.

Response and Commit: If stag

exists in IbSMT, the

server searches for stag

in TSet. Then it encrypts t

using key K

and generates R

. It shares R

with the

user and sends commitment of t (c

), commitment of

), commitment of K

), and h

to SC

Check Response: The user checks if the commitment

of R

is c

. If not, then it complaints to SC

and un-

locks P

coins. Else, the it regenerates vtag

, which is

used to generate h

. The user submits vtag

to SC

and locks additional P

coins.

Algorithm 2: Fidelis.Search(w).

Algorithm 2: Fidelis.Search(w)

User (U):

takes K = (K

) and a keyword w.

computes stag

← TSetGetTag(K

,w)

executes StoreandLock(stag

) in SC

and locks P

coins till time T

Server (S):

if IbSMT.root in SC

̸= α

, then S aborts

if stag

does not exist then

p f

← NMSearch(IbSMT,x)

if QueryValid(p f

) = valid then

S gets P

coins and protocol aborts.

else

gets unlocked and abort.

else if stag

exists then

t ← TSetRetrieve(TSet,stag

)

,.. .,e

] ← t; K

←− {0, 1}

;

← Sym.Enc(K

,t)

← H

(t); c

← H

); c

← H

)

SendCommitment(c

)

Sends R

to the U

end

User:

if c

̸= H

) then

U complains as v

ComplainResponse(R

);

if v

is valid bit then

B unlocks P

coins and aborts.

else

Computes vtag

← H

(

,w)

StoreandLock(vtag

)

locks P

coins by B in SC

till time T

end

Server:

if h

̸= H

(vtag

||e

||.. .||e

) then

abort!

else Reveal(K

)

User:

,.. .,e

] ← Dec(K

)

′

← H

(vtag

||e

||.. .||e

)

if h

′

̸= h

or H

(t) ̸= c

then

p f

= (R

,t)

executes Complain(p f

) by B in SC

if current time < T

then

B evaluates correctness of p f

else S gets P

+ P

coins

else if h

′

= h

then

U re-generates K

← F(K

,w);

U decrypts each e

← Sym.Dec(K

)

U gets R = {id

,id

,.. .,id

}

S receives payment after time T

end

Fidelis: Veriﬁable Keyword Search with No Trust Assumption

701

Commit Reveal: Using vtag

and e

′

s, if it is possible

to generate h

, then the server reveals the decommit-

ment of c

. Else, it aborts.

Algorithm 3: Smart Contracts.

Algorithm 2: Fidelis Search(w)

User (U):

takes K = (K

) and a keyword w.

computes stag

← TSetGetTag(K

,w)

executes StoreandLock(stag

) in SC

and locks P

coins till time T

Server (S):

if IbSMT.root in SC

̸= α

, then S aborts

if stag

does not exist then

p f

← NMSearch(IbSMT,x)

if QueryValid(p f

) = valid then

S gets P

coins and protocol aborts.

else

gets unlocked and abort.

else if stag

exists then

t ← TSetRetrieve(TSet,stag

)

,.. ., e

] ← t; K

←− {0, 1}

;

← Sym.Enc(K

,t)

← H

(t); c

← H

); c

← H

)

SendCommitment(c

)

Sends R

to the U

end

User:

if c

̸= H

) then

U complains as v

ComplainResponse(R

);

if v

is valid bit then

B unlocks P

coins and aborts.

else

Computes vtag

← H

(

,w)

StoreandLock(vtag

)

locks P

coins by B in SC

till time T

end

Server:

if h

̸= H

(vtag

||e

||.. .||e

) then

abort!

else Reveal(K

)

User:

,.. ., e

] ← Dec(K

)

′

← H

(vtag

||e

||.. .||e

)

if h

′

̸= h

or H

(t) ̸= c

then

p f

= (R

,t)

executes Complain(p f

) by B in SC

if current time < T

then

B evaluates correctness of p f

else S gets P

+ P

coins

else if h

′

= h

then

U re-generates K

← F(K

,w);

U decrypts each e

← Sym.Dec(K

)

U gets R = {id

,id

,.. ., id

}

S receives payment after time T

end

Algorithm 3: Smart Contracts

Function Initialize(IbSMT.root):

Record IbSMT.root in B

Function StoreandLock(value,P):

Lock P in the contract

Record value in B

if current time is T

then

Unlock coins locked in contract for

User

Function QueryValid(p f

if p f

is valid w.r.t IbSMT.root then

Unlock P

for Server

Function

SendCommitment(c

Record c

in B

Function Reveal(K

Store K

in B

if current time is T

then

Unlock coins locked in contract for

Server

Function ComplainResponse(R

if c

̸= H

) then

Unlock coins locked in contract for

User

Function Complain(p f

Parse p f

if p f

= (K

) and c

̸= H

) then

Unlock P

+ P

for User

else

Compute t

′

=Dec(K

)

||e

||.. .||e

) ← Parse(t

′

)

Compute

′

= H

(vtag

||e

||.. .||e

)

if h

′

̸= h

or R

̸= Sym.Enc(K

,t)

then

Unlock P

+ P

for User;

else

Unlock P

+ P

for Server;

end

Response Retrieval: The user checks the commitment

of K

. If unmatched, it raises a complaint and submits

a proof p f

= (K

) to the function complain in SC

before time T

. The client has to raise the complaint

and send proof of error p f

within time T

, else the

server gets the payment P

. The waiting times T

and T

can be ﬁxed at the beginning of the protocol.

If K

is valid, the user decrypts R

using K

and

gets t. Next, he parses t to get e

′

s and recomputes

′

. If h

′

̸= h

or c

! = Commitment(t), he submits

a proof of invalid response to SC

, again before time

. SC

evaluates whether the complaint raised by the

user is valid. If valid, then the user gets a refund of

+ P

coins. If not, then the server gets the total

amount for performing the task correctly.

If h

′

= h

, the user decrypts e

s using K

F(K

,w). If the user has not raised a complaint within

, then the server claims the full amount.

Fidelis is veriﬁable by both the user and the server.

If anyone cheats, it can be detected by others. Fair-

ness is guaranteed as well. The server cannot get pay-

ment from the user without giving the correct result.

Moreover, there is no way a user can get a correct

result from the server without payment. Conﬁdential-

ity is retained as there is no leakage of information

that would beneﬁt an adversary. The proofs justifying

these properties along with the proof for correctness

and soundness will be discussed in the full version of

the paper.

4 PERFORMANCE ANALYSIS

We implement and evaluate the protocol w.r.t.

Ethereum as a blockchain platform. The smart con-

tracts are written in Solidity language and deployed

in the Ropsten test network.The gas price is 38.66

GWei (or 0.00007132 USD on 9

, February, 2023).

We vary number of ﬁles from 10K to 100K, keywords

from 35K to 109K and queries from 10 and 1000.

The gas cost for deploying the smart contract

and for executing Initialize are around 163.957

USD (gas usage: 2298905) is 12.277 USD (gas us-

age: 172144) respectively. For querying a existing

or a non-existing keyword, the gas cost for executing

StoreandLock for a single query remains the same

which is is around 7.366 USD (gas usage: 103287).

(i) Searching existing keyword: For a single exist-

ing keyword, executing SendCommitment takes

16s and costs is 9.487 USD (gas usage: 133021)

payed by the server. They are same for

StoreandLock. However, executing Reveal,

they are 21 s, and 10.045 USD (gas usage:

140846). Finally, the time taken to ﬁnalize the

payment is 18s and the gas cost is 2.857 USD (gas

usage: 40063).

(i) Searching a non-existing keyword: The only func-

tion that gets executed in QueryValid, where the

proof size varies with the size of the database. The

time taken for execution varies between 20s and

34s whereas the gas cost increases slightly from

41.296 USD (gas usage: 579030) to 43.528 USD

(gas usage: 610329).

Apart from this, we plot the initial encrypt time

taken by owner in Fig.2(a). It varies between 38s

SECRYPT 2023 - 20th International Conference on Security and Cryptography

702

(a) Owner Computation Time upon varying ﬁle size

(b) User and Server’s Computation Time upon varying

number of keywords

Figure 2: Time taken for computation.

and 360s with the increase in the size of the database.

For the bad case, when a given keyword is not a

part of the database, the computation time of user

is around 0.02ms but in the case of server, the time

varies between 25ms to 70ms. If the keyword is part

of the database, then with an increase in the number

of keywords, the user time varies between 0.045ms

to 0.1ms, and the server time varies between 0.05ms

and 0.15ms, as shown in Fig.2(b).

We observe that querying existing keywords, the

gas cost is around 23 USD. In Guo et al. (Guo

et al., 2022), the gas cost for uploading a digest in-

creases with the increase in index pairs, varying be-

tween 712.08 USD (gas usage: 9984351, for 1K index

pairs) and 14,252.8388 USD (gas usage:199843506,

for 16K index pairs). In Fidelis, the gas cost for up-

loading data/locking coins is around 46.877 USD (gas

usage: 65727700), being invariant with the frequency

of occurrence of the keyword. The cost of storage

on-chain is ﬁxed (only 320 B) for our protocol, com-

pared to (Guo et al., 2022), where the cost of storage

increases to 1MB when the number of index-pairs is

20K. For non-existing keywords, the smart contract

needs to verify whether the proof sent by server is cor-

rect. The length of the proof increases with the size

of the database, hence the gas cost is much higher.

5 CONCLUSION

We have proposed Fidelis, a blockchain-based search-

able encryption scheme that operates without any

trust assumption and ensures the veriﬁability of

search results. We provide proof of its security and

fairness. We deploy and test our prototype in the

Ethereum Ropsten testnet with real-life data which

demonstrates the feasibility and efﬁciency of our pro-

posed scheme. We can see that the protocol can be

executed by all involved parties efﬁciently.

REFERENCES

Buterin, V. (2020 (accessed November 4, 2020)). Ethereum.

Cash, D., Jarecki, S., Jutla, C. S., Krawczyk, H., Rosu,

M., and Steiner, M. (2013). Highly-scalable search-

able symmetric encryption with support for boolean

queries. In Advances in Cryptology - CRYPTO 2013 -

33rd Annual Cryptology Conf., pp 353–373.

Dahlberg, R., Pulls, T., and Peeters, R. (2016). Efﬁcient

sparse merkle trees - caching strategies and secure

(non-)membership proofs. In Secure IT Systems - 21st

Nordic Conf., NordSec 2016, vol. 10014 of LNCS, pp.

199–215.

Fan, C., Dong, X., Cao, Z., and Shen, J. (2020). VCKSCF:

efﬁcient veriﬁable conjunctive keyword search based

on cuckoo ﬁlter for cloud storage. In, 19th IEEE Int.

Conf. on Trust, Security and Privacy in Computing

and Communications, TrustCom 2020, pp. 285–292.

IEEE.

Guo, Y., Zhang, C., and Jia, X. (2020). Veriﬁable

and forward-secure encrypted search using blockchain

techniques. In ICC 2020 - 2020 IEEE Int. Conf. on

Communications (ICC), pp. 1–7.

Guo, Y., Zhang, C., Wang, C., and Jia, X. (2022). To-

wards public veriﬁable and forward-privacy encrypted

search by using blockchain. IEEE Trans. on Depend-

able and Secure Computing, pp. 1–1.

Jiang, S., Liu, J., Wang, L., and Yoo, S. (2019). Veriﬁable

search meets blockchain: A privacy-preserving frame-

work for outsourced encrypted data. In 2019 IEEE Int.

Conf. on Communications, ICC 2019, pp. 1–6. IEEE.

Li, H., Zhou, H., Huang, H., and Jia, X. (2020). Veri-

ﬁable encrypted search with forward secure updates

for blockchain-based system. In Wireless Algorithms,

Systems, and Applications - 15th Int. Conf., WASA

2020, vol. 12384, LNCS, pp. 206–217. Springer.

Miao, Y., Tong, Q., Deng, R., Choo, K.-K. R., Liu, X.,

and Li, H. (2022). Veriﬁable searchable encryption

framework against insider keyword-guessing attack in

cloud storage. IEEE Trans. on Cloud Computing,

10(2):835–848.

Sardar, L. and Ruj, S. (2019). Fspvdsse: A forward secure

publicly veriﬁable dynamic sse scheme. In Provable

Security - 13th Int. Conf., ProvSec 2019, pp. 355–371.

Wang, J., Chen, X., Sun, S., Liu, J. K., Au, M. H., and

Zhan, Z. (2018). Towards efﬁcient veriﬁable conjunc-

tive keyword search for large encrypted database. In

Computer Security - 23rd European Symposium on

Research in Computer Security, ESORICS 2018, vol.

11099, LNCS, pp. 83–100. Springer.

Fidelis: Veriﬁable Keyword Search with No Trust Assumption

703