 Hello my name is Russell Lai. Welcome to my talk on multi-client Oblivious RAM with polylogarithmic communication. This is a joint work with Sherman-Charl, Katharina Fech and Julio Malavota. Let us start by recalling single-client Oblivious Random Access Machine or ORAM for short. An ORAM can be thought of as a stateful compiler which inputs a logical access instruction and outputs a sequence of physical access instructions of length L. The sequence of physical accesses is functionally equivalent to the logical access, but hides all the information about the logical access. The length L is called the communication overhead of the ORAM. It is well known that an overhead of polylog N, where N is the database size, is both necessary and sufficient. ORAM is tremendously useful in a setting where there is one or a group of mutually trusted processes talking to one memory. However, it is not very useful when it comes to the network setting, where multiple mutually untrusted clients wish to access the same database. To allow multiple clients to access the same database obliviously, the notion of multi-client ORAM or MCORAM was introduced. In this setting we have a data owner, a server and multiple clients. The server and some of the clients might be corrupt. For example, here we have a malicious client one with one finger and an honest client two with two fingers. In more detail, the data owner shares a database in encrypted form to the server, together with an access control policy. In this example, client one is allowed to read and write address one, while client two is allowed to read and write address two. An MCORAM should provide obliviousness. For example, if client two reads or writes address two, client one should not know what client two is doing. In fact, client one should not even know that it is client two who is accessing the database. This also means that client one should not be able to read address two. An MCORAM should also provide integrity. For example, client one should not be able to override address two. A bit more formally, an MCORAM consists of a setup algorithm, a key generation algorithm and an oblivious access protocol. The data owner can run the setup algorithm on a plain text database and produce a master secret key and an encrypted database. He keeps the master secret key for himself and delegates the encrypted database to the server. For client i with access policy i, the data owner can run the key generation algorithm using his master secret key and produce a client secret key for client i. Using this secret key, client i can engage in the oblivious access protocol with the server with the access instruction consisting of an address and a value v. Upon termination, client i should return a read value v prime while the server updates the encrypted database. Obliviousness requires that from the server's and other malicious client's points of view, two oblivious accesses should be indistinguishable unless it is trivial. Integrity, on the other hand, requires that given any sequence of access instructions and its derived subsequence of legal instructions, if the full sequence is applied to the encrypted database, while the legal sequence is applied to the plain text database, then the two should end up encoding the same values. MCORAM is quite young as a notion and there were only two existing schemes. The first scheme achieves basically the same complexity as a single client ORAM, but it is not secure against malicious clients. The second scheme is secure against malicious clients, but requires linear server computation and square root client computation and communication. In the same paper, the authors also show that the linear server computation is necessary in the Boss and Bins model. However, there are no known law bounds for client computation and communication. Therefore, a natural question to ask is whether MCORAM with polylaw communication is possible. In this work, we answer this question in the affirmative. In fact, our construction achieves the optimal log-n client computation and communication. Our scheme is based on the new technique which we call the cross-key evaluation of fully homomorphic encryption ciphertexts. Let me quickly recall the syntax of FHE. There are the usual key generation encryption and decryption algorithms as in a public key encryption scheme and also a homomorphic evaluation algorithm. This evaluation algorithm homomorphically evaluates the function F, chosen from some admissible family, over a tuple of ciphertexts and produces a new ciphertext. As a warm-up, let's see how oblivious read can be done. The idea is to simply use an FHE-based private information retrieval or PIR scheme. To read the target address, which we denote by address star, the client samples a fresh FHE key pair denoted by EK and DK. He then encrypts the target address under EK and sends EK and the ciphertext to the server. Suppose that the database consists of the plaintext values v1 up to vn. The server would homomorphically evaluate a read function over the ciphertext sent by the client. The read function has v1 up to vn hardwired, inputs an address, and simply returns the value indexed by this input address. After the evaluation, the server returns the resulting ciphertext to the client. The client then decrypts this ciphertext and learns the value stored at the target address. Note that so far, the database consists of only plaintext values. To support read access control, instead of storing plaintext values v address, the server stores an encrypted version of it, denoted by v address bar, which is encrypted under an address-dependent key denoted by EK address. To grant read access to an address to a client, the data owner simply delegates the corresponding decryption key, DK address, to the client. Next, we tackle the challenging part, which is oblivious write. First, let me give you some intuition. To override the target address address star with a new value v star, the client encrypts the target address and the new value to the server. The server then evaluates a certain function over each database entry. Intuitively, this function should update the existing value v address to a new value v star if the address is equal to the target address. Otherwise, the existing value v address should remain unchanged. The difficulty is that when the address is not equal to the target address, then the existing value v address stored in the database and the tuple address star v star sent by the client are encrypted under different keys. Therefore, it is unclear how homomorphic evaluation works. Obviously, revealing the correct encryption key to the server is not an option because it breaks obliviousness. To solve this problem, we need to take a closer look at the correctness property of fxg schemes. An fxg scheme is correct if it satisfies two properties. The first is decryption correctness, which says that if we encrypt the message and then decrypt it with the correct key, then we should get the same message back. The second is evaluation correctness, which says the following. Suppose that the tuple of ciphertext, ciphertext1 up to ciphertextk, are produced under the same encryption key ek, either by encryption or by homomorphic evaluation. Then, if we first decrypt them using the correct encryption key and then pass them through a function f, the result should be the same as if we evaluate f over them first and then decrypt the result afterwards. A subtlety here is that ciphertext1 up to ciphertextk must be produced under the same key. If some of them are produced under a different key, it is unclear what will happen. To solve this problem, we have to define a stronger correctness property for fxg, which consists of three parts. The first is the usual decryption correctness property. The second is what we call well-defined decryption, which requires that for any decryption key, the decryption function should be well-defined over the entire ciphertext space, even though decrypting with a wrong key might result in garbage. To illustrate, suppose we encrypt the message and then decrypt it with a wrong key, we should end up with a random string, which is nevertheless still in the message space. Finally, we have strong evaluation correctness, which says that the evaluation correctness should hold for any ciphertext in the ciphertext space. We show that the strong correctness of fxg is in fact not very strong in the sense that there exists a generic compiler which turns the standard fxg scheme into a strongly correct one with mild assumptions. Specifically, assuming that the underlying fxg has well-defined decryption, which basically all fxg schemes have, we can upgrade standard correctness to strong correctness. Moreover, assuming circular security, the resulting fxg scheme retains key privacy as well as CPA security. Given a strongly correct fxg scheme and other standard ingredients, namely a signature scheme, we are now ready to construct the Oblivious Write protocol. I am going to present a simplified version of the protocol. The formal details can be found in the paper, of course. To write the new value vstar to the target address address star, the client signs the tuple address star vstar with a signing key depending on address star denoted by sk address star. The client then encrypts the tuple and the signature to the server. The server then homomorphically evaluates a different write function over each database entry. Each write function is hardwired with an address-dependent verification key vk address. It inputs an existing value v and address star, a new value vstar, and a signature sigma. It checks if sigma is the valid signature of the tuple address star vstar under the verification key vk address. If so, it returns the new value vstar, otherwise it returns the existing value v. To see why this protocol works, we consider two cases. In the first case, which is the simpler case, the evaluated address is equal to the target address. In this case, the verification equation should be satisfied, and therefore the evaluation should give an encryption of vstar under ek address star, which is as decided. In the second case, the evaluated address is not equal to the target address. Suppose that the client's ciphertext decrypts to a certain message in the message space, which we pass as address dagger, v dagger, and sigma dagger, which are anyway most likely garbage. In this case, the verification should fail, or otherwise we can use the client to construct a signature forgery. Since the verification failed, the evaluation should result in an encryption of v under ek address. In other words, the value encrypted under the evaluated address remains unchanged. This concludes my overview of our FHE-based MCORAM construction. While we really like the cross-key evaluation technique, verifying a signature homomorphically is quite costly. Also, FHE is only known from lattice-based assumptions. Therefore, we consider an alternative solution to MCORAM with polylog communication, that is to introduce more servers. In a multi-server setting, we will make use of another tool called distributed point function, or DPF. In this context, a point function is a function which is parameterized by a target address address star and a valued delta star. On input and address, the function should return delta star if it is equal to the target address address star, otherwise it should return zero. A TM DPF is simply a secret sharing scheme for point functions. As in other secret sharing schemes, there is a share algorithm which shares a point function into m shares, f1 up to fm. Given the jth share, fj, the shareholder can locally evaluate fj as a function on an address to produce an output share, yj. Finally, given all the output shares, one can recover the value of the point function on the evaluated address. The t in the name TM DPF stands for t-security, which means that the point function is hidden as long as at most t of the m shares are linked. Existing constructions of DPFs have a very nice additive decoding property, which means that the decoding algorithm simply adds up all the output shares. This property allows linearly homomorphic evaluation, as we will see in the next slide. Given a TM DPF, it is not difficult to construct a multi-server single client ORAM with corruption threshold t and m square servers. To set up the database, we treat the database as an n-dimensional vector and secret share it into m shares, db1 up to dbm. We then arrange these shares in an m by m matrix, where the i-th row consists of dpi's. The ijth entry is exactly the share of the ijth server. That is, server ij will get dbi. With this setup, let's see how the client can read the target address address start. First, the client secret shares the point function, which has value 1 at the target address, and distributes the shares column-wise. That is, the jth column of servers would get the jth share fj. Each server ij then evaluates its share fj on all the addresses from 1 to n, which results in an n-dimensional vector. It then computes the inner product of this vector with dpi. Because of the linear homomorphic property, this results in the jth share of the ijth share of the target value. Finally, the client simply adds up all these values and recovers the target value. Oblivious write can be done similarly, but this time the dpf shares are distributed row-wise. Since the multi-server ORAM scheme is stateless, it is straightforward to adapt it to the multi-client setting. Then, to make it a full-blown MCORAM, we just need to add read and write access control. To this end, read access control can be done by encryption, like in the FAQ-based single-client MCORAM construction. Write access control can be done using zero-knowledge proofs. This approach, however, only results in a weaker integrity, called accountable integrity. Achieving full integrity seems to be impossible in the multi-server setting. In terms of communication, which we care most about, we observe that the communication complexity is dominated by the dpf share size. Therefore, if we want a multi-server MCORAM scheme with polylogarithmic communication, we just need to build a dpf with polylogarithmic share size. For this purpose, we look at the literature. Currently, there are only two dpf constructions from non-latest assumptions. The first one is secure against one out of two servers and has polylog share size. The second is secure against two out of three servers but has square root share size. In this work, we add another two out of three scheme and a three out of four scheme to the table. Both of them have polylogarithmic share size. Very briefly, our constructions are based on the observation that the evaluation algorithm of the first scheme can be computed by an NC1 circuit. Therefore, by emulating each server using a homomorphic secret sharing scheme for NC1 circuits, we obtain the results. For the purpose of constructing MCORAM, what it means is that we now have a 1-4, a 2-9 and a 3-16 multi-server MCORAM with polylogarithmic communication. You are welcome to check out our paper for more results. This includes an equivalent simulation-based definition of MCORAM. To conclude, I am happy to tell you that MCORAM with polylogarithmic communication indeed exists.