SYSTEMS AND METHODS FOR END-TO END-ENCRYPTION WITH ENCRYPTED MULTI-MAPS

Abstract

According to some aspects, provided are systems and methods that implement end-to-end encryption, and provide implementation configured to secure information during execution of queries on an encrypted data source. Various embodiments include multiple encrypted multi-map data structures and associated encryption schemes configured to securely read, write, and delete information while supporting any one or more of the following features: snapshot security, multiple client support, efficient execution under concurrent operation, and resilience to client failures. In various embodiments, addressable multi-map data structures enable concurrent access, and allow correct operation under polynomial time constraints.

Description

BACKGROUND

Implementing end-to-end encryption poses many challenges in the data management and database spaces. The goal of such encryption approaches is to provide a completely secure set of data for any client, irrespective of platform. Even when data is fully encrypted, there are opportunities for adversaries to exploit data leakage to learn about underlying encrypted data, where the opportunities for leakage depend on the underlying encrypted search design as well as on the adversarial model being considered.

SUMMARY

According to some aspects, provided are systems and methods that implement end-to-end encryption, and provide implementation configured to secure information during execution of queries on a data source. Various embodiments include multiple encrypted multi-map data structures and associated encryption schemes configured to securely read, write, and delete information while supporting any one or more of the following features: snapshot security, multiple client support, efficient execution under concurrent operation, and resilience to client failures.

According to various aspects, provided are descriptions of encryption schemes for implementing end-to-end encryption in document oriented database systems, semi-structured, and/or unstructured database systems. According to one embodiment, a database system can include an OST1 construction. According one example, OST1 describes a (e.g., document) database encryption scheme that is configured to enable any one or more of the following features: (1) snapshot security; (2) support for multiple clients; (3) efficient support for concurrent operations; and (4) resilience to client failures. Further embodiments provide “lightweight clients”—in the sense that the implementation does not require or assume that the clients can have large memory or have access to a non-conventional computational power. Still other embodiments enable resilience to “server crashes,” and also provide for “scalability.” For example, the system can support scalable architecture and work in sharded clusters of the known MongoDB database (among other options). Some embodiments are configured to provide efficient search, updates and deletes, low storage overhead, and expressive queries including for example, support for more than point queries.

According to one aspect, a database system is provided. The system comprises at least one processor operatively connected to a memory, the at least one processor when executing configured to: enable end-to-end encryption of plaintext data via an emulation of a database implementation (e.g., distributed database, dynamic schema database, known MongoDB database, etc.); accept and process queries against the emulation of the database implementation, such that the queries operate on and retrieve encrypted data from the emulation; instantiate the emulation of the database implementation, the emulation including: at least a first encrypted data structure (e.g., multi-map, addressable multi-map, etc.) configured to: store encrypted representations of the plaintext data; link multi-dimension labels to respective encrypted representations in the first encrypted data structure; receive and execute database operations against the encrypted representations using the multi-dimension labels; and at least a second encrypted data structure (e.g., multi-map, addressable multi-map, etc.) configured to: store encrypted metadata associated with the first encrypted data structure; and prevent overwrite conditions from occurring on the first encrypted data structure using the encrypted metadata.

According to one embodiment, the at least one processor is further configured to receive and execute concurrent database operations against the first encrypted data structure. According to one embodiment, the at least one processor is further configured to receive and execute concurrent database operations against the second encrypted data structure. According to one embodiment, the at least one processor is further configured to receive and execute stateless database operations against the first encrypted data structure. According to one embodiment, the at least one processor is further configured to receive and execute stateless database operations against the second encrypted data structure. According to one embodiment, the emulation further comprises a third encrypted data structure configured to store gap information for the multi-dimension labels and respective encrypted representations.

According to one embodiment, the third encrypted data structure is configured to limit reads executed on the first encrypted data structure to occur on locations in the first encrypted data structure having existing data. According to one embodiment, the at least one processor is further configured to receive and execute concurrent and/or stateless database operations against the third encrypted data structure. According to one embodiment, the emulation further comprises an encrypted set structure configured to: store operation tokens generated for database operations on the second and third encrypted data structures; and enable compaction of the second and/or third encrypted data structures. According to one embodiment, the emulation further comprises an encrypted range data structure (e.g., multi-map, addressable multi-map, etc.) configured to: store encrypted representations of the plaintext data; and receive and execute range delimited database operations against the encrypted representations.

Still other aspects, examples, and advantages of these exemplary aspects and examples, are discussed in detail below. Moreover, it is to be understood that both the foregoing information and the following detailed description are merely illustrative examples of various aspects and examples and are intended to provide an overview or framework for understanding the nature and character of the claimed aspects and examples. Any example disclosed herein may be combined with any other example in any manner consistent with at least one of the objects, aims, and needs disclosed herein, and references to “an example,” “some examples,” “an alternate example,” “various examples,” “one example,” “at least one example,” “this and other examples” or the like are not necessarily mutually exclusive and are intended to indicate that a particular feature, structure, or characteristic described in connection with the example may be included in at least one example. The appearances of such terms herein are not necessarily all referring to the same example.

BRIEF DESCRIPTION OF THE DRAWINGS

Various aspects of at least one embodiment are discussed herein with reference to the accompanying figures, which are not intended to be drawn to scale. The figures are included to provide illustration and a further understanding of the various aspects and embodiments, and are incorporated in and constitute a part of this specification, but are not intended as a definition of the limits of the invention. Where technical features in the figures, detailed description or any claim are followed by references signs, the reference signs have been included for the sole purpose of increasing the intelligibility of the figures, detailed description, and/or claims. Accordingly, neither the reference signs nor their absence are intended to have any limiting effect on the scope of any claim elements. In the figures, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every figure. In the figures:

FIG. 1 is an example stateless addressable two-dimensional multi-map encryption scheme, according to one embodiment;

FIG. 2 is an example stateless two-dimensional dictionary encryption scheme, according to one embodiment;

FIG. 3 is an example stateless two-dimensional multi-map encryption scheme according to one embodiment;

FIG. 4 is an example stateless two-dimensional multi-map encryption scheme, according to one embodiment;

FIG. 5 is an example stateless enumerable encrypted set scheme, according to one embodiment;

FIG. 6 is an example binary search subroutine, according to one embodiment;

FIG. 7 is an example merge subroutine, according to one embodiment;

FIG. 8 is an example stateless multi-map encryption scheme, according to one embodiment;

FIG. 9 is an example stateless multi-map encryption scheme, according to one embodiment;

FIG. 10 is an example stateless multi-map encryption scheme, according to one embodiment;

FIG. 11 is an example stateless range multi-map encryption scheme, according to one embodiment;

FIG. 12 is an example emulated function for collection creation, according to one embodiment;

FIG. 13 is an example emulated function for insert, according to one embodiment;

FIG. 14 is an example emulated function for find, according to one embodiment;

FIG. 15 is an example emulated function for find, according to one embodiment;

FIG. 16 is an example emulated function for find, according to one embodiment;

FIG. 17 is an example emulated function for find, according to one embodiment;

FIG. 18 is an example emulated function for find, according to one embodiment;

FIG. 19 is example emulated function for find, according to one embodiment;

FIG. 20 is an example emulated function for find, according to one embodiment;

FIG. 21 is an example emulated function for delete, according to one embodiment;

FIG. 22 is an example emulated function for update, according to one embodiment;

FIG. 23 is an example emulated function for update, according to one embodiment;

FIG. 24 is an example emulated function for compaction, according to one embodiment;

FIG. 25 is an example emulated function for compaction, according to one embodiment;

FIG. 26 is an example emulated function for compaction according to one embodiment;

FIG. 27 is an example emulated function for erase, according to one embodiment;

FIG. 28 is an example emulated binary search subroutine, according to one embodiment;

FIG. 29 is an example emulated function for a get counter subroutine, according to one embodiment;

FIG. 30 is an example emulated function for an insert field subroutine, according to one embodiment;

FIG. 31 is an example emulated function for a get caps subroutine, according to one embodiment;

FIG. 32 is an example subroutine, according to one embodiment;

FIG. 33 is an example subroutine, according to one embodiment;

FIG. 34 is an example subroutine, according to one embodiment;

FIG. 35 is an example algorithm, according to one embodiment;

FIG. 36 is an example algorithm, according to one embodiment; and

FIG. 37 is a block diagram of an example computer system improved by implementation of the functions, operations, and/or architectures described herein.

DETAILED DESCRIPTION

To facilitate understanding of elements of the end-to-end encrypted database and example encryption schemes, described are consideration for construction of OST1 and underlying development of two new multi-map encryption schemes Ω_P and Ω_R that achieve any one or more or any combination of the properties above (e.g., 1-4), in various examples. Ω_R is an example range multi-map encryption scheme that can be used. Ω_R itself based on Ω_P and Ω_P is based on multiple data structure encryption schemes that each achieve different characteristics and can be used for different purposes. Example considerations and implementation for the schemes are discussed in detail below.

Various embodiments enhance security over conventional approaches. For example, security can be enhanced over conventional implementation when considering a snapshot adversary. A (memory-level) snapshot adversary has access to the entire memory and disk of a server at a particular point in time. This means that at that instant, the adversary can access the entire database, any keys stored in memory, all the caches and all the logs. Some approaches exist that include snapshot-secure structured encryption. While such approaches exist, they are very complex and do not support the properties above. As is described in further detail below, example schemes Ω_P and Ω_R, are more efficient than known approaches and provide enhanced security guarantees.

According to various embodiments, the system supports databases that are accessed by multiple clients. Further, the implementation of the underlying structured encryption (“STE”) scheme can be configured to support a multi-writer multi-reader (“MWMR”) setting. In a multi-writer setting, clients can issue put operations (described in greater detail below) at the same time which can cause contention and reduce write throughput. Various embodiments resolve the complexity of multi-writer settings and improve over various known single writer approaches. To the inventors' awareness, the various embodiments described are the first multi-writer multi-reader structured encryption schemes.

Various conventional dynamic multi-map encryption schemes require the client to keep state. State becomes difficult to manage in a multi-client setting, for example, because clients need to maintain a consistent view of state. Another important consideration is that clients can crash at any time and cause state information to be lost. Various embodiments are configured to provide crash recovery protocols that are efficient. Some embodiments resolve the state issue by removing the consideration under a stateless architecture.

Construction Examples and Notation: The set of all binary strings of length n is denoted as {0, 1}ⁿ, and the set of all finite binary strings as {0, 1}*. [n] is the set of integers {1, . . . , n}. The output y of a probabilistic algorithm A on input x is denoted by y←A(x). The output y of a deterministic algorithm A on input x is denoted by y:=A(x). If S is a set then xS denotes sampling from S uniformly at random. Given a sequence s of n elements, the description refers to its ith element as s_i. If S is a set then #S refers to its cardinality. Throughout, k will denote the security parameter.

Example Dictionaries & multi-maps. A dictionary DX with capacity n is a collection of n label/value pairs {(_i, v_i)}i≤n and supports Get and Put operations. v_i:=DX[_i] denotes getting the value associated with label _i and DX[_i]:=v_i denotes the operation of putting the value vi in DX with label _i.

A multi-map “MM” with capacity n is a collection of n label/tuple pairs {(_i, v_i)_i}i≤n that supports Get and Put operations. v_i=MM[i] denotes getting the tuple associated with label _i and MM[_i]=v_i to denote operation of associating the tuple v_i to label _i. Multi-maps are an abstract data type instantiated by an inverted index. In further example, the system can define a range multi-map “RMM” that supports—in addition to Get and Put operations-range queries: given a range [a, b]⊆Z², return the set of values V=RMM[]. V=RMM[[a, b]] denotes getting the values associated with the range [a, b].

Example source databases can include any structured or semi-structured database. Various embodiments are configured to manage document databases. A document database DDB of size n holds n documents D1, . . . , Dn each of which is a set of field/value pairs. Various examples described herein are discussed under the assumption of documents in a database that have the same number of field/value pairs. More precisely, for all 1≤i≤n, D_i=(f₁, v₁), . . . , (f_m, v_m). The examples are provided to illustrate operations and facilitate understanding and are not limited to such cases, and in other embodiments are configured to manage databases and documents having varying numbers of field/value pairs.

Examples are discussed that include document databases with fields that support the following exact queries and range queries. For example, an exact search query takes as input a field/value pair (f, v) and returns the documents in DDB that include the field f with value v. A range search query takes as input a range [a, b] instead of a single value and returns the documents in DDB that include the field f with values between a and b.

Various embodiments and operations are discussed with respect to the known MongoDB database and its mongo shell query and update operations. Other embodiments can be employed with different databases and query/update operations.

Example cryptographic primitives are included in, for example, a symmetric-key encryption scheme. The symmetric-key encryption scheme is a set of three polynomial-time algorithms SKE=(Gen, Enc, Dec) where Gen is a probabilistic algorithm that takes a security parameter k and returns a secret key K; Enc is a probabilistic algorithm that takes a key K and a message m and returns a ciphertext c; Dec is a deterministic algorithm that takes a key K and a ciphertext c and returns m if K was the key under which c was produced.

Informally, a private-key encryption scheme is secure against chosen-plaintext attacks (CPA) if the ciphertexts it outputs do not reveal any partial information about the plaintext even to an adversary that can adaptively query an encryption oracle. A scheme is random-ciphertext-secure against chosen-plaintext attacks (RCPA) if the ciphertexts the scheme outputs are computationally indistinguishable from random even to an adversary that can adaptively query an encryption oracle. In some examples, RCPA-secure encryption can be instantiated practically using either the standard PRF-based private-key encryption scheme or, e.g., AES in counter mode. In addition to encryption schemes, the system can be configured to leverage pseudo-random functions (PRF), which are polynomial-time computable functions that cannot be distinguished from random functions by any probabilistic polynomial-time adversary. In the following examples, described are the evaluation of a pseudo-random function F with a key K on an input x as F_K(x) but sometimes as F(K, x) for visual clarity. Also the notation F_K[s₁, s₂, . . . , s_n] can be used to mean F(F(F(K, s₁), s₂), . . . ), s_n). Various formal security definitions are known and include those described in Introduction to Modern Cryptography, by J. Katz and Y. Lindell, (2008).

Various embodiments employ hypergraph data structures. A hypergraph H=(V, E) consists of a set of n vertices V=v₁, . . . , v_n and a collection of m non-empty edges E=e₁, . . . , e_m such that, for all i∈[m], e_i⊆V. The degree of a vertex v∈V is the number of edges in E that contain v and is denoted by deg(v). In the following, described is a range hypergraph, H=(V, E) such that V is a total order and such that for all ranges r∈R(V), there exists a subset C_r⊆E such that ∪_e∈Cre=r, referred to as a cover of the range r. The min-cover of a range r⊆V is the set

$C_r=\arg {\min }_{C\subseteq E}\left\{\mathrm{\#C}:\bigcup _{e\in C}e=r\right\}.$

In various embodiments, the system includes two efficient algorithms: Edges_H and Mincover_H. In some examples, Edges_H takes as input a vertex v and outputs the subset of edges E_v⊆E that include v. In other examples, Mincover takes as input a range r∈R(V) and outputs its min-cover C_r. The two efficient algorithms permit use of a hypergraph H in various constructions.

Various embodiments include a stateless multi-map encryption scheme Ω_P. In various examples, Ω_P evolved and improved over some known multi-map encryption schemes. In various embodiments, the underlying encryption schemes were adapted and improved, and each one modified to have different characteristics and ultimately used for different purposes. At a high level, the first scheme, Σ_M, can be used to encrypt the input multi-map which results in the main encrypted multi-map EMM_M. The second scheme, Σ_C, can be used to encrypt metadata about the main encrypted multi-map (e.g., that can be used to avoid overwriting items in EMM_M). The third scheme, Σ_D, can be used to store information about items deleted in the main encrypted multi-map (e.g., in order to speed up queries on EMM_M). The last scheme, Σ_P, can be used to store information that can be needed to compact the auxiliary structures. Compacting the auxiliary structures reduces their space consumption. The following description describes examples of the underlying encryption schemes, optimizations, improvements, and purposes.

Example Two-Dimensional Addressable Encrypted Data Structures

As mentioned above, various embodiments include scheme Ω_P, which can employ a first scheme Σ_M to encrypt an input multi-map MM, resulting in the “main” encrypted multi-map EMM_M. In various examples, Σ_M is a π_dyn-style construction that has been adapted to improve security and operation over known π_dyn-style constructions. For example, Σ_M is part of a two-dimensional multi-map encryption scheme (described in greater detail below). Further Σ_M is configured to be stateless. This architecture can be implemented at the cost of correctness, in the sense that the values associated to a label can be overwritten. To better understand this example scheme and this behavior, Σ_M is described as supporting read, write, and erase operations instead of get, put, and delete operations. More precisely, these operations work as follows:

• • write: takes as input a label , a tuple v and a sequence of addresses a and stores the pair (, v′) such that for all 1≤i≤#v, v_i is stored at index a_i of v. In this example #v′ ≥#v.
  • read: takes as input a label and a sequence of addresses a and returns the values in 's tuple v′ indexed by a.
  • erase: takes as input a label and a sequence of addresses a and removes the values indexed by a from 's tuple v.The example construction is referred to as an addressable multi-map.

According to some embodiments, the system is configured to enable concurrency via two-dimensionality. According to one embodiment, the encrypted multi-map EMM_M will be used by Ω_P to store the tuple associated with a label . Typical operation results in contention when multiple clients are writing to the same label, and which in turn, results in slowing down Ω_P 's write throughput under parallel put operations. Various embodiments are configured to resolve the contention and the throughput issue. For example, the system can be configured to employ EMM_M as a 2-dimensional (encrypted) multi-map, instead of using a standard multi-map. In this example, the multi-dimension multi-map is configured to hold label/tuple pairs with labels of the form =(x, y). Given a high contention label , Ω_P is configured to process as a multi dimensional label ′=(, u), where u is a value sampled uniformly at random from {1, . . . , p}, and store the pair ((, u), v) in EMM_M. Stated broadly, the system manages the scenarios where n clients try to write to the same high-contention label then, in expectation, only n/p writes will be executed on the same two-dimensional label =(, u) in EMM_M. Further embodiments can be configured with additional optimization via a two-choice allocation instead of just sampling u at random.

Various embodiments enable this operation based on the two-dimensional encrypted multi-map supporting—in addition to read, write and erase operations—read operations on a single dimension. To facilitate understanding, in various embodiments, n write (, v) operations for EMM_M can be transformed to n writes of the form ((, u), v) for 1≤u≤p. In various examples, this architecture does not cause any issue during write operations, but potential issues can result for reads, since a hypothetical read needs to return the values associated with every two-dimensional label . An example solution requires the client to compute and send p read tokens to the server; one for each u∈{1, . . . , p}. Other embodiments are configured to support two additional algorithms, ReadXToken and ReadXYToken, to improve operation. According to one example, the first algorithm, ReadXToken, can be used by the client to generate a read token for the x-component of a label =(x, y). The second algorithm, ReadXYToken, is used by the server to generate a read token for =(x, y) given a read token for x and the y-component y. When querying for a label , the system (e.g., client) can be configured to send to the server a read token for and the server can use that to generate read tokens for the two-dimensional labels (, 1), . . . , (, p).

The following examples and embodiments describe the syntax of addressable two-dimensional multi-map encryption schemes. Various embodiments provide a response-hiding stateless addressable two-dimensional multi-map encryption scheme. The scheme can be a structured encryption scheme Σ_M=(Init, WriteToken, Write, ReadToken, ReadXToken, ReadXYToken, Read, EraseToken, Erase, Resolve) that can include the preceding polynomial-time algorithms. Examples of the algorithms are shown in the Source Code Appendix, which forms an instant part of this specification. In further embodiments, Σ_M provides a practical stateless encryption scheme for addressable two-dimensional multi-maps.

According to one example, the scheme is described in detail in FIG. 1. The various implementations can be understood to work as follows. According to some embodiments, the scheme employs a pseudo-random function F and of a symmetric encryption scheme SKE. Init samples a k-bit key K_t for F, generates a key K_e for SKE and initializes an empty dictionary DX that will represent the encrypted multi-map EMM. The WriteToken algorithm produces a write token wtk that consists of a key :=F(F_Kt(x, ) and encryptions of each value in v under the key K_e. The Write algorithm stores pairs of the form (t_i, ct_i) in the dictionary DX, where t_i:=(a_i) and ct_i is the encryption of v_i. The ReadToken algorithm is configured to return the key :=F(F_Kt(x, ) as the read token rtk and Read returns the ciphertexts in DX associated to the labels (a_i), for all a_i∈a. The ReadXToken algorithm is configured to return K_x:=F_Kt(_x) as its read-x token, and ReadXYToken is configured to return F_Kx() as the read token. EraseToken is configured to output :=F(F_Kt(_x), ) as the erase token etk and Erase sets DX[(a)] to ⊥. Resolve recovers v by decrypting the sequence of ciphertexts ct using K_e.

FIG. 1 illustrates an example stateless addressable two-dimensional multi-map encryption scheme. According to some embodiments, the scheme is addressable, however, the scheme does not inherently guarantee correctness since tuple values can be overwritten if writes for two different values are made to the same address. Further embodiments can be configured to employ another scheme to encrypt an auxiliary structure that is configured to provide “overwrite protection” for EMM_M.

According to one embodiment, Σ_M is optimal with respect to communication complexity: write tokens are O(#v), read and erase tokens are O(1) and read responses are O(#a). In further example, the scheme is also optimal with respect to server-side computation since writes and reads are O(#a) and erase operations are O(1). Client-side operations are also optimal since computing write tokens is O(#a), computing read and erase tokens is O(1) and resolving is O(#ct).

Example Two-Dimensional Immutable Dictionaries

In further embodiments, a second building block, Σ_C, which can be a dictionary encryption scheme that achieves statelessness and correctness. Some examples provide these features at the cost of limited query functionality and (in some cases) a slight decrease in query efficiency. This scheme is configured to satisfy several non-standard properties described in greater detail below.

Example Overwrite Protection

As discussed above, Σ_M achieves statelessness by easing on correctness and, specifically, by not guaranteeing that values cannot be overwritten. Various embodiments address this limitation via an auxiliary encrypted structure EDX_C produced with a dictionary encryption scheme Σ_C to store information that limits overwrites in EMM_M. Embodiments of Σ_C have been designed so that they are both stateless and correct, in the sense that it does not allow overwrites.

An example approach that achieves these goals includes an option to associate a counter count with every label in the main encrypted multi-map EMM_M, store the pairs (, count ) in a dictionary DX, encrypt DX using a response-revealing dictionary encryption scheme and store the resulting encrypted dictionary EDX_C with the main encrypted multi-map EMM_M. To add a label/tuple pair (, v) to EMM_M, the system (e.g., the client) is configured to send encryptions of v and a Σ_C get token gtk_C for so that the server can query EDX_C, recover count and store the ciphertexts ct in EMM_M at addresses a=(count +1, . . . , count +#ct). The server then updates the pair (, count ) in EDX_C to (, count +#ct).

Example Snapshot Security Via Immutability

Additional embodiments resolve potential security concerns of the above approach. While this approach may seem reasonable, it has a subtle security flaw if implemented naively. The problem is with the last step where the server updates EDX_C with the new counter value. If this is done in-place, then a snapshot adversary will be able to correlate EDX_C put operations—and therefore EMM_M write operations-since every put for a label results in changes at a specific location of EDX. It is realized that even if the location of the pairs in EDX_C's underlying structure are randomized, there may still be a consistent string associated to the pair that could be used to correlate. While some embodiments use randomization, further security improvements can be realized.

For example, various embodiments include Σ_C configured in such a way that Σ_C supports edits in an immutable manner so that correlations are not revealed. One example approach implements the encrypted dictionary using an encrypted multi-map and implements dictionary edit operations with multi-map append operations. For example, the system is configured to, when changing a pair (, v) in the encrypted dictionary to (, v′) append the new value v′ to 's tuple in an encrypted multi-map. A dictionary get operation for can then be implemented by returning the last value of 's tuple in the underlying multi-map. According to various embodiments, because an EDX_C-level edit is implemented as an encrypted multi-map append, a snapshot adversary cannot correlate between edit operations.

Example (Efficient) Immutability Via Completeness

As discussed above, the STE schemes implemented by the system, and as a building block for Ω_P have been designed to be stateless. The system is configured to maintain the stateless property for the encrypted dictionary EDX_C and its underlying encrypted multi-map. The properties may seem cross purpose, however, various embodiments implement EDX_C's underlying EMM to guarantee that the EMM has a special property which enables a stateless and correct scheme. For example, the underlying multi-map will always be complete, in the sense that for all labels , if 's tuple v includes m values then there does not exist an index 1≤i≤m such that v_i=⊥.

According to some embodiments, the above guarantee of completeness enables support of get tail operations on the underlying encrypted multi-map efficiently—where the tail of a label/tuple pair is the last element of the label's tuple. More precisely, in various examples the system provides this functionality using the following variant of binary search. According to one example, consider a sequence S=(v₁, . . . , v_n, ⊥_n+1, . . . , ⊥_N). Given S, we would like to find the address a such that v_a≠⊥ but v_a+1=⊥. This problem can be solved in O(N) time with linear scanning but also in O(log N) time as follows: given S, check if the element at address N/2 is ⊥; if so recur on the “left half” of S otherwise recur on the “right half” of S. The base case occurs when the set holds a single element. Embodiments of the algorithm are described in detail in FIG. 6.

Example Concurrency Via Two-Dimensionality.

According to some embodiments, another characteristic of Σ_C is that, like Σ_M, Σ_C is two-dimensional in order to provide support for concurrent Ω_P operations. The following examples and embodiments describe the syntax of addressable two-dimensional multi-map encryption schemes. Various embodiments provide a response-revealing stateless immutable two-dimensional multi-map encryption scheme. The scheme can be a structured encryption scheme Σ_C=(Init, PutKey, PutToken, Put, GetToken, GetXToken, GetXYToken, Get, DeleteToken, Delete) that can include the preceding polynomial-time algorithms. Examples of the algorithms are shown in Source Code Appendix.

FIG. 2 illustrates an example of the scheme Σ_C. Evaluations of the approach show that embodiments of Σ_C are optimal with respect to communication complexity: all tokens and responses are O(1). All its algorithms are also O(1) with the exception of Put and Get which are O(log #MM_C) and Delete which is O(#MM_C[]).

Example Two-Dimensional Append Multi-Maps

As discussed above, Ω_P encrypts the input multi-map MM with a stateless addressable scheme Σ_M to produce a main encrypted multi-map EMM_M and then encrypts a dictionary to avoid overwrites with a stateless (two-dimensional) immutable dictionary encryption scheme Σ_C. Embodiments that include these features achieve a stateless snapshot-secure semi-dynamic scheme. However further embodiments expand functionality to support deletes. For example, augmenting the scheme to support deletes can be achieved with minor updates if all the system enables is correctness, but further implementation to handle deletes without affecting the scheme's query complexity includes additional considerations. The inventors have realized that the problem stems from deleting label/value pairs from the main encrypted multi-map EMM_M. So for example, if the multi-map originally stored a pair (, v), where #v=m, and then values (v₁, . . . , v_m-1) are deleted, querying the structure for would still be O(m). Some embodiments are configured to address this issue so, Ω_P includes, in addition to EMM_M and EMM_C, an encrypted multi-map EMM_D that stores, for every label in EMM_M, the gaps/holes in 's tuple v. When the server executes a get for, it first queries EMM_D to retrieve 's gaps gf and uses that to only read from the existing locations in 's tuple.

In further embodiments, other characteristics of Σ_D include (like Σ_C) two-dimensionality in order to provide support for concurrent Ω_P operations. Σ_D can also support two kinds of insert operations, append and put which work as described on Source Code Appendix.

Various embodiments enable Σ_D to support multiple kinds of inserts to allow Ω_P to make different kinds of insertions at different times. For example, Ω_P can be configured to append gaps to 's tuple in EMM_D when deletes on are made; and Ω_P can be configured to put entire label/tuple pairs in EMM_D during compaction (discussed in greater detail below).

The following examples and embodiments describe the syntax of a response-revealing stateless two-dimensional multi-map encryption scheme. The scheme can be a structured encryption scheme Σ_D=(Init, AppendKey, AppendToken, Append, PutKey, PutToken, Put, GetToken, GetXToken, GetXYToken, Get, DeleteToken, Delete) that can include the preceding polynomial-time algorithms. Examples of the algorithms are shown in Source Code Appendix.

According to some embodiments, the design of Σ_D is shown with detailed examples in FIGS. 3 and 4. Further embodiments show that Σ_D is optimal with communication complexity: where all tokens are O(1) and responses are O(MM_D[]. The algorithms reference above are also optimal with the exception of Append which is O(log #MM_D).

Example Enumerable Sets

As discussed above, Ω_P encrypts the input multi-map with a stateless addressable multi-map encryption scheme Σ_M which results in a main encrypted multi-map EMM_M. Overwrite protection can be achieved by encrypting a dictionary that stores counters with a stateless two-dimensional dictionary encryption scheme Σ_C which results in an auxiliary structure EDX_C. Information about deletions is stored in encrypted multi-map EMM_D using a two-dimensional scheme Σ_D. This information can be used to speed up query operations. The embodiments and examples described achieve statelessness and correctness but can still be optimized further as they are not necessarily space efficient. On review, the space complexity of the three structures described is O(#MM[]+#puts+#deletes), where #MM[] is the size of the input multi-map and #puts and #deletes are the total number of put and erase operations made on the input multi-map. Note the analysis depends on the total number of puts and deletes ever made and not on the size of the input multi-map. To address these considerations, various embodiments of Ω_P use a process called compaction to remove stale data from EMM_C and EMM_D.

According to one embodiment, the compaction process can be executed by the server which means it needs access to information stored in both EMM_C and EMM_D. More precisely, the server utilizes the ability to query these structures to delete certain pairs and to add new ones. To enable this operation, the client generates get, put and delete tokens for EMM_C and EMM_D whenever the client executes a put or erase for Ω_P. According to one example, these tokens are stored in an auxiliary encrypted set structure EST_P and used at compaction time. According to some embodiments, the encrypted set structure supports the following operations:

• • insert: takes as input an element and stores it in the set;
  • enum: enumerates all the elements in the set.The following examples and embodiments describe the syntax of a response-revealing stateless set encryption scheme. The scheme can be a structured encryption scheme Σ_P=(Init, InsertToken, Insert, Enum) that can include the preceding polynomial-time algorithms. Examples of the algorithms are shown in Source Code Appendix.

Example implementation of the scheme Σ_P is described in FIG. 5. According to one example, the scheme includes an encrypted set EST that includes symmetrically-encrypted elements, an insert token that includes the encryption of the inserted element and an enumeration that includes decryption of the ciphertexts in the encrypted set and listing the plaintexts.

Example Stateless Multi-Map Encryption Scheme

Considerations for the high level structure of Ω_P have been described above in the previous sub-sections to facilitate understanding and describe the design of example building blocks of the scheme. As discussed, embodiments of the scheme make use of an addressable multi-map encryption scheme Σ_M, an immutable two-dimensional dictionary encryption scheme Σ_C, a two-dimensional append multi-map encryption scheme and an enumerable set encryption scheme Σ_P. According to one embodiment Ω_P includes functions Init, PutToken, Put, GetToken, Get, DeleteToken, CompactionToken, Compaction, EraseToken, Erase, Resolve, which are described in FIGS. 8, 9, and 10.

Example Implementation: Put Operations

According to some embodiments, PutToken for a label and tuple v first determines if is a high contention label. If so, the function creates a two-dimensional label ′=(, u), where u←${1, . . . , p}. If not, the function creates a two-dimensional label ′=(, 0), and then creates a put token ptk which consists of: (1) an EMM_M write token wtk_M for (′, v); (2) an EDX_C get token gtk_C for ′; (3) an EDX_C put key for ′; (4) an EST_P insert token itk_P; and (5) the size of v. The EST_P insert token itk_P is for an element that is the concatenation of EDX_C get and delete tokens for ′, a put key for ′ and EMM_D get and delete tokens for ′. According to one embodiment, these elements are stored in EST_P and also used later during compaction.

Given a put token ptk=(wtk_M, gtk_C, pk_C, itk_P, m), the Put algorithm uses gtk_C to retrieve a counter count from EDX_C that represents the number of previously used addresses in the tuple of ′. For example, the server uses this counter, together with the write token wtk, to write to EMM_M without overwriting Specifically, the server executes Σ_M. Write with wtk_M and addresses a=(, . . . , +m−1). The server can be configured to update the counter of EDX_C by generating a put token ptk with the put key pk_C and value count+m and applying ptk_C to EDX_C. The server can be configured to update the encrypted set EST_P with itk_P.

Example Implementation: Get Operations

According to one embodiment, GetToken produces a get token gtk for a label that consists of: (1) a read x-token rxtk_M for ; (2) a get-x token gxtk_C for ; (3) a get-x token gxtk_D for ′; and (4) a flag that describes whether the label is a high contention label or not. Given a get token gtk=(rxtk_M, gxtk_C, gxtk_D, cont), the Get algorithm first uses the flag to determine if the label is a high contention label. If so, the server uses gxtk with values {1, . . . , p} to generate p get tokens (gtk_C,1, . . . , gtk_C,p), where gtk_C,i, is for the two-dimensional label (, i). The server then queries EDX_C with these tokens to retrieve p counters (count₁, . . . , count_p) from EDX_C for the two-dimensional labels (count_i, . . . , count_p). Similarly, for all 1≤i≤p, if count_i>0, the server uses gxtk_D with {i} to generate a get token gtk_D,i, and uses it to recover the gaps g_i for the two-dimensional label (, i). In addition, the server uses rxtkM to generate a read token rtkM,i for the two-dimensional label (, i). According to some examples, the server then uses the counters and gaps to generate the sequence of used addresses it needs to read from EMM_M. If the label is not a high contention label, the server can execute the above with a single two-dimensional label (, 0).

Example Implementation: Erase Operations

According to one embodiment, EraseToken produces an erase token etk for a two-dimensional label (, u) and address a that consists of: (1) an erase token etk_M for (∥u); (2) a get token gtk_D for (, u); (3) an append token atk_D for (, u); (4) the address a to erase; and (5) an insert token itk_P for a set of compaction-time tokens, i.e., a set of EDX_C and EMM_D tokens configured for use during compaction. According to one example, the Erase algorithm uses itk_P to insert the compaction tokens in the encrypted set EST_P and uses etk_m, to erase the element at address a from (, u)'s tuple in EMM_M.

Example Implementation: Compaction

According to one embodiment, CompactionToken outputs the key K_P as a compaction token. At a high level, for every in EMM_M, the compaction algorithm first retrieves 's counter from EDX_C and

's gaps from EMM_D. Once collected, the algorithm is configured to then delete everything related to from both EDX_C and EMM_D which includes “stale” data, for example, old counter values in EDX_D. The deletion enables reclamation of wasted space. Once removed, the algorithm then re-inserts 's counter in EDX_C, merges 's gaps and re-inserts them in EMM_D. Merging in this context includes operations where 's gaps are re-encoded into a more compact representation. For example, if 's gaps include four holes i, i+1, i+2, i+3 then the algorithm encoded them as a single gap [i, 3]. A detailed description of an example merge process is given in FIG. 7.

According to further embodiments, the compaction algorithm enumerates EST_P which returns a set P of elements of the form gtk_C∥dtk_C∥pk_C∥gtk_D∥dtk_D. For example, these elements encode a set of tokens needed to compact EDX_C and EMM_D for some label . For each of the elements in P, the algorithm is configured to use gtk_C to retrieve 's counter from EDX_C and gtkD to retrieve gaps g from EMM_D. The algorithm then merges g into a new sequence g. is then deleted from EDX_C and EMM_D using dtk_C and dtk_D, respectively. If g′={1, . . . , count} then every element of 's tuple has been erased and nothing else needs to be done. If g′≠{1, . . . , count}, however, the algorithm is further configured to: (1) use pk_c to generate a put token for 's counter and inserts the counter into EDX_C; and (2) use pk_D to generate a put token for g and inserts the token into EMM_D.

According to some embodiments, during compaction, if the data related to a particular label is being compacted then get, put and delete operations can still occur simultaneously on any label ′≠. According to one embodiment, the Resolve algorithm executes Σ's resolve algorithm and returns its output.

Example Implementation: Stateless Range Multi-Map Encryption Scheme

According to some embodiments, the system can include a range multi-map encryption scheme Ω_R=(Init, PutToken, Put, RangeToken, Range, EraseToken, Erase, CompactionToken, Compaction, Resolve), for example, that is used by OST1. Various embodiments have been adapted from an ERX framework described in “Encrypted Range Search via Range Hypergraph”, by Kasemsan Kongsala, Seny Kamara, and Tarik Moataz. Example implementation makes use of a multi-map encryption scheme E and a range hypergraph H equipped with efficient algorithms EdgesH and MincoverH. According to some examples, the scheme is updated to instantiate E with the stateless multi-map encryption scheme Ω_P and H with a new hypergraph referred to as a sparse partition hypergraph. Example details of the construction are provided in FIG. 11 and the sparse partition hypergraph is described in the Source Code Appendix. According to some embodiments the scheme includes the functions described in the Source Code Appendix.

Example Implementation: Storage-Level Emulation of OST1

A common belief in this space is that STE may be limited based on use of non-standard data structures and query algorithms which can limit applicability since STE requires re-architecting existing database systems. Various embodiments described herein resolve the legacy-friendly concern of STE. For example, one reason traditional STE schemes are believed to be not legacy-friendly is because they make two implicit assumptions about the server: (1) that it can store arbitrary data structures; and (2) that it can execute arbitrary algorithms. A legacy-friendly scheme does not make these assumptions and is designed to work with servers that can only store a fixed kind of data structure and execute a fixed set of operations. For example, a SQL-friendly STE scheme is a scheme that produces encrypted structures that can be stored as relational databases and that has query and update algorithms that can be executed as standard SQL operations. Similarly, a MongoDB-friendly STE scheme is a scheme that produces encrypted structures that can be stored as document databases and that have query and update algorithms that can be executed using standard MongoDB operations.

Emulation Examples

Stated broadly, various aspects provide emulation that is configured to take an encrypted data structure (e.g., an encrypted multi-map) and find a way to represent it as another data structure (e.g., a graph) without any additional storage or query overhead. Intuitively, emulation is a more sophisticated version of the classic data structure problem of simulating a stack with two queues. Designing storage- and query-efficient emulators can be challenging depending on the encrypted structure being emulated and the target structure (i.e., the structure used to emulate on top of). According to various embodiments, the benefits of emulation are twofold: (1) a low-overhead emulator essentially makes an STE scheme legacy-friendly; and (2) emulation preserves the STE scheme's security.

Example Implementation: Storage-Level Emulation of OST1

The following examples and embodiment describe a storage-level emulation rather than a fully-emulated version of OST1. The difference between full and storage-level emulation is that the latter emulates the data structures of the scheme but not its query and update algorithms. In other words, various embodiments of the emulated OST1 scheme require no modifications to the server's storage system but implement new query algorithms. Other embodiments provide for fully emulating OST1 (no query algorithm changes) but the following examples of the storage-level emulation results in a more communication-efficient scheme. Example implementation details for storage-level emulation of OST1 is described in FIGS. 12 through 26 and include the following (encrypted) operations: collection creation, document insertion, document update, exact search, negation, range search, conjunctive search, disjunctive search, Boolean search, document deletion and compaction. Some of these operations make use of subroutines which are detailed in FIGS. 28, 34, and 35. The following provides further illustrative description of examples of such operations below. According to some embodiments, a document can define a base unit of data, that for examples, stores data as attribute value pairs (e.g., as fields with, for example, field names), may include other documents, and/or other complex structures (e.g., arrays). A collection can be a logical grouping of documents, and may be accessed by a name associated with the grouping.

Example notation used: The set of all encrypted fields in the database is F, the set of encrypted fields that support exact queries is EF⊆F, the set of encrypted fields that support range queries is RF⊆F and the set of encrypted fields that are high contention as HC⊆F. Given some document D, denote by EFD, RFD and HCD the fields in D that support equality and range queries and that are high contention, respectively. Reference to a field f, f refers to the “absolute” path of the field, i.e., db.collection.f if the field f is not nested, or db.collection.field.f if it is nested. Various examples use this approach to guarantee that every field in the database is unique. To facilitate understanding, recall that when F is a pseudo-random function, it is sometimes written as FS[s₁, s₂, . . . , s_n] to mean F(F(F(F(S, s₁), s₂), . . . ), s_n).

Example Database Implementation and Schema Examples

According to some embodiments, the following description assumes that server stores a schema that includes the following information for encrypted fields:

• • query type: whether the field supports exact or range queries;
  • numerical type: ⊥ for fields that support exact queries and a tuple of the form (precision,
    • lBound, uBound, sparsity) for fields that support range queries;
  • contention level: an integer p≥1 that determines the field's level of contention. p=0 Indicates the field has no contention.

Example scrub function. Various embodiments can optionally use a function “scrub” which takes in as input a query Q (e.g., a MongoDB Query Language (“MQL”) query) and outputs a clean query Q which is like Q with the exception that its values are replaced with an “obfuscation” symbol ▪. Other embodiments can be implemented with other native databases and their respective query languages.

Example MQL Operations

Create collection. Described are operations on how to create a collection. There are many ways to create a collection each one supporting a different key generation mode. Example pseudo-code for these modes is given in FIG. 12 and can include the follow functions/modes:

• • driver-generated keys: in this mode, the data encryption keys are generated by OST1. Detailed examples are shown in the createCollectionDriverKeys operation of FIG. 12. user-generated collection-level key: in this mode, the user provides a collection-level key from which OST1 derives the necessary data encryption keys. Detailed examples are shown in the createCollectionCollectionKeys of FIG. 12.
  • user-generated document-level keys: in this mode, the user provides a key for every document from which OST1 derives the necessary data encryption keys. Detailed examples are shown in the createCollectionDocumentKeys of FIG. 12.
  • user-generated field-level keys: in this mode, the user provides a key for every field in the collection which OST1 uses as the data encryption key. Note that for some field f, the same data encryption key is used across all documents in the collection. Detailed examples are shown in the createCollectionFieldKeys of FIG. 12.
  • user-generated field- and document-level keys: in this mode, the user provides a key for every field of every document which OST1 uses as the data encryption key. Note that for some field f, different data encryption keys are used across the documents in the collection. Detailed examples are shown in the createCollectionFieldDocumentKeys of FIG. 12.

Example Insert Operation. An example insert operation is shown in FIG. 13. The pseudo-code describes how to insert documents without nested documents or arrays. Additional functions and operations are described in Source Code the Source Code Appendix.

FIG. 37 is a block diagram of an example computer system that is improved by implementing the functions, operations, and/or architectures described herein. Modifications and variations of the discussed embodiments will be apparent to those of ordinary skill in the art and all such modifications and variations are included within the scope of the appended claims. Additionally, an illustrative implementation of a computer system 3700 that may be used in connection with any of the embodiments of the disclosure provided herein is shown in FIG. 37. The computer system 3700 may include one or more processors 3710 and one or more articles of manufacture that comprise non-transitory computer-readable storage media (e.g., memory 3720 and one or more non-volatile storage media 3730). The processor 3710 may control writing data to and reading data from the memory 3720 and the non-volatile storage device 3730 in any suitable manner. To perform any of the functionality described herein (e.g., image reconstruction, anomaly detection, etc.), the processor 3710 may execute one or more processor-executable instructions stored in one or more non-transitory computer-readable storage media (e.g., the memory 3720), which may serve as non-transitory computer-readable storage media storing processor-executable instructions for execution by the processor 3710.

The terms “program” or “software” are used herein in a generic sense to refer to any type of computer code or set of processor-executable instructions that can be employed to program a computer or other processor to implement various aspects of embodiments as discussed above. Additionally, it should be appreciated that according to one aspect, one or more computer programs that when executed perform methods of the disclosure provided herein need not reside on a single computer or processor, but may be distributed in a modular fashion among different computers or processors to implement various aspects of the disclosure provided herein.

Processor-executable instructions may be in many forms, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.

Also, data structures may be stored in one or more non-transitory computer-readable storage media in any suitable form. For simplicity of illustration, data structures may be shown to have fields that are related through location in the data structure. Such relationships may likewise be achieved by assigning storage for the fields with locations in a non-transitory computer-readable medium that convey relationships between the fields. However, any suitable mechanism may be used to establish relationships among information in fields of a data structure, including through the use of pointers, tags or other mechanisms that establish relationships among data elements.

Also, various inventive concepts may be embodied as one or more processes, of which examples (e.g., the processes described herein) have been provided. The acts performed as part of each process may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

In other embodiments, various ones of the functions and/or portions of the flows discussed herein can be executed in different order. In still other embodiments, various one of the functions and/or portions of the flow can be omitted, or consolidated. In yet other embodiments, various one of the functions and/or portions of the flow can be combined, and used in various combinations of the disclosed flows, portions of flows, and/or individual functions. In various examples, various one of the screens, functions and/or algorithms can be combined, and can be used in various combinations of the disclosed functions.

Having thus described several aspects of at least one example, it is to be appreciated that various alterations, modifications, and improvements will readily occur to those skilled in the art. For instance, examples disclosed herein may also be used in other contexts. Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the scope of the examples discussed herein. Accordingly, the foregoing description and drawings are by way of example only.

All definitions, as defined and used herein, should be understood to control over dictionary definitions, and/or ordinary meanings of the defined terms. As used herein in the specification and in the claims, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, “at least one of A and B” (or, equivalently, “at least one of A or B,” or, equivalently “at least one of A and/or B”) can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.

The phrase “and/or,” as used herein in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.

Use of ordinal terms such as “first,” “second,” “third,” etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed. Such terms are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term).

The phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use of “including,” “comprising,” “having,” “containing”, “involving”, and variations thereof, is meant to encompass the items listed thereafter and additional items.

Having described several embodiments of the techniques described herein in detail, various modifications, and improvements will readily occur to those skilled in the art. Such modifications and improvements are intended to be within the spirit and scope of the disclosure. Accordingly, the foregoing description is by way of example only, and is not intended as limiting. The techniques are limited only as defined by the following claims and the equivalents thereto.

Claims

1. A database system comprising: at least one processor operatively connected to a memory, the at least one processor when executing configured to:manage a distributed database, the distributed database configured to: provide end-to-end encryption of plaintext data;accept and process queries from a plurality of clients, such that the queries operate on and retrieve encrypted data;enforce security against a snapshot adversary during execution of database functions; andexecute the database functions under stateless constraints.

2. The system of claim 1, wherein the at least one processor is configured to retrieve and write with the encrypted data using multi-dimension labels.

3. The system of claim 1, wherein the at least one processor is configured to enable concurrent access to the encrypted data based at least in part on multi-dimension labels.

4. The system of claim 3, wherein the at least one processor is configured to employ read tokens for data retrieval based on use of a first read token for a first component of a multi-dimension label and use of a second read token for a second component of the multi-dimension label.

5. The system of claim 1, wherein the at least one processor is configured to execute initialization, write, read, and erase operations for the encrypted data under polynomial time constraints.

6. The system of claim 1, wherein the at least one processor is configured to conceal correlations from a snapshot adversary based at least in part on executing edits under an immutable constraint.

7. The system of claim 6, wherein the at least one processor is configured to manage an encrypted multi-map data structure and execute dictionary edit operations based at least in part on executing append operations to the multi-map data structure.

8. The system of claim 7, wherein the at least one processor is configured to manage the encrypted multi-map data structure and operations under a completeness constraint.

9. The system of claim 2, wherein the at least one processor is configured to generate an encrypted data structure for managing metadata about the encrypted data.

10. The system of claim 9, wherein the at least one processor is configured to execute an encryption scheme configured to manage information on items deleted from the encrypted data.

11. The system of claim 10, wherein the at least one processor is configured to execute an encryption scheme configured to manage auxiliary data structures.

12. A computer implementation method for managing encrypted database data, the method comprising: managing, by at least one processor, a distributed database;encrypting and operating, by the at least one processor, on the encryption of plaintext data, wherein encrypting and operating on includes accepting and processing queries from a plurality of clients, such that execution of the queries operate on and retrieve encrypted data to communicate to the plurality of clients;enforcing, by the at least one processor, security against a snapshot adversary during execution of database functions; andexecuting, by the at least one processor, the database functions under stateless constraints.

13. The method of claim 12, wherein the at least one processor is configured to retrieve and write with the encrypted data using multi-dimension labels.

14. The method of claim 12, wherein the method further comprises enabling concurrent access to the encrypted data based at least in part on multi-dimension labels.

15. The method of claim 14, wherein the method comprises generating read tokens for data retrieval based on employing a first read token for a first component of a multi-dimension label and a second read token for a second component of the multi-dimension label.

16. The method of claim 12, wherein the method comprises executing initialization, write, read, and erase operations for the encrypted data under polynomial time constraints.

17. The method of claim 12, wherein the method comprises concealing correlations from a snapshot adversary based at least in part on executing edits under an immutable constraint.

18. The method of claim 17, wherein the method comprises managing an encrypted multi-map data structure and executing dictionary edit operations based at least in part on executing append operations to the multi-map data structure.

19. The method of claim 18, wherein the method comprises managing the encrypted multi-map data structure and operations under a completeness constraint.

20. The method of claim 2, wherein the method comprises generating an encrypted data structure for managing metadata about the encrypted data.