Efﬁcient and Secure Encryption Adjustment for JSON Data

Maryam Almarwani, Boris Konev and Alexei Lisitsa

Department of Computer Science, University of Liverpool, Ashton Street, Liverpool, U.K.

Keywords:

Onion Layers Encryption, Encryption Adjustment, Document-store, Communication Cost, Efﬁciency,

Security Trade-off.

Abstract:

Querying over data protected by multi-layered encryption requires encryption level adjustments. Different

layers of encryption enable different sets of operations over encrypted data at the expense of possibly reducing

protection levels and releasing some information about the data. Trade-offs between functionality and data

security are non-trivial and have been addressed in previous work for various data models. In this paper, we

consider encryption level adjustments for JSON-formatted data and propose new adjustments methodologies,

based on sorted criteria and on update-aware principles. Sorted criteria are used to limit the number of

encryption layers adjusted, while update-aware adjustments limit the number of updated values. We report on

the empirical evaluation of the policies and show that they improve over previously proposed policies in terms

of communication costs, exposing information, and performance.

1 INTRODUCTION

Database encryption, which protects sensitive data

prior to storage, has been widely used to resolve mul-

tiple data security concerns. Query processing for en-

crypted data poses some challenges and trade-offs be-

tween functionality, security and performance, as it

is necessary for information to be revealed for the

required computations to be performed. Different

approaches to generating viable query systems have

been proposed to tackle these query processing is-

sues. One option is to decrypt data on the server or

client-side before executing a query, that requires a

transfer of encryption keys. Another option is query

processing over encrypted data that allows compu-

tations to be performed directly over encrypted data

at the server-side, avoiding transferring encryption

keys or downloading data. These encryption tech-

niques, however, may expose some information about

the data as they enable particular subsets of computa-

tions. Several encryption schemes (Boldyreva et al.,

2009) can be used for customized computation. Such

encryption schemes are used in the CryptDB system

(Popa et al., 2011), which uses onion encryption that

takes an advantage of various schemes, offering se-

curity guarantees for each item of data and requires

adjustment techniques (Popa et al., 2011; Aburawi

et al., 2018a; Almarwani et al., 2021), as different

queries may require adjustments to particular layers

supporting required operations. However, major chal-

lenges remain in the use of adjustment techniques,

such as revealing information, communication costs,

and scalability concerns due to increasing data sizes.

This paper’s main aim is to highlight the communica-

tion cost associated with revealed information during

the adjustment and provide ways to reduce it. To ad-

dress these challenges, this paper presents novel tech-

niques for controlling the number of values adjusted

while simultaneously limiting or avoiding data up-

dates on the database during processing adjustments.

These include the techniques based on: (i) Sorted

Criteria: To limit the number of values adjusted; (ii)

Update-Aware Adjustments: To decrease commu-

nication costs and exposed information as well as to

improve the trade-off between these factors, perfor-

mance and security.

The remainder of the paper is structured as fol-

lows. In the next section, preliminaries are presented.

In Section 3, issues with existing adjustment tech-

niques are outlined and solutions proposed. Section

4 provides a case study based on the proposed ap-

proach, while Section 5 presents the outcomes of

the empirical evaluation. Finally, in Section 6, an

overview of related work is presented to support a

summary of the conclusions in Section 7.

Almarwani, M., Konev, B. and Lisitsa, A.

Efﬁcient and Secure Encryption Adjustment for JSON Data.

DOI: 10.5220/0010791300003120

In Proceedings of the 8th International Conference on Information Systems Security and Privacy (ICISSP 2022), pages 307-313

ISBN: 978-989-758-553-1; ISSN: 2184-4356

307

2 PRELIMINARIES

For this paper, we assume that the data is in a NoSQL

Document-Oriented Database (OrientDB). JSON data

are encrypted using onion layers encryption. To

execute a query over such encrypted data, an en-

cryption adjustment may be needed. Various poli-

cies for the adjustment have been proposed in the

previous research such as a Simple Encryption Ad-

justment (SEA) (Popa et al., 2011) for relational

data model, Traversal-Aware Encryption Adjustment

(TAEA) (Aburawi et al., 2018a) for graph data model,

and Release-Aware Encryption Adjustment (RAEA)

(Almarwani et al., 2020; Almarwani et al., 2021) for

document-based databases. The rest of this section

thus offers a concise outline discussing onion layers

encryption and RAEA in more detail.

2.1 Onion Layers Encryption

In onion layers encryption, each data object is en-

crypted in "onions," or at least one "onion". Each

onion is composed of layers of increasingly se-

cure types of encryption. Each onion layer sup-

ports/enables a different set of computation opera-

tions depending on the type of encryption used. RND

(Random) layer (Popa et al., 2011) provides the high-

est level of protection as it does not reveal any in-

formation about encrypted values, not even equality.

Deterministic encryption (DET)(Popa et al., 2011) or

Order-Preserving Encryption (OPE) (Boldyreva et al.,

2009) allow for more computation operations (equal-

ity and comparisons, respectively) at the cost of re-

duced security. Each encryption type releases some

information about encrypted values, and the informa-

tion inclusion induces generally a partial order on

the encryption types (Almarwani et al., 2020). For

the encryption types we use in this paper, this or-

der is RND  DET  OPE  PLAIN, where PLAIN

denotes “no encryption”. For this paper, we use

Ciphertext Policy Attribute-Based Encryption(CP-

ABE)(Bethencourt et al., 2007) which is public-key

encryption at the RND layer

(Almarwani et al.,

2019a). The outer layers of onion layers encryption

provide higher level of protection, but limited or none

operations support (i.e. RND), while inner layers al-

low for more operations at the cost of reduced security

(i.e. DET, OPE). These arrangements lead to the ne-

cessity of the encryption level adjustments depending

on a query to be executed.

CP-ABE encryption provides more functionality and

can be used for attribute-based access control, which is not

our concern in this paper

2.2 Conjunctive Queries

While the techniques proposed in this paper are ap-

plicable to the wider classes of queries, we limit our-

selves to conjunctive queries of the form “Find all

documents satisfying a conjunction of simple crite-

ria”. To unify the presentation, we use the notation

adopted in (Almarwani et al., 2021) which itself fol-

lows conventions of MongoDB API. So, for a query

Q we denote its conjunction of criteria by C(Q) =

$And{e

, . . . , e

}. Each e

is an expression of the form

f op v, where f , f

, f

are ﬁelds names and v is a

value. op is one of the comparison operators from

{<, ≤, >, ≥, =}. For a comparison operator op we

denote by SL

the minimal wrt to  encryption level

of the arguments of op sufﬁcient for evaluation of op

on these arguments. Thus we have SL

= DET , while

= SL

≤

= SL

≥

= SL

= OPE. For an atomic ex-

pression e we denote by op(e) the operator occurring

in e and by field(e) the ﬁeld name (“property”) ) oc-

curring in e. For a query Q we denote by E(Q) the

set of all atomic expressions occurring in C(Q). For a

query Q and a ﬁeld name f occurring in Q we deﬁne

( f ) = max

{e∈E(Q)| f ield(e)= f }

op(e)

. For a query Q

and a database instance (set of documents) I we de-

note by D(Q, I) a set of documents returned by the

execution of Q on I.

2.3 Release-Aware In-Out Encryption

Adjustment

Release-Aware In-Out Encryption Adjustment

(RAEA) (Almarwani et al., 2021) is a dynamic

adjustment policy that combines several simple but

powerful ideas. The main idea behind RAEA is

to query with the conjunction of criteria: 1) sort

atomic criteria according to the popularity of ﬁelds

in a database instance: from low to the high count

of ﬁelds; 2) proceed gradually with the execution of

sub-queries by adding one atomic condition at a time;

3) in between make inward adjustments sufﬁcient

to proceed with the next sub-query; 4) once the

execution of the query is completed, make outward

adjustments to restore the protection levels.

3 EFFICIENCY AND SECURITY

TRADE-OFFS IN RAEA

It has been shown in (Almarwani et al., 2020) that

RAEA, as compared with SEA, reduces the number

of decryptions/re-encryptions, leading to better secu-

rity and reduced computational cost of adjustments.

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

308

There are still some noticeable issues affecting per-

formance and security in RAEA. One is high commu-

nication cost incurred, as back and forth communica-

tion is required between the client and the server to

update the data. It is impacted by two factors: (i)

the place of the adjustment: whether it is done on

the client side or server side and with varying secu-

rity implications for each (see Subsection 3.1); and

(ii) the number of two-way communications required

(see Subsection 3.2). Secondly, RAEA has made sig-

niﬁcant progress in reducing the amount of informa-

tion disclosed to the database, but there is still scope

for improvement.

3.1 Adjustment Side

The encryption level adjustments involve data

decryption/re-encryption and it can be done either on

a server or a client side. The most signiﬁcant differ-

ences between the two adjustment-side concerns are

:(i) Back and Forth Communication: Client-side

adjustment demands additional back and forth com-

munication than database server-side adjustments, in-

creasing communication costs; (ii) Data Download:

Client-side adjustment requires data downloads, a

process which may expose data to external attacks;

(iii) Transferring Encryption Keys: Server-side ad-

justment involves transferring encryption keys to sup-

port adjustment, which may expose internal databases

to attacks or abuse of these keys. In general, server-

side performance is better than client-side perfor-

mance, as the client-side communication costs are

higher. In terms of security, the client side often pro-

vides better protection due to its lack of key exchange.

However, this is not always the case; it is dependent

on the client’s security policies.

3.2 Proposed modiﬁcations of RAEA

In this paper, we propose the modiﬁcation of the orig-

inal RAEA policy. Sorted Criteria and Update-Aware

Adjustments are used to facilitate an efﬁcient trade-

off between disclosure of information, security, and

performance. The application of the modiﬁed RAEA

policy happens in stages which are described below.

• Stage A (Sorted Criteria): Three options for

sorting expressions of criteria based on the data

owner or user needs for security and performance

are offered. Option 1 is preferable where perfor-

mance is more important than security, whereas

option 2 prioritizes security above performance,

and option 3 is a trade-off between the two:

- Option 1 (Frequency Order (FO)) (C(Q

≤

))):

Option 1 is deﬁned by RAEA (Almarwani et al.,

2021) to mean if the frequency properties is pro-

vided by DB features, the frequency in I of all

properties f occurring in C(Q) can be calculated.

The original query condition C(Q) is then re-

written by sorting the atomic expressions by fre-

quency, F such that C(Q

≤

) = $And{e

, . . . , e

where F(property(e

)

) ≤ F(property(e

i+1

)

i = 1, . . . , n − 1.

- Option 2 ( Sensitivity Order (SO)) (C(Q

))):

The data owner determines the sensitivity level

of all properties. The original query con-

dition C(Q) is then re-written by sorting

atomic expressions according to this Sensitiv-

ity level, S, such that C(Q

) = $And{e

, . . . , e

where S(property(e

)

) ≤ S(property(e

i+1

)

), i =

1, . . . , n − 1. The focus is thus on the amount

of information exposed that represents sensitive

user data, irrespective of the number of values ad-

justed. Safety therefore takes priority here over

performance.

- Option 3 (Encryption Level Order (EO))

(C(Q×))): Encryption Level Order shows the

number of layers peeled away to reach a sup-

port level layer, thus reducing the number of val-

ues updated to a low-security level that disclosed

more information. The original query condition,

C(Q), is re-written by sorting the atomic expres-

sions according to the Support level , SL

op(e)

, such

that C(Q×) = $And{e

, . . . , e

}, where SL

op(e

)



op(e

i+1

)

, i = 1, . . . , n −1. Each group at the same

encryption level (i.e. support level) can then be

sorted according to frequency order to help to

minimise adjustment values based on accessing

the advantages of the frequency order.

• Stage B (Criteria Encryption): Query Q is en-

crypted to Q

∗

by encrypting the constant value in

e to the level S

(property(e)).

• Stage C (Update-Aware Adjustment): The

number of values decrypted in the inward ad-

justment phase is determined based on the sort-

ing stage options. However, the outward adjust-

ments reveal that the trade-off between security,

performance, and the disclosure of information to

the Database Management System (DBMS) is de-

pendent on the number of values updated on the

DBMS. As a result, three cases for updating val-

ues have been described:

- CASE 1 (Global Update (GU)): Case 1 is

proposed in original RAEA (Almarwani et al.,

2021) policy; while it reduces the number of up-

dates required as compared with SEA, it includes

a higher number of updated values as compared

with newly proposed CASE 2 and CASE 3 be-

low, particularly with regard to the ﬁrst property

Efﬁcient and Secure Encryption Adjustment for JSON Data

309

of the sorting criteria. This is happened by up-

dating all existing property(e

) values for doc-

uments returned during progressive execution of

the query D(Q

∗

i−1

, I

i−2

) to the encryption level

op(e

)

, regardless of whether or not they match

the current expression. Global Updated data is

generated in both the inward and outward Encryp-

tion (IEA,OEA) adjustment directions. This has

a signiﬁcant impact on the amount of informa-

tion disclosed to the DB and high communication

costs, thus triggering greater outward adjustment

processing costs.

- CASE 2 (Necessary Update (NU)): This case

involves updating only property values for those

documents returned by progressively executing

the query, which refers to those matching the cur-

rent expression. This has a signiﬁcant impact in

terms of reducing the amount of information dis-

closed to the DB as well as minimising communi-

cation costs, resulting in reduced outward adjust-

ment processing costs. Necessary Update is also

performed in both the inward and outward En-

cryption adjustment directions: (A) IEA: The fol-

lowing iterative steps are executed and Let I

= I:

(i) All values of property(e

) in the whole I

are

adjusted to the encryption support level SL

op(e

)

and then matched with e

; where a match is identi-

ﬁed, this is updated in the DB Storage, resulting in

a database state I

; (ii) The values of property(e

)

occurring in documents D(Q

, I

) are adjusted to

op(e

)

and then matched with e

;matches are

updated in the DB Storage, resulting in database

state I

;(iii) ·· · ; (iv) The values of property(e

)

occurring in documents D(Q

i−1

, I

i−2

) are adjusted

to SL

op(e

)

and then matched with e

; matches are

updated in the DB Storage, resulting in database

state I

. (B) OEA: The following iterative steps

are executed:(i) All values of property(e

) across

are restored and updated to the Outer Layer

in the DB Storage; matches with e

result in

database state I

;(ii) All values of property(e

)

across I

are restored and updated to the Outer

Layer in the DB Storage; matches with e

re-

sult in database state I

;(iii) ···; (iv) All values of

property(e

) across I

i−1

are restored and updated

to the Outer Layer in the DB Storage; matches

with e

result in database state I

;(v)···.

- CASE 3 ( Zero-Update (ZU)): It is not neces-

sary to update values in this case. We assume that

the documents contain a unique value property uv,

whose values serve as indexes for the documents.

It means for different documents the values of uv

are different. Then Zero-Update policy is accom-

plished by comparing the current expression to

the documents returned. Where matches occur,

instead of the property values being updated in

the data storage, a copy of the index values of

the matching documents is obtained. The next

expression is then checked against the documents

with the indexes stored, and the list of indexes is

updated to refer to the documents matching the

criteria up the current in the progressive execution

of the query. The ﬁnal list, the ultimate result of

a user query, is thus a set of documents referred

by this list. This case does not disclose any infor-

mation to the DB server and hence minimises the

communication costs. Zero-Update is only per-

formed in the inward adjustment direction, as no

re-encryption of values at the server side is re-

quired. Retrieval of the documents during ZU

processing is performed by the disjunctive queries

with C(U) = $Or{u

, . . . , u

}. Each u

is an ex-

pression of the form f

= v where U

is an ﬁeld

that contains unique index value in the collection/

table. we denote by D(U ) a set of documents re-

turned by the execution of C(U). (A)IEA: The

following iterative steps are executed : (i) All val-

ues of property(e

) in the whole I are adjusted

to the encryption support level SL

op(e

)

without

any updates to the DB Storage; these are then

matched with e

and where matches occur, U val-

ues are stored, resulting in U

;(ii) The values of

property(e

) occurring in documents D(U

) are

adjusted to SL

op(e

)

without any updates to the

DB Storage; these are then matched with e

and

where matches occur, U values are used to up-

date , resulting in U

; (iii)···; (iv) The values of

property(e

) occurring in documents D(U

i−1

) are

adjusted to SL

op(e

)

without any updates to the DB

Storage; these are then matched with e

and where

matches occur, U values are used to update , re-

sulting in U

4 CASE STUDY

A case study was conducted to verify the effective

capabilities of the various proposed RAEA policies.

This was based on a sample dataset with 15 doc-

uments, with four properties offering a total of 52

values (see Fig. 1(a)). Query 1 was then executed

using SEA and the various proposed variants of

RAEA (see Fig. 1(C to L)).

FirstName="Erica" AND LastName="Murt"

AND Salary>5000 AND Salary<7000 AND

Department="Engineering"; Q1

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

310

Figure 1: Case Study.

Figure 2: Analysis Results.

Table 1: Case study Results.

SEA

GU NU ZU

NO-

FO-

EO-

NO-

FO-

EO-

NO-

FO-

EO-

IEA 52 21 17 19 21 17 19 21 17 19

UA 52 21 17 19 7 8 5 0 0 0

OEA 52 21 17 19 7 8 5 0 0 0

RND 0 31 35 33 54 44 46 52 52 52

DET 42 20 7 18 6 4 4 0 0 0

OPE 10 1 10 1 1 4 1 0 0 0

The amount of information revealed to DBMS

relies on the number of RND, DET, and OPE val-

ues to be updated for all encrypted data queries, as

shown in Figure 1. The case study ﬁndings are

shown in Table 1. There are two main ﬁndings: ef-

ﬁciency and security. The efﬁciency evaluation in-

cluded three components: decryption, communica-

tion, and re-encryption costs. Decryption costs de-

pend on Inward-Adjustment. In order to lower such

costs, it is necessary to decrease the number of de-

crypted values. The numbers of values decrypted by

SEA and RAEA are shown in Figure 2(A). As with

other RAEA variants, SEA requires more decrypting

values. The total number of decrypted values is the

same for all RAEA variants that are sorted in the same

way, and the frequency order is the smallest of the

three. Communication costs were reduced by decreas-

ing the number of values updated. Figure 2(B) shows

the greatest update values for SAE, highlighting that

the update values on the GU were larger than those

in NU but less than in SEA. The lowest update value,

however, was 0, for ZU. Re-encryption costs are pro-

cessed through outward adjustment. Charts B and C

in Figure 2 show that the number of outward adjust-

ment values was related to the number of values up-

dated. Security was assessed using the amount of in-

Efﬁcient and Secure Encryption Adjustment for JSON Data

311

formation revealed to DBMS. The cases NU and ZU

were very simple and straightforward, offering only

the information necessary for a query to be executed

and results generated. Thus, the control of DB up-

dates helps to maintain the RND layer values, which

do not expose any information (see Fig 2(D-F)). ZU

raised all RND values to 100 % , while NU is less

than ZU, it increased RND more than GU on the DB.

In all cases, the most obvious level of security hap-

pens in the ZU scenario.

5 EXPERIMENT & EVALUATION

The inward-adjustment time, outward-adjustment

time, and communication time on both the client-

side and server-side adjustments will be measured as

data size increases. Data encryption was performed

in three layers, in the following order: CP − ABE 

DET  OPE  PLAIN. The testing datasets are se-

lected based on the number of documents: (i) 1,000

documents with 6,500 values; (ii) 2,000 documents

with 13,000 values; (iii) 5,000 documents with 32,500

values; and (iv) 10,000 documents with 65,000 val-

ues. SELECT,UPDATE,DELETE were all evaluated

using the same criteria as in Q1. It was tested 20

times. The prototype was written in Java and stored in

a local database (OrientDB). The machine utilised for

testing has 8 GB RAM and an i7-8565U CPU (1.99

GHz).

5.1 Performance Evaluation

Figure 3a illustrates the time required for inward ad-

justment execution, which rises linearly as the num-

ber of documents increases. However, the execution

time is equal for all cases. Figure 3b illustrates the

Outward-Adjustment execution time, with ZU out-

performing all other cases and GU taking the longest

time of them. Figure 3c illustrates the time required to

communicate with and retrieve data from a database.

GU communicated slowly and was the least effec-

tive of the three cases, while the ZU outward adjust-

ment outperformed the other two. Overall, in all three

cases, server-side adjustment outperforms client-side

adjustment.

6 RELATED WORK

The majority of research has focused on unmodiﬁed-

based DBMS for querying encrypted data. (Popa

et al., 2011; Waage and Wiese, 2017; Aburawi

et al., 2018b; Almarwani et al., 2019b) encrypt

data using multiple layers of encryption; thus, they

need adjustment techniques that enable more com-

puting classes. In a previous study, three types of

adjustment techniques were identiﬁed: SEA (Popa

et al., 2011), TAEA (Aburawi et al., 2018a), and

RAEA(Almarwani et al., 2020; Almarwani et al.,

2021). SEA performs adjustments prior to query ex-

ecution by adjusting all values of columns occurring

in query criteria to the encryption level based on the

class of computation contained in the expression col-

umn. CryptDB was the ﬁrst to offer an adjustment

technique (SEA) for SQL, whereas CryptGraph (Abu-

rawi et al., 2018b) and SDDB (Almarwani et al.,

2019b; Almarwani et al., 2019a), respectively, ap-

ply the CryptDB transfer concept to graph databases

(Neo4j database) and document databases (Mon-

goDB). As SEA discloses more information than nec-

essary, Aburawi et al. (Aburawi et al., 2018a) pro-

posed TAEA for traversal queries for graph databases.

TAEA processes adjustments during query execu-

tion to limit the quantity of information required as

much as possible; this execution happens dynamically

based on node-to-node relationships. However, the

Document-Database lacks document-to-document re-

lationships, thus, TAEA is useless in such scenarios.

Almarwani et al (Almarwani et al., 2019b; Almarwani

et al., 2019a) suggested RAEA for conjunctive condi-

tions, as unlike TAEA, RAEA is concerned with lim-

iting the amount of information disclosed after query

conduction, a process based on restoring maximum

security levels. TAEA and RAEA both offer better

protection than SEA, but they create additional obsta-

cles, such as communication costs or disruptions to

adjustments in some cases; determining how to han-

dle these while enabling an appropriate trade-off be-

tween security, effectiveness, and amount of revealed

data is thus important.

7 CONCLUSION

This paper presented an overview of the RAEA ad-

justment techniques used to query encrypted data us-

ing Onion Layers Encryption. The main goal was

to identify the approach that best met the following

requirements: the approach had to (i) permit adjust-

ment at a lower cost of decryption/encryption; (ii)

permit adjustment with limited data updates; (iii) re-

duce communication costs; (iv) provide better secu-

rity by revealing only the required information to the

DBMS for each query; and (v) provide better perfor-

mance concerning query execution speed. This pa-

per thus presented both Sorted Criteria and Update-

ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

312

(a) Execution Time of IEA (b) Execution Time of OEA (c) Execution Time of compunction

Figure 3: Execution Time of Queries.

Aware Adjustments to RAEA. The sorting approach

provides three options, depending on the priorities

given to performance and security, facilitating a trade-

off between the two. Update-Aware Adjustments, on

the other hand, give three cases based on Outward

Adjustment costs and the predetermined trade-off be-

tween three requirements of communication cost, per-

formance, and security. In the document-database ex-

periment, the improved Update-Aware Adjustments

yielded lower communication costs and increased se-

curity. More experiments on these Sorted Criteria

and Update-Aware Adjustments will be conducted in

future work to assess their applicability for various

database types, such as SQL, and to assess their efﬁ-

cacy with regard to big data more formally.

REFERENCES

Aburawi, N., Coenen, F., and Lisitsa, A. (2018a). Traversal-

aware encryption adjustment for graph databases.

In Proceedings of the 7th International Confer-

ence on Data Science, Technology and Applications.

SCITEPRESS-Science and Technology Publications.

Aburawi, N., Lisitsa, A., and Coenen, F. (2018b). Querying

encrypted graph databases. In Proceedings of the 4th

International Conference on Information Systems Se-

curity and Privacy. SCITEPRESS-Science and Tech-

nology Publications.

Almarwani, M., Konev, B., and Lisitsa, A. (2019a). Fine-

grained access control for querying over encrypted

document-oriented database. In International Con-

ference on Information Systems Security and Privacy,

pages 403–425. Springer.

Almarwani, M., Konev, B., and Lisitsa, A. (2019b). Flex-

ible access control and conﬁdentiality over encrypted

data for document-based database. In ICISSP, pages

606–614.

Almarwani, M., Konev, B., and Lisitsa, A. (2020). Release-

aware encryption adjustment query processing for

document database. In Proceedings of the 2020 4th In-

ternational Conference on Cloud and Big Data Com-

puting, pages 48–51.

Almarwani, M., Konev, B., and Lisitsa, A. (2021). Release-

aware in-out encryption adjustment in mongodb query

processing. In ICISSP, pages 714–722.

Bethencourt, J., Sahai, A., and Waters, B. (2007).

Ciphertext-policy attribute-based encryption. In Secu-

rity and Privacy, 2007. SP’07. IEEE Symposium on,

pages 321–334. IEEE.

Boldyreva, A., Chenette, N., Lee, Y., and O’neill, A. (2009).

Order-preserving symmetric encryption. In Annual

International Conference on the Theory and Appli-

cations of Cryptographic Techniques, pages 224–241.

Springer.

Popa, R. A., Redﬁeld, C., Zeldovich, N., and Balakrish-

nan, H. (2011). Cryptdb: protecting conﬁdentiality

with encrypted query processing. In Proceedings of

the Twenty-Third ACM Symposium on Operating Sys-

tems Principles, pages 85–100. ACM.

Waage, T. and Wiese, L. (2017). Property preserving en-

cryption in nosql wide column stores. In OTM Con-

federated International Conferences" On the Move to

Meaningful Internet Systems", pages 3–21. Springer.

Efﬁcient and Secure Encryption Adjustment for JSON Data

313