 floor is yours. Hi everyone, welcome to my presentation on multi-designated receiver signed public encryption. CCC's joint work with William Auer and Christopher Portman. Oh thanks, sorry. Okay, so in this paper we introduced two new types of public encryption schemes. The first one is as in the title and the second one is called PKEBC or public encryption for broadcast. We also give constructions of both of these schemes from standard assumptions and I would like to note that any MDRS PKE scheme which satisfies anonymity yields a multi-designated verifier signature scheme or MDVS with privacy of identities. This means that we give the first MDVS scheme with privacy of identities from standard assumptions. Okay, so now let's look at the syntax for PKEBC schemes. So suppose you have a standard Alice and five receivers B1 through B5 with these public keys. So RPK just means receiver public key and the similar for RSK. So if Alice wants to send a message to say for example a factor of receivers B1, B4 and B3, she just encrypts it using this factor of public keys and the message and then to the crypt, for example, B1 will just use his own secret key and he will get back not only the message but also the factor of public keys with respect to which the suffer text was encrypted. I wanted to point out here that the decryption algorithm really only needs the secret key of the receiver. So this is important because for example if the encryption scheme achieves some sort of anonymity, if the encryption would need the public keys of the other parties, then the receiver would have to guess who the other parties are or who'd have to know that in advance. And then the receiver's public keys is also output so that the party knows who the other receivers were. Okay so we consider these three notions as the basic security notions for PKEBC schemes and as an addition we'll also consider anonymity or IKCC to security. So consistency is captures the following. So even if Alice would now be dishonest, she cannot come up or any suffer text she might come up with will satisfy that if for example one of the honest receivers decrypts it and obtains some message and some factor of public keys, for example B1, B3, B5, then any other honest receiver whose public is in this factor when it decrypts the same suffer text will obtain exactly the same factor and exactly the same message. Then there is also robustness. So robustness is considered a non-assender and honest receivers and this is similar to the robustness notion for normal PKE schemes. The only difference that it's adapted for PKEBC schemes. So basically if Alice sends a message to say B1 and B4, of course B1 would still decrypt it normally but if for some reason B3 gets also this suffer text when he tries to decrypt it he will not get anything. Then we also have confidentiality. So if Alice sends a message to two honest receivers, a party who is not one of these receivers and who is dishonest will not learn anything about the underlying message other than the size of the message. So in this case B5 would not learn anything other than the length of the message. Similarly, sort of similarly for anonymity, B5 will not learn who the receivers of the message are although it will still learn that the the suffer text is intended to two receivers. So for example it would not be able to tell if the receivers of the suffer text were B1 and B4 or maybe there were B2 before or any other possible combination of honest receivers. Okay so with this let's just have a look at how and how one can construct PKEBC schemes, PKEBC scheme. So we'll first recall Norayung's NCC1 PKE scheme and then we'll show how to make it how to turn it into a PKEBC scheme and finally we'll make it actually anonymous. So as building blocks for Norayung's PKE scheme we'll have an in-CPA secure PKE scheme and also a non-interactive zero-knowledge proof. The key pair generation algorithm will generate two key pairs for the underlying CPA scheme and also a CRS for the NISC. The public key will consist of the public keys for this underlying CPA scheme and also the CRS for the NISC and the secret key will just be the secret key of one of these CPA generated secret keys. I mean one of the secret keys that were generated by this CPA scheme and also the public key, sorry. So for encryption what the sender does is it just generates two cipher texts. Each of them are an encryption under one of the public keys of the receiver of the message and then uses this NISC scheme to prove that there is some message that both of these cipher texts are encryptions of the same message. Of course then the cipher text for this PKE scheme will correspond to the NISC proof and the two the two cipher tests that were generated. For the encryption a receiver will first check if the NISC proof is valid for the same statement and if it is it will decrypt the first cipher text and simply output the underlying message. One thing I would like to note is that if the NISC scheme is assumed to be simulation sound then the PKE scheme will actually be in CC2 secure. So now let's see how can we generalize this into a PKEBC scheme. So first PKEBC schemes have an additional algorithm that is used to generate now the CRS for this NISC and then in key generation we no longer have to generate this CRS for the NISC so the public key will just consist of the public keys of the underlying CPA secure scheme. Now recall that the encryption algorithm will now get as input this vector of receiver public keys and so what the sender does or what this encryption algorithm does is that now the sender has to compute for each of these senders an encryption of the message that it wants to send. So it's basically the same as before but just that it does it for each of the senders. Then it uses this NISC scheme to prove that there is a message such that every cipher text that it generated is an encryption of this message M under the corresponding public key that was received as input to the scheme. Then the cipher text will correspond to this NISC proof to the vector of cipher text that were generated and also to the vector of public keys. Decryption will be similar except that now we also have to check which cipher text the receiver should decrypt. So what the receiver does is that it looks for the index such that his public key matches the one that is in this vector in the cipher text and of course if there is no such index it just does not output anything but if it finds it then it just tries to decrypt the cipher text and outputs the vector of public keys that were in the cipher text together with the message that it obtained from decrypting the cipher text. Okay one thing I wanted to notice from the from this scheme is that notice that of course this is not does not achieve any sort of anonymity first because this vector v goes in planning the in the cipher text and also because actually even the NISC statement has this vector there. I mean the vector of public keys is not part of the witness so it does not have to be hidden. Okay so let's have a look at how things look. We know that there are NISC schemes from standard assumptions and actually there are also simulations on NISCs from standard assumptions. So we take any simulations on NISC and also from any PKE scheme from which is in the CPA secure we get this first construction of a PKEBC scheme however it's still not anonymous so let's make the previous scheme actually anonymous. So the main idea will be to add a binding commitment to the vector of receiver's public keys and also to the message and then when instead of just encrypting the message we'll encrypt the vector of public keys the message and also the random coins that were used to compute the commitment. So now the building blocks are the same as before but also now a statistically binding commitment scheme and actually we also need the underlying PKE scheme to also be IKC-PA secure. So the public perimeter generation algorithm or setup algorithm now the only difference is that it also has to compute this CRS for the commitment scheme but everything else looks the same as before. Now our scheme what it does is it first one has to compute the commitment to the vector of public keys to which we are encrypting the message okay and also of the message under some sequence of random coins row and then for each receiver we'll have to generate essentially instead of just being encryption of a message we encrypt not only the message but also the sequence of random coins and this vector v and then the NISC statement is slightly different because we have to show that there is a message but now also there is a vector of public keys and the sequence and these are now in the witness such that essentially they explain the commitment and also each of the encryptions okay and now of course the commitment is also part of the final ciphertext. For the encrypting the the encryption is basically the same as before but now we have to go over each of the ciphertext and check which one was meant for the for this receiver so we will try to decrypt each ciphertext until we finally find one that first encrypts correctly and second such that the public key of the receiver is encrypting matches in the same index as the as in this vector and such that it can you can recompute the commitment this gives you like correctness basically okay and if there is none of course you just don't don't output anything and otherwise you will output this vector v and the message okay so let's see how things look now now we also have this additional statistically binding commitment scheme which exists from standard assumptions and we will also use a pke scheme which is not only in cpi but also ikacpa secure and this also exists from standard assumptions and with these three building blocks we get we get the first scheme which satisfies all the security notions of pkvc schemes plus these ikac to security okay so with this let's just now look at the syntax and security notions for mdrs pke schemes so first the syntax the syntax is somewhat similar to before to the pkvc schemes things that now senders also have key pairs then a sender to send a message also has to use his own or her own secret key in order to generate his suffer text and decryption now will output not only this vector of receiver public is in the message but also the sender's public key so again i want you to make the same note as before which is for decrypting you really only need to know the sender's public key and you don't need to know who the sorry the receiver's secret key not the sender's public key and you do not need to know who the sender is or who the other receivers are and this is actually output by the decryption so the security notions that mdrs pke schemes should satisfy these four properties plus anonymity okay so i'll just go over the the security notions so off the record guarantees the following so suppose that a2 just sends some message m to this vector of receiver so before b5 b2 b2 b5 because he's dishonest might want to try and tell a3 that you know a2 said said something so just wants to convince a3 now that uh who is not a designated receiver that a2 said something and off the record guarantee captures that well maybe actually a2 never said anything maybe b5 is actually just making it all up so then what happens is that of course if a3 cannot knows that he cannot distinguish the cipher texts that would be honestly generated by a2 or the cipher texts that would be generated by b5 it will not be convinced okay so then we also have authenticity this is essentially the same as for mdvs schemes and it just says that the dishonest parties cannot come up with cipher texts that an honest receiver will successfully decrypt where the public key that is output by the decryption is the public key of some honest sender and dishonest sender had never sent a cipher text which is basically the encryption of the same message to uh some vector of parties okay so there is also consistency it's similar to before the only thing is that now we also have to consider the sender so if b1 outputs some vector of uh actually a triple where in this vector there is for example before uh public key with some sender's public key spkx then when before decrypts she should obtain exactly the same because before public key was output also by b1's decryption then we also have confidentiality and this really looks like before so it's just that dishonest parties will not learn anything about underlying message other than the length of the message and finally we also have anonymity and for anonymity the guarantee is slightly different although similarly to before again so the thing is that now the dishonest parties will not only not learn who the receivers are but also not learn who the sender was so in this case the dishonest receivers will not learn that maybe the sender was a2 and the receivers were b1 and before it could be any possible combination of an honest sender and two honest receivers okay so finally let's just have a very brief look at how one could or the main idea for constructing an mdrs pke scheme and basically the main idea is really just to use an mdvs scheme with does not have to be anonymous or does not have to satisfy privacy of identities and an iccc to secure pkebc scheme and basically we'll use the mdvs scheme to sign messages with respect to some factor of or to some set of receivers and then we'll use the pkebc scheme to encrypt all the key information plus the message and the signature and yeah and basically this is the main idea of the construction so finally let's have a look at how things look so we had this from before and now if we take any mdvs scheme and also any anonymous pkebc scheme using this construction we will just get the mdrs pke scheme which satisfies all the basic mdrs pke scheme notions plus anonymity and finally again as i said i think in the first slide before there were no constructions of these mdvs schemes with anonymity from standard assumptions there was one construction based on verifiable functional encryption and essentially since any mdrs pke scheme is essentially an mdvs scheme but just gives even more guarantees basically actually give the first mdvs scheme with anonymity okay so thank you for your attention and please let me know if you have any questions is there any question no question here yes can you please use the microphone hello great um sorry i just wanted to ask um what are the real-world situations where specifically i think in the mdvs scheme that you described the receivers do know who are the other receivers when they are decrypting and i was wondering what would be the situations where they would like receivers would need to know who are the other receivers of a message so the question is the use case for the first scheme so when receivers would not know okay so actually the use case for the first scheme was that essentially the question is how can you transmit the public keys for example even if you have an mdvs scheme that satisfies privacy how can you actually transmit the information such that receiver will know sufficient information to be able to verify signatures and the thing is that if i mean either you assume that the uh either you assume that the receiver just knows who the what the context would be somehow or if you do not make that assumption which i think is natural uh then you'd have basically to guess because you just don't know who the other who the sender and who the other receivers were so you're just left with a guessing so this is just a way to uh can be used for example to transmit the keys okay any other question so actually i have one so yeah if i understood well uh if i see a message circulating and i don't know if this message is intended to me so i should try to decrypt right and i should go through all the possible decryption to figure out that the message was not for me right uh yes yes yes you're right is there any analysis of the complexity of the this algorithm i mean i did not analyze it but it's at the very least linear any other question okay so thank you very much thank you thank you