 Okay. The next talk is Comcomitting Restriction with Art Mali. By Dr. Gantli Kri, Oksana Rodina-Laya, and Mariana Lecombe, and Steve Rice, Oksana Rodina. Thank you very much for the introduction. So before I start my talk, I just want to warn you that this is a very theoretical result. And if somebody here is allergic to confiscation, well, I won't. So let me start with a motivating example. Let's say we have a bunch of ciphertexts encrypting some messages under the same public key. And let's say the adversary gets to open some of them. And what do I mean by open? Well, it gets to see randomness and the plaintext which is encrypted. Can we still guarantee security of unopened ciphertexts? And our intuition tells us, well, encryption scheme should protect security, but life turns out to be miserable. So it turns out that this answer actually depends on whether the adversary is adaptive or not. So in particular, consider the static case first where adversary has to tell beforehand before he sees a ciphertext which exactly ciphertext he is going to open. So he says, I want to open number 1, 2, and 5, and then he actually sees the whole thing. In this case, you can show away a simple hybrid argument that unopened ciphertexts actually protect messages. But in adaptive case, we cannot perform the same proof. And actually it turns out there is a specially crafted counter example when this thing breaks completely. And let me just tell you what it is. So consider a secret sharing scheme with threshold T and let's say adversary gets to see encrypted shares and can open some of them. Such that open threshold shares he learns do not allow him to actually reconstruct the secret. Can you guarantee that the adversary doesn't learn the secret? Well, intuitively, you want to say that other shares are protected by encryption but this intuition turns out to be completely false. So there exists a very specially crafted secure encryption scheme such that adversary can learn the secret. So what is our takeaway from this example? Our takeaway is that adaptive security is a complete mess. In adaptive case, standard encryption doesn't provide you guarantees which you expect. Now let's move to a more serious example of generic protocols. Again, you can consider two settings, all static protocols and adaptive protocols. And in a static setting, adversary has to commit beforehand on to which part he is going to corrupt. In adaptive security, adversary can make adaptive choices. He can first absorb communication and later decide to corrupt some party and maybe he learns some important information from this. So now he knows that those two guys are very important and he can actually target his attack. So this security notion turns out to be much harder to achieve but it much better captures real life. And so non-committing encryption, which is the title of this talk turns out to be a very important building block for such protocols. Namely, it allows you to implement secure channels in adaptive setting. So you start with the secure channels, you encrypt your message. You start with a protocol which is secure in secure channel setting and then you encrypt every message under non-committing encryption and the result in protocol turns out to be secure. If you just encrypt with a standard encryption there is no guarantee whatsoever on security of the final protocol. Okay, so let me talk about definitions. Essentially, non-committing encryption is adaptively secure encryption. So you can think about this as a protocol which allows you to transmit a message out. So what does this mean for this protocol to be adaptively secure? So it means that the adversary may first absorb communication which in symmetric case is just the cybertext and then corrupt parties and learn all their internal state which is their message and the key. And if you want to guarantee security you need to provide a simulator who would simulate the view of the adversary which means that first it has to simulate communication which is the cybertext and he has to do this without knowing the message. So your simulator has to show the cybertext without any message inside. But later when corruption happens the simulator has to simulate random coins of every party. So you put this dummy cybertext there was no message inside and now somebody tells you my actual message was this and you have to provide a consistent key for this specific message. So here is the exact syntax and security tells you that the real cybertext and the real key are indistinguishable from simulated cybertext and the simulated key. In particular if you try to encrypt or decrypt things should look consistent. Just a simple example in the symmetric case one time bad is a great non-committing encryption because the simulator can choose a random cybertext and later when the message comes in you can open it to any message that is. So what about the public key encryption you can consider the same notion with the public key setting. So now the simulator has to simulate the whole communication which is public key in the cybertext and later given message M you have to provide consistent random coins which are randomness of encryption and randomness of key generation. So in the symmetric case we have a very very efficient non-committed encryption scheme with rate one. And what about the public key case? But before we go there let's talk about how do we define the rate of NCE in the public key case. So in symmetric case it's very easy just the cybertext, the number of bits you send in the cybertext per number of bits of the index and in asymmetric case it's something unexpected you need to actually count not only the cybertext but also the public key size. Why I say this is unexpected? If you talk about standard public key encryption you usually don't include your public key inside rate. Why so? Well because your public key can be reused. So you send one public key and then you send a lot of cybertext and essentially your public key gets amortized. So you don't include this into rate. But non-committed encryption it turns out that public key cannot be reused. And just in case you care non-committed encryption NCE actually means not full for environment. So there is a lower bound which says that the size of the secret key should be as large as the size of the message. Why so? Well remember how the simulation works. You first simulate some empty cybertext and then for every message there should be a corresponding secret key. So you have to have as many keys as you have messages and basically once you set your key with this size of the secret key you can only send that many bits. So it makes sense to view non-committed encryption not as a public key encryption but as a two round protocol. If you need to send many bits you just send out many public keys and you get back many cybertexts. And the rate of such thing is just the total communication over the total number of bits you send. And let's talk about some prior works. So we started with a bunch of works which roughly followed the same approach and what they did they encrypted their plaintext bit by bit and the resulting rate was very high. You need to send the security parameters where bits of cybertext per each bit of plaintext. And recently we got some new works from Algebra which got a much better rate in particular the last work what the rate which is polylogarithmic and secures the parameter. And in our work we show almost optimal rate which is almost one and I will talk about more what this means but we assume a very very strong things. So we need authorization and we work in something called a common reference string order. So this is our result. And more strictly the theorem says assuming IO and boundary functions you can have NCE which is rate which can be anywhere close to 1 in the common reference string model and our scheme is actually the first perfectly correct way of making an image. So what is a common reference string model? Basically this is a model where both parties have access to some pre-generated string. Think about Microsoft publishing some code on its website such that every party can go and download it. And let's talk about the rate in the setting so now by rate we mean the total communication including the size of the common reference string over the number of bits you send. And why do you want to include the size of the CRS? Well if your CRS allows you to send only one bit and you need to get the new CRS every time then you cannot really say that your rate is small, right? You need to download the whole thing every time. But luckily in our work the CRS is reusable for any polynomial number of distributions. So essentially you get your CRS once and then you can send your bits as many times as you like. So the size of the CRS gets advertised just like in public key setting you can advertise your public key size. And just more completely the size of a single public key in our scheme is just two lambda and the size of the cybertext is two lambda plus l. And so if you do computation then you see that our rate is essentially this. So it's one plus something lambda over new message and as long as your message is sufficiently large this rate goes to one. And if the bigger message you are sending the smaller rate will be. So let's talk about the construction. So we are going to do this in two steps. First we will build a primitive which we call sense and the thing about this is a non-committal encryption with erasures. And then we are going to bootstrap it to full non-committal encryption with constant rate. And at the end we need to start with a non-committal encryption here which has a short cycle. So what is this sense? It's a non-committal encryption with two additional properties. First property is that security holds only as human erasures. So it's not a full non-committal encryption you are actually allowed to erase some information. And which information are you allowed to erase? You don't need. So for example the sender doesn't need his randomness once the cycle takes it out so you can erase that. And the receiver doesn't need his randomness of key generation so you can erase this. But he still needs his secret key. So secret key should be still there. And in particular this is exactly what the adversary expects to see. So this is what we need to see. So that's one thing. And the other thing is called the same public key property. And this is a very technical property which is needed deeply inside the proof. It says that if you generate your public key from some random coins here honestly using the real generational rhythm and here you simulate them using the same random points then those two public keys are exactly the same. So usually you require just a utility of real and fake public keys. So this is a stronger property. It says start with the same randomness you get exactly the same string. So this is our sense. And we build the sense from IO and one of the functions with a very short cycle text which are just two loud double sounds. And the scheme is perfectly correct. And before I go into the construction let me just say a word about IO. So we have several notions of obfuscations. One notion is called a black box obfuscation which sort of tells you that you can completely hide whatever happens inside your program. But unfortunately we don't have this notion. So we can only work with something called indistinguishability obfuscation which says that as long as two programs are identical you cannot distinguish between their obfuscated functions. So for the purpose of this talk you can really think about black box obfuscation but in the paper we need to work with IO and so this is the main technical challenge. Ok so how to construct this sense? Recall this symmetric key encryption from PRF which says that to encrypt the message L you one time paired your message with PRF on random SR and you publish R and SR and to decrypt you do whatever you expect to do. So to build a sense we obfuscate encryption and decryption already. So my public key is going to be obfuscated encryption code and my secret key is going to be obfuscated decryption code. So what's going on in the scheme? The receiver will sample some randomness and use it to create obfuscations and once obfuscations are created he doesn't need this randomness anymore so he erases it and he keeps the secret key for himself and he sends out the public key and the sender can use the public key which is encryption program on his own random codes to encrypt the message M and send it over. So this is basically the scheme, very simple just obfuscated encryption and decryption and this scheme has a very short time index so you need for some reason you need to run the beads for the randomness and then the second part is just the size of the message and it has the same public key property our simulator will generate exactly the same public key. So we are done with the first step we build the sends and now how to transform the sends into the real non-committal encryption. So here is a high level idea in the CRS we will put two special programs which will help parties to sample some common parameters of underlying sends and the receiver will in round one will send some very short almost random stream T which will use which will be used by both parties to derive the same key of sends namely the receiver will somehow derive the secret key of sends and the sender will somehow derive the public key of sends and then the sender can just use this public key to encrypt his message and send it back and the receiver decrypts so essentially the core of the scheme is underlying sends and then is how exactly do you perform this sampling. So little bit more in detail those two programs GenN and GenDeck will have a shared master secret key and they will sample the same public key and secret key of sends using this master secret key and now let's go over the actual code so the receiver picks his generation randomness from GenDeck on this randomness and here is what happens so first this program applies some very special hash on this randomness and gets this short T and remember T is going to be used to sample the common parameters here how we do this we apply a PRF with master secret key on this T and get the randomness is actually used to sample public key and secret key of sends and then the program outputs whatever the receiver needs to know which is the secret key and the short T now the sender is going to pick two random strings one is randomness for generational illusion and he will run his GenEck program on this randomness and the T he got in round one so this program will run the same PRF with the same secret key on the same T and not surprisingly it will get exactly the same randomness R as the other program and then it will sample exactly the same public key and the secret key of sends after this it will output the public key but not the actual public key but obfuscation of this public key so why do we need obfuscation here well this is somewhat technical and you need to know the proof so whilst he knows obfuscated public key he can pick his random points of encryption and run an encryption algorithm output the secret text and the receiver can be created so this is the secret and you can check that it has all properties beneath it is as correct as the underline NCE it is secure because essentially remember that underline NCE was only secure under erasures so you had to erase your key generation randomness R from the whole picture here it's present but it's sort of sitting deeply inside the programs so nobody actually knows this key generation randomness including parties only problems know it so that's why very roughly why security to security of underline sense and finally the communication size is very short, small you send just the D which is size of two lambda and you send the underline cyber text of sense which we built to be very short okay let me summarize so we built a rate one public key NCE so technically speaking this is almost as good and bad you get rate one but of course this is very very practical because in our scheme we have to use triple nested applications so you have to take the code obfuscative append some more code obfuscative so it would be interesting to build a practical NCE with constant rate not just rate one any constant rate or if you cannot do that it is to reduce the number of nested applications in this construction I think it's also very interesting I'm really curious to see any real definition we use for nested applications I wonder if this is possible okay thank you very much thank you