 So today, I will be talking about our recent work on FHG in the RAM model. This is a joint work with Justin, more Weiss, and Daniel Wicks. So consider the setting where I actually know which button to press to advance the slides. Consider the setting in which we have a data owner that has some database that they wish to outsource to the cloud encrypted. We're considering, in this case, the server to be our adversary, and this data owner would like to allow other clients to essentially upload programs to the server, the server to execute them and hand back the encrypted results. So in this paradigm, we have a client who says, I would like to run a binary search program across this database that this data owner has provided. So the client has to hand some representation of this program to the server for it to run. And the traditional FHG setting, this program takes the form of a circuit, whether it be Boolean or arithmetic. So it hands this over. The circuit by necessity takes in the entire database as input and outputs some encrypted result, which is then handed back to the client to do with what they will. I will note in this setting, the server itself can also submit programs that it wants to run, and it will get some encrypted output, but without the key, the output is essentially meaningless. So in this setting, where we're considering a circuit representation of this program, the run time by necessity is going to be at least linear in the size of the dataset, which in the case of algorithms, such as binary search, which would have a logarithmic run time in the size of the database, is really, really suboptimal. So this motivates the case of can we consider a different model of computation to allow for FHG, particularly if we are able to give the underlying program in its RAM program format, essentially, we give the server some representation that allows it to make queries into this encrypted database, get that value back, and fold that into the subsequent computations, so on and so forth, until we get the encrypted result. Well, this is the model that we are working in, and it much more closely adheres to the underlying run time of the program offered to the server, namely, in this case, we are able to achieve a run time much, much more sort of close to our underlying log N run time of binary search. So this is the model of computation that we want to support in our RAM FHG, setting and construction. I will note that we differ from other primitives sort of of this type, such as Garbled RAM, in that we allow any person to come along and submit these programs, essentially, and we are not limited to a certain class of program. Essentially we can say submit NEP here and have the server essentially run this and get some encrypted output. So that being our setting, our goal of this talk is to construct the first sort of proof of concept construction of RAM FHG, and to run in this setting essentially any RAM program across an encrypted database. So syntactically, what does this look like? It is essentially the standard FHG syntax or public key encryption syntax in which we have a key generation algorithm, an encryption algorithm that takes in the database, and outputs an encrypted version of that database, and a decryption algorithm that takes in decrypts if you have the secret key. In addition, we have an evaluation algorithm that is capable of taking in some RAM program P, some time bound T, which we expect P to run in less than, and outputs the encrypted value of running P across this encrypted database. So here represented as P superscript DB, and this value is encrypted using the public key. Decryption then is able to take this value in and essentially output the result of running this program across this encrypted database. We say that security is standard indistinguishability, CPA, we should not be able to distinguish between two database encryptions, nor should evaluation give us any information to be able to do that distinguishing. What I've shown here is what we call our single hop FHG RAM paradigm, which is to say that essentially any program that we want to run for evaluation is run across the same database. Updates are not made as part of the program. We also have a multi-hop variant, which does allow for updates in this database that are present and can be folded into subsequent RAM executions. I will be focusing primarily on the single hop version today, see the paper for more details on the FHG multi-hop version. So in this setting, we are able to achieve at a high level a scheme based on secret key, doubly efficient peer or D peer, which is a primitive first introduced by Kennedy et al and Boyle et al in 2017, and VBB for a specific class of circuits. These are fairly heavy duty primitives, but we are able to show that even with assuming these, it is not a straightforward construction, which is why this is sort of the first proof of concept in this class. We are able to get in terms of complexity for any epsilon greater than zero, an evaluation run time for our single hop case, in which is T, where T is the run time of the underlying RAM program, lambda is our security parameter, and N is the size of our database. We are able to get essentially a run time that only has a polylog N overhead over just the plain evaluation of the program. For our multi hop case, same parameters except that we have an N to the epsilon overhead as well, essentially representing the changes that you have sort of done to the database and ingesting those. We also introduce as part of our construction a variant on an ORAM that we call Rewindable ORAM, which we believe is a primitive of independent interest. So without further ado, I want to go into a little bit of how we actually construct RAM for FHE. So remember our setting where we have our database, we have our evaluator that takes in a program, a time bound, and outputs an encrypted result of evaluating P over this dataset. We have four primary difficulties in this construction. The first of which is because we have RAM access to this database, inherently we have access patterns. What elements of the database that the evaluator is actually accessing. And we have to hide these access patterns without necessarily having a consistent state between different executions of different programs. We also need, within an execution of a single program, the ability to evaluate or emulate statefulness, so program essentially has state, you can think of it as the register contents or things like that. And we need to hide this evaluation state from the evaluator or the server who we are considering malicious. We also have to enforce honest behavior of this evaluator so they don't essentially twist the evaluation of the program in order to get information about the database. And finally, as part of this evaluation process, hiding access patterns and encrypting this final result requires randomness. So we need the evaluator to be able to generate that to feed it into those two steps. So those are our four main areas of difficulty today. These three, with some crypto tricks and throwing BBB off your skation, are tricky but quite doable. This one is the main source of difficulty here. How do we hide access patterns without necessarily having a consistent state? And that's what I want to focus on today, which is how do we build a tool that allows us to hide these access patterns? So to motivate why this is difficult, consider our following case where the program that we are asking the evaluator to evaluate is the following. If we have, we essentially read the first element of the database, and if it is less than five, we do some access. If it's not, we read the third element and do a different access. So inherently built into this program is some information about the first element of the database, and the evaluator, even not getting the decrypted output, can tell what is the first element of the database or at least some information about it based on the access patterns alone. And this will now remember our RAM FHE security goal. This will break it. So hiding access patterns is imperative if we want to achieve security of our overarching RAM FHE construction. So consider the case where we solved all of the problems, VBB does everything, and so what we're going to do now is, forgive me, some of the graphics have gotten a little messed up in the translation process. So consider this being the ORAM client state. So we have as part of our evaluation process an obfuscated ORAM client with some state. If we want to run the program, which is going to be P here, from our previous example, and all of these accesses are now happening underneath sort of the ORAM client here. We can say that these access patterns are essentially hidden and not giving the adversary any information about the database. However, the ORAM client is going to essentially run. It will update its own internal state. It has to do so in order to provide obliviousness, either push things down a path or shuffle things around depending on your ORAM construction. Once we're done with this program, however, and we want to run another program, imagine that this is changing different colors to represent a new state. The ORAM is now in a new state. In order to run another program, however, P prime, this state is going to revert back to our original ORAM state because things are not preserved between different executions because we are in sort of a case where state is not shared. In practice, the state is going to be rewound. When we execute this program, we are making essentially the same style or the same first access in P prime as in the original P. We are going to get the exact same first access pattern in our subsequent program execution as we did in our initial one. This means that essentially standard ORAM schemes, because our state is not maintained between two different program executions, are not going to maintain its obliviousness. It will have the exact same access pattern, because that initial element is going to be in the exact same place in that initial state. So we are not providing obliviousness. We are not no longer hiding access patterns, and thus our RAM FHE security is going to be broken. If we just assume we have a standard ORAM client using VBB obfuscation, which makes us realize that we need an oblivious RAM with an additional property, namely, we need security, so obliviousness is maintained when the client and server state are rewound to an initial or previous state. We introduce two variants of this. We have a initial state rewindable or ISR ORAM, where we say obliviousness holds if we only rewind to essentially this initial state, and subsequent executions or access patterns essentially create two parallel execution paths. This is analogous to our single hop and FHE, in which this is the actual ORAM used to hide access patterns in that particular construction. We also introduce a notion of any state rewindable ORAM or ISR ORAM, which instead of having sort of two parallel execution paths allows you to branch off from any intermediate point. We have here that this is used primarily in our multi-hop FHE scheme. We formalize this through standard correctness and security games as in standard ORAM, what we say that is parameterized through the state that you are in. Our construction relies primarily on secret key deep here. This is essentially, in essence, a read-only ORAM scheme with a stateless client and server. We have a setup function that takes in a database, outputs some client key, and an encoded database which is then handed to the server. We say that essentially this gives us the same obliviousness security guarantees as standard ORAM, but only supports reads. At this point, we have constructions for this by Canadi et al. and Boyle et al. based on noisy, permuted read-muller codes. We can get different parameters based on the underlying read-muller paradigms. What we have now is essentially a read-only ISR ORAM. The question is, how do we support writes? We do this using a standard ORAM, but the trick is when we initialize that standard ORAM. Our setup procedure takes in our database, generates our client key, and generates the encoded secret key deep here version of our database. Access also now is going to be in charge of initializing the standard ORAM. Our first access, regardless of whether it's a read or a write, will generate a standard empty ORAM and hand that to the server. Subsequent accesses, if it's a write, will grow that ORAM, writing to it, growing it as needed. Read accesses will read both of these two data structures and take it from the ORAM if it is present, representing any updates that have been done to the static encoded database. We get security here because any rewind will essentially erase that standard ORAM that is created upon the first access, and the secret key deep here is essentially stateless, giving us rewind security for free. So in terms of our results, we are able to construct an ISR and ASR ORAM scheme based on secret key deep here, the schemes inherent, the secret key deep here complexity, namely initial state is poly log in the size of the database, any state is slightly more complicated but not much, and we are able to use this primitive now within our FHE construction. So if you remember our four main problems, we now have essentially tackled this one by saying state does not matter, so we do not need to maintain a consistent state. We now have three remaining challenges, the first of which is how do we emulate statefulness and essentially hide that client's state? What we do here is represent the program as a series of obfuscated step circuits, so essentially a step circuit is going to take in the current client's state, it will take in a database entry, basically the database entry as requested by the ORAM client that the step circuit is running, and the state itself will be encrypted under a hardwired key within this circuit. We will then sort of do whatever the program tells us to do, update the state, and ask for the next value in this database. So the evaluator is essentially just running a series of these step circuits up to time t. We then throw obfuscation, VBB obfuscation over that entire thing and call it a day. So that is how we are able to get statefulness and hide that client's state from the evaluator. We also need to enforce honest behavior in order to get correctness for our reliable ORAM schemes and also security. The way we do this is to that step circuit we add two things. We add a MAC of the client's state in order to say that we don't mix and match state. We also over the database instantiate a Merkle tree. So when any element that is given to the step circuit is also given the path in the Merkle tree, which the step circuit can now evaluate and make sure that it is getting handed the correct database element that it asked for. So that's how we enforce honest client, sort of honest input into this step circuit. We also, Merkle tree, and then finally we have to generate randomness. The way we do that is we hard code a PRF key within the step circuit. And in order to generate randomness, apply the PRF across the entire execution history to generate unique randomness for that particular instance. In summary, this allows us to construct the first proof of concept, FHE for RAM construction. In order to create that construction, we also introduce a variant of ORAM that we call Rewindable ORAM. And we are able to get the following parameters for our FHE for RAM construction. We provide a single and multi hop version. And for our Rewindable ORAM, we provide a initial state Rewindable secure, and in any state Rewindable secure, already. There are a couple of open problems from sort of introducing this as a construction and a concept. Our main sort of open problem of our construction is, can we reduce the assumptions that we rely on? Is it possible to get RAM FHE from IO or something similar? Also, is it possible to contextualize the underlying noisy, permitted read-muller code assumptions that secret key DPR relies on? So thank you at this point for listening to my talk, and I'm happy to take any questions. If you have a question, please come to the microphone. Great, thank you for the nice talk. So on one of the slides, I was wondering that you have the SKDPR and you have the standard ORAM. And in the read and write operations, in one of them, you do read from one of them. You do operate on one, and in the other, you operate on both of them. So how do you hide that pattern? Like, how can you make it indistinguishable? So essentially it's, as you would any ORAM, you do a dummy operation. So for reads, you do a dummy read, or so you do valid reads essentially on both of the two. And on a write, you have, so if you want to be able to hide, we don't necessarily, but it is trivial to hide the difference between read and writes. If you're going to do a read operation, you also grow your underlying ORAM. So the size of the ORAM is now going to grow with the total number of operations rather than just the total number of writes. Thanks, I have another question. Okay, so do you know any of the existing implementation of SKDPR? Like, can you comment on concrete efficiency, such things? I know that there are a couple of different sort of asymptotic evaluations of different paradigms. I am not aware of any concrete implementations of secret KDPR. It would share fairly similar parameters as to any implementation of read-molar codes, yeah. Let's thanks to speak again.