 Hi everybody, I'm Ilan and before I start the talk I want to wish everybody happy Labor Day and To mention that today is also Yomad Yomazikaron, which is the Israeli Memorial Day for the fallen soldiers of terror attacks and Wars so happy holidays and let's remember all the fallen victims all the fallen soldiers and Now I'll begin to talk. So this is joint work with Gilsega from the Hebrew Hebrew University And let me get to it So we just heard what functional encryption is It's just a standard encryption scheme which is which allows Alice that has a public key to encrypt messages and the the additional functionality that functional encryption gives us is that The holder of the master secret key can generate keys for functions that allow Somebody that has a ciphertext and the key for the function to evaluate The value evaluate the function on the underlying ciphertext But without learning anything new about what is encrypted inside the ciphertext We'll be talking a lot about the private key Notion of functional encryption Which we think about in slightly in a slightly different scenario where there is a holder of a master secret key And there's a database or a server that stores Ciphertext sent by the user that holds the master secret key The server a when he has only the ciphertext knows nothing of course about whatever is encrypted underneath But the holder of the master secret key can generate a key for a specific function of its choice Delegated to the server send it to the server and the server will be able to compute the function f of Whatever is encrypted inside a ciphertext, but without learning anything except it it's a very useful notion and Here's a Simple example of what we can do with it. It's something I call positivity revealing encryption So as long as the server has only ciphertext that in codes are messages He doesn't know anything about what's inside But once Alice generates a key for a function, which is just the greater than zero Then the server can compute whether the encrypted the Messages of a message which is greater than zero or not, which is something it couldn't do before The security that we'll be relying on is what we call in distinguishability based security And it says that the server give is given a list of functions f1 to fl And he sees a bunch of ciphertext corresponding to messages and one to MK He'll be able to learn fi on of MJ for any i and any j but nothing else And nothing else is the standard in distinguishability based security notion What do we know about this primitive? We know quite a lot about it and the highlights are the following three constructions There's a very simple construction or very it's of the sort of garble circuits and stuff like that That gives you some sort of Some sort of limited functionality and specifically it gives us a bounded number of Functional keys and the ciphertext are quite long in some sense and in the private key setting We know how to do it based on any one-way function and in the prior public is setting We know how to do it based on any public encryption scheme If we want to somehow make the ciphertext shorter in some sense, which I will not explain then we know how to do it from LW And we have the perfect construction based on IO Which gives us an unbounded number of keys and very short ciphertext and it's very very neat construction and the question that we care about in this work is Is I own necessary to construct functional encryption schemes with unbounded number of keys? It seems like this is the only way we know how to construct it. So is it necessary? So let's see what we know about this question So in the public key setting, we know that public key functional encryption is essentially equivalent to IO I actually mentioned those works of an Anthony Jane and Bitansk and Van Kutanathan In the private key setting up until recently we didn't know anything except that they imply just one-way functions And we have at least some limitation result telling us that black box Constructions will not give us anything better than one-way functions This is the work of Shalov and Segev A very recent work from half a year ago of Bitansk et al showed that If you take a private key functional encryption scheme and combine it with very strong one-way functions Then we may somehow get public encryption, which is kind of surprising at the time it was and they had another result that if you take a private key functional encryption and Add a public key encryption, then we get all IO So that's kind of kind of Answers the question, but they have additional assumptions. For example, the private key functional encryption scheme needs Some public key primitive. It needs a public key encryption scheme And of course they somehow bypassed the black box barrier of Shalov and Segev and the non-black's component is a previous work of Brachiaro scheme myself and Gil and Segev from last year's crypto Okay, so what do we know? Basically the world looks as follows we want to construct an IO scheme and I will try to explain Which what kind of the IO we can construct from from any primitive and I will talk about a bounded input IO which says how many inputs can it support? The length of what inputs can it support? So an IO scheme that supports only logarithmic number of inputs is trivial to construct, right? You just write the truth table It has no applications and it's trivial to construct IO that supports polynomial length inputs Gives us all applications of IO and we know how to construct it based on public EFE or Private key FE and public encryption. This is what I just said in last year's Eurocrypt We had the paper showing how to construct just from private key FE and IO scheme that supports slightly more than logarithmic number of inputs and As an application bitansky et al showed that if you add very strong one-way functions then you get public encryption scheme from this primitive and The main result in this work is a construction based just on quasi polynomial secure private key FE We construct an IO scheme which supports a poly logarithmic number of inputs The length of the inputs that it supports is log to the one plus delta for some fixed constant delta times n And we show that as an application if you add Sub-explanatory secure one-way functions then we can get we can get not only public encryption but actually Public key functional encryption and we can also get other applications of IO such as PPAD hardness and more So this is the main result. This is just Saying it again more exactly So we construct the main result the main theorem we're gonna talk about is a construction of IO For circuits that have polylog many inputs based on quasi polynomial secure functional encryption and we have two applications that I mentioned and Recently last week a Kitagawa, Nishimaki and Tanaka uploaded the paper Proving that private key FE implies full-fledged IO It seems it improves over our theorem, but their techniques are completely different and I think this is Still interesting So let's see what what the applications gives us at least in terms of assumptions a PPAD hardness is a very important question I will not define what it is, but it is very important and What we know so far is is constructions based on Strong assumptions VVB IO public here fee and our work shows that basically you can get the same application PPAD hardness but based just on private key FE with quasi polynomial security and A very cool open question, which is on this matter exactly to prove hardness based on weaker assumptions I think that's a very important question So let's dive into our construction and proof So we work using the notion of a multi-input functional encryption scheme This is an underlying primitive and let me define what the two input functional encryption is So it's very similar to a single input Functional encryption in the in the private key setting where there's a player Alice that has a master's secret key It can encrypt messages and one and two and three and so on send them to the server and At some point in time it can also generate a key for a function F But now the function F gets not a single message as input, but two inputs as input So the server can learn F of M1 and M2 for every ciphertext of M1 and M2 and A very nice application of this notion is what is known as order revealing encryption Which allows the server to learn which ciphertext is greater than the other with ciphertext encodes a message Which is greater than the other this thing is very useful in searchable encryption and has many applications and You can also generalize this definition to a team put scheme where the function gets team puts as input So what do we know how to do? How to get a team put scheme So we know based on the work of Goldwasser from a couple of years ago that we can do that This primitive exists based on IO A bonnet I'll had a construction based on multi linear maps Ananta Jane and the Tansky and we couldn't nothing had the work based on public key Fee last year We obtained a construction of this primitive based on private key Fee But the number of inputs we could support was limited to log log a to double W Logorithmic and in this work, we can support a poly logarithmic number of inputs Let's see how this primitive is related to IO Basically, what we show is that private key Fee implies IO This is the main theorem private key Fee implies IO with circuits for of poly polylogorithmic input size and The way we do it as is that we show a generic transformation Information from any t input functional encryption scheme to a 2t input functional encryption scheme So we start with a private key functional encryption scheme Make it a 2t in it make it a 2 input functional encryption scheme and then a 4 and then 8 and so on so forth Until we get to log to the delta number of inputs And then we take this primitive and show that it's equivalent to IO with log to the 1 plus delta inputs Okay, let's see how the last step is done the last step We said is that a t input private key functional encryption scheme implies IO for circuits of length t times log of n of inputs of time of t times log n How this is done so we want to construct an obfuscator based on the private key functional encryption scheme The obfuscation of a circuit C is very simple. It's just a key for a function a Key for the circuit plus we'll have a cipher text encoding all messages of length length to logarithmic Each one corresponding to a different index in the multi input scheme So SK sub C is the key for the function C and see the IEJ is a cipher text encrypting them the string I with respect to input J and To evaluate it's very easy. You take the key for the function you take the cipher text of Cypher text that you want to evaluate on and you can get the value of the circuit That's That's given immediately based on the correctness of the functional encryption scheme Security is proven quite easily. It's also quite immediate Especially if you assume that the functional encryption scheme is function private something we can get generic generically So we basically know now that a team put functional encryption scheme implies IEO for circuits That have t times log n number of inputs So we are left to show how we construct a 2t input functional encryption scheme based on a t input functional encryption scheme And this will finish the job So we start with an a with a functional encryption scheme that supports t inputs The master secret key will be just a master secret key for the functional encryption scheme and the PRF key When we want to generate a key for a function that gets 2t inputs We generate a key for a function that gets only t inputs and it has hardwired the PRF key K What it does is it generates a new master secret key for the t input scheme That depends on all the t inputs that it got as input and it generates a new key that will get later the second part of the input the other t inputs when we want to encrypt an input x corresponding to an index I We will just encrypt it using the previous scheme and When we want to encrypt an input y which is of the second part will generate again a key for a function that we call a gg for aggregator and The key for the function will have y hardwired inside and the same PRF key it will generate again the same master secret key for the t input scheme and Output a ciphertext of y under this under this master secret key It's sort of a re-encryption circuit Okay, this is the full scheme So let me repeat what's going on here. We want to construct the 2t input scheme based on the t input scheme The t input scheme supports functions of t inputs So we can generate keys only for t inputs and we can encrypt messages only for Only for t indices So the first t indices will treat them as standard indices in the t input scheme and The last t inputs will generate keys for the a gg function Which allows us to re-encrypt the cypher re-encrypt the message Based on a master secret key that depends on x1 to x2 and The same master secret key will be generated by the gen function when we generate a functional key How is decryption done? Decryption is done in the following way. We generate a Secret key that corresponds to the function f star which has which is just f with x1 to x2 hardwired inside Given all these ciphertexts Then we will generate a new ciphertext for every y For every y ciphertext, which is the ciphertext of the same message, but under a new key Then we'll combine f star with ct prime and ct with all the ct primes So this is how decryption is done more pictorially. It looks something as follows We get a key for a function f and we get t ciphertext corresponding to the first t inputs And t ciphertext corresponding to the last t inputs. We'll call them ctx1 to ctxt and cty1 to ctyt We first take the key for the function f and all the ciphertext corresponding to x1 until xxt and Generate a new key for the same function f, but now it has hardwired x1 to xt and It is under a key that depends on x1 to xt Then we'll take all the ciphertext corresponding to x1 and xt and Take the key, which is the ciphertext of Which is a ciphertext of y It's a functional key for the function that takes all ct all x1 to xt and generates a new encryption of y under the key that depends on x1 to xt So we get ct prime y1 We'll do the same for every y and we'll get ctyt prime and Now we take again the key of f star with the ciphertext of y1 until yt and get the value of f on x1 until xt And y1 until yt. So this is how decryption is done or evaluation The proof of security is as follows So the high-level idea of the proof of security is to get rid of somehow of the PLF key That's the only secret we have basically In in all the functional keys So we need to somehow get rid of the functional key PRF key the technical technical challenge is Is to get rid of the PRF key and we do it using a puncturable PRF function privacy and lots and lots of hybrids The idea of the proof is to attack each x1 to xt separately. So we somehow have a Sequence of hybrids each one attacking x each x1 to xt separately and the idea is to take In every ciphertext corresponding to a y which is key for a function the agg function will Hardwire ahead of time the ciphertext Under the master secret key that depends on x1 to xt and we'll do the same in the key in the functional key for f will a Hardwire inside jet the gents function the secret key of f sub x1 to xt with with With and then we will not need the PRF key basically That's the proof idea and Questions questions So you are able to do this log to the delta times. Can you explain what the limitations are that lead to that bound? Yeah the ciphertext blows up polynomially at every at every iteration of this No disk transformation, so cannot do it too many times That's basically the reason