 Hello everyone, my name is Rebecca Schwerth and together with my colleague Roland Kröll I will give you some insights into our paper, a new security notion for PkC in the standard model, weaker, simpler and still realising secure channels. The paper is joint work with Vasili Beskarovanov, Jörn Müller-Quade and Astrid Ottenhus. Firstly, I will try to give you an idea of our topic by explaining the choice of our title. An important goal of cryptographic tools is to facilitate secure channels between communicating parties. In our particular setting we want to build them from authenticated channels and some form of encryption. This was previously achieved in different works by use of classic public key or tech-based encryption. All the security notions employed for this, however, are known to be unnecessarily strong for the specific purpose. In this work we develop a new game-based security notion which is weaker than the previous ones and makes for simpler constructions, but at the same time is still strong enough to realise secure channels from authenticated channels. To show that this is not merely a theoretic interest, we provide a concrete construction which we prove in the standard model to fulfil our new security notion. This construction is more efficient than previous ones which had to fulfil stronger security notions to realise secure channels. I will now give you an overview of what to expect in this talk before diving in. We firstly develop a new type of encryption scheme, sender binding encryption, which unifies prior approaches to construct secure message transfer from authenticated channels. For this type of encryption we develop the corresponding game-based security notion of IND-SBCPA. We proceed to show how SBCPA secure sender binding encryption can be generically obtained by various transformations from other types of encryption scheme. For the transformation from dual receiver encryption we give concrete constructions which are more efficient than previously known ones. We then go on to prove that SBCPA security can be used to use realised secure message transfer from authenticated channels. In the last part we look at how the new SBCPA security notion fits into the current landscape of other game-based notions. Let's get started with the first part. As we all know a classic PKE scheme consists of three algorithms, key generation, encryption and decryption, which we require a correctness property from, namely that by decrypting an encrypted message we get the same message back. A tech-based encryption scheme works almost the same. Just that encryption and decryption additionally take attack T. The correctness property requires the text to be the same for encryption and decryption. From tech-based encryption it is not far to what a new notion of sender binding encryption entails. The texts are party IDs now. This is a notational difference only so far, but means there are now correspondences between keys and IDs. These IDs are thought of as some uniquely identifying information used within the specific system like names, emails etc. Sender binding encryption is meant to be used with the ID of the sending or encrypting party. This definition alone does not yield any obvious benefit so far, as IDs are seen as public knowledge, so malicious parties can insert any ID they want. But the benefits unfold in conjunction with authenticated channels. Checking the authenticated channel sender against the sender indicated in the ciphertext gives protection against replay attacks. To make sure neither message content nor sender ID of a ciphertext can be maliciously modified, we need a meaningful security notion for sender binding encryption. We call this notion in sender binding CPA. It has the same setup as common game-based encryption security notions. Firstly, the challenger determines information about the party or parties in question and hence the public part to the adversary. For our setup, this entails the keys and identities of a sending and a receiving party. After a first oracle phase, the adversary picks two messages and hands them to the challenger. The challenger draws one of them uniformly at random and encrypts it as the challenged ciphertext. Lastly, after the second oracle phase, the adversary tries to determine the challenge bit and wins if it is correct. Now the interesting part about the security definition is what exactly the two oracle phases look like. Both oracle phases are identical. As always, the adversary asks for some ciphertext C to be decrypted. In our case, not only this receivers public key but also the sender ID as specified together with the ciphertext. The oracle either decrypts to the true message or hands back bottom if decryption is not allowed. What we want is for the adversary to have no access to any communication between SNR but any other communication should be accessible, as would be the case if every other party was corrupted. The adversary already has free access to communication sent from SNR to any other party, as the adversary can just choose the other party's keys himself and only needs public information from SNR to encrypt messages. Hence the oracle only needs to give access to messages from another party to SNR. This means for the decryption request that the receiver needs to be SNR, while the sender needs to be someone else. Only in these cases does the oracle decrypt correctly. With these oracle phases, our int SPCPA security notion is fully specified. There are several ways to generically transform other forms of encryption into secure sender binding encryption. Let us briefly look at the construction from classic public key encryption and then consider the transformation from dual receiver encryption in some more detail. For the transformation from identity-based encryption, please have a look at our paper. To construct sender binding encryption from a classic public key scheme, we simply concatenate the sender ID to the message. This gives an int SPCPA secure sender binding encryption scheme as long as the underlying PKE is int RCCA secure. For those of you who are not familiar with this notion, RCCA security lies strictly between CCA1 and CCA2 security. So we get a complete decryption oracle in the first oracle phase and a partial oracle in the second oracle phase. The second oracle phase allows decryptions for all ciphertext, which do not contain one of the challenge messages M0 and M1. For this SPE transformation, where the sender ID is concatenated to the message, this means in particular that the oracle decrypts anything which has a sender ID different from S, even if the message before the sender ID might be one of the challenge messages. The construction is not very novel, but was previously used by Kanati at RLE to use serialized secure message transfer from authenticated channels and classic public key encryption. Together with its relation to tech-based encryption, this shows that our notion of int SPCPA secure sender binding encryption is well tailored to our research question and unifies all prior approaches to gaining secure message transfer via authenticated channels. For the transformation from dual receiver encryption, let us briefly recap how DRE works and what DRE soundness entails. The intuition is that ciphertext should be decryptable by exactly two specified parties instead of just one. So DRE consists of the same three algorithms as most encryption schemes, key generation, encryption and decryption. The interfaces are slightly different, as both encryption and decryption get two public keys as input. In addition to the common correctness property, we require a DRE scheme to be sound. This means an adversary cannot create a ciphertext which decrypts to two different messages for the two receivers. Not even if the adversary gets both public and secret keys of the parties involved. For our SBE construction, we additionally require the DRE scheme to permit a Boolean key checking function, which indicates whether a secret and public key belong together or not. Think, for instance, about checking for an Elgamar key pair, whether the public key is the group generator exponentiated with the secret key. Now, let's get to the actual transformation. Taking a DRE scheme, we require both the receiving and the sending parties to have keys. Instead of encrypting the message for two different receivers, the sender encrypts for the receiver in themselves. Hence the construction sketch looks like this. Encrypting for the sending party might seem weird at first, but actually acts as a plaintext awareness property. This means parties cannot send messages without knowing the content of the message, which prevents replay attacks. To get this property, however, we need to make sure parties actually know the secret key corresponding to the public credentials. We ensure this by using a key registration with knowledge functionality FKRK. A party registers their key by simply sending their public and secret key to the ideal functionality. The functionality checks if the key pair is well formed via the checking function FID. Now any party can query the registered public key. Hence we extend our construction by interactions with FKRK. After the key generation, keys are registered and for encryption and decryption, the necessary public keys are queried from FKRK. Using FKRK and this transformation, we can turn an int-CBA secure and sound double receiver scheme into an int-SBCBA secure sender binding encryption. We'll have a quick look at how the proof of this works. As a sum, we have a successful adversary breaking the security of the SBE scheme. We will use this to construct an adversary against the underlying DRE scheme. Firstly, the DRE challenger hands over two public keys. The DRE adversary denotes them as the public keys of two parties SNR and inserts keys into FKRK. Note that the DRE adversary simulates FKRK for the SBE adversary. So it can just insert those keys without providing corresponding secret keys. Apart from this insertion, the DRE adversary honestly simulates FKRK throughout this proof. So the SBE adversary can register and request keys at any point. Don't be irritated by the DRE adversary handing over the party IDs instead of public keys. We formally use those as the party's public keys for the SBE scheme, but it is just the technicality. Now the rest of the game is just handing through everything that the SBE adversary and the DRE challenger send, apart from the oracle phases. This is where the actual magic happens, so we'll look at it in some detail. The first and second oracle phases are exactly the same. When the SBE adversary asks for decryption of some ciphertext C sent from S' to R' the DRE adversary firstly checks if the SBE oracle would decrypt this, otherwise they hand back bottom straight away. If the SBE oracle would decrypt, then the receiver R' must be one of our known party's SNR and the sender S' is not allowed to be one of those. But this means the decryption only needs to succeed if the SBE adversary registers that keys for S' with FKRK at some point, and in particular handed a valid secret key of S' to the DRE adversary. The DRE adversary uses this secret key and the public key of R' to decrypt the oracle query. The soundness property of the DRE scheme guarantees that this decryption yields the same output as the decryption with R''s secret key would. Apart from a negligible difference, the DRE adversary now has the same success probability as the assumed SBE adversary has, which concludes our proof. I will now hand over to my colleague Roland Greul to explain our efficient construction of an DRE scheme. Thank you Rebecca. Hello everyone, I am Roland Greul and I want to show you an efficient construction of an NCPA secure dual receiver encryption scheme. We built our scheme on three assumptions. The first assumption is that random irreducible binary Goppa codes are indistinguishable from random linear codes. The second assumption is that random linear codes are hard to decode. These assumptions are the bases for the McElise cryptosystem and are also known as McElise assumptions. The third assumption is that the learning parity with noise distinguishability problem is hard. The main idea of our construction is to encode the message using a publicly known Goppa code and then mask it using randomness that is encrypted for both the sender and the receiver. This construction can be seen as an augmentation of a construction by Kils et al, which they published in their work Simple Shows and CypherTech Security from Low Noise LPN. We augment this construction to the dual receiver setting by encrypting the randomness for both sender and receiver. The Goppa codes and the McElise encryption scheme is an important building block of our construction. I want to start with an overview about linear codes, Goppa codes and McElise. A linear code can be seen as a matrix that is multiplicated onto a message vector to compute a code vector. While linear codes are hard to decode in general, there are classes of linear codes that yield an efficient decoding algorithm. One of these classes are irreducible binary Goppa codes. If you know the generating polynomial or know a generator in a specific form, the systematic form, there is an efficient decoding algorithm. It is a bit more complicated than that, but for the sake of priority I won't get into more detail about decoding Goppa codes. But despite there being an efficient decoding algorithm, and this is an important assumption for the McElise cryptosystem, a random Goppa code is hard to distinguish from a random linear code if the attacker does not know the systematic generator. On a high level McElise works by using a systematic generator as the private key and scrambling this generator to get a random generator which does not yield an efficient decoding algorithm. Here we see the public and private keys of the McElise cryptosystem. The matrix G prime is a generator for a Goppa code yielding an efficient decoding algorithm. And the non-singular matrix S and the permutation matrix P are used to scramble the generator so that a generator G can be computed that can be used to encode messages but not to efficiently decode code words. To encrypt the message we sample a random error vector E such that the code word C can still be decoded. So the error vector E can't introduce too many errors. To decrypt the cipher text C we first multiply it by the inverse of the permutation matrix P. Because the permutation does not change the hamming rate of a vector the error vector E times P inverse still introduces the same amount of errors as the original error vector E. So we can still decode this code word to get m times S. And now we can multiply the inverse of the non-singular matrix S to get the plain text. Now that we have seen how McElise works I can show you how our construction works. First the preliminaries that are needed for our construction. We need a family of irreducible binary Goppa codes that can correct up to T errors. We then need a Bernoulli distribution to sample error vectors that introduce up to T errors to our code words. Finally we need a public Goppa code with a public error correcting decoding algorithm. To generate a key pair we generate a McElise key pair and an additional random matrix C. This is later used together with an error vector to get the masking vector for the cipher text code words. To encrypt the message we generate randomness and encrypt it using the McElise keys for both sender and receiver. We then encode the message using the public Goppa code and add an error vector to it and then mask this using the randomness and the matrix C of the public key. Now for the decryption. We use McElise decryption to get the shared randomness S. We verify the consistency by encoding the decrypted S using the public McElise matrix Gs of the sender. This should have difference ES and as such have a hamming distance less than T to CS. If this verification step succeeds we can use the shared randomness S to unmask the S times C part of the cipher text and use the public decoding algorithm to get the plain text. Now we get to the comparisons with similar schemes. In this table we see the public key and cipher text sizes of our construction in comparison with similar construction by kilts et al and u et al. Because these sizes do not mean that much without inserting realistic numbers we research recommendations for parameters for the underlying hardness assumptions. Here we see realistic public key sizes for the three different constructions that were mentioned before. For kilts et al we have a public key size of 77 megabyte and this estimation is based on the paper is public key encryption based on LPN practical. For u et al we have a public key size of 2.5 megabyte which is based on the estimation from unsolving LPN using BKW and variants. For our work we have an estimated public key size of 505 kilobyte and we use the estimations of the paper in tacking and defending the Mekkelis cryptosystem by Bernstein et al. Now we get the NCPA security of our construction. These are the assumptions we need for the security of our construction. As mentioned earlier we use the assumption that randomly reducible binary gopal codes are indistinguishable from random linear codes and that random linear codes are hard to decode. Furthermore we rely on the assumption that learning parity with noise pairs are hard to distinguish from a uniformly random distribution. Now for an overview of our game hopping proof for the NCPA security of our construction. For game 1 we examine the NCPA game. The ciphertext is the challenge ciphertext from the NCPA experiment. The indistinguishability assumption for gopal codes allows us to exchange the matrices gs and gr with uniform random matrices us and ur without an attacker being able to distinguish between these cases. So game 2 and game 3 are indistinguishable from game 1. Because s times u plus e is an instance of the learning parity with noise distribution problem we can exchange s times u plus e with the uniform random vector u to get game 4. Now we have a codeword of the message x odd to a uniformly random vector. This acts as a one time pad and so our construction is int cpa secure. To show di e soundness we assume that the verification step fails for one party but succeeds for the other party. The case where both verification steps succeed but the decryption results in different plain text messages is analogous. The ciphertext consists of the three parts cr, cs and c prime. The public keys for both sender and receiver consist of the public meccalese matrix gr respectively gs and the matrices cr and cs. These are the ciphertexts of the supposedly shared randomness s and s prime. The non-valid decryption for the receiver means that the verification step has failed. This means that the hamming distance between s prime gs and cs has to be greater than or equal to t. Because cs is equal to sgs x or es we get that the hamming rate of s prime gs x or es has to be greater than or equal to t. Now because es has a hamming rate which is less than t it follows that sgs and s prime gs have a non-zero hamming distance and so s and s prime have to be non-equal. However because the decryption for the receiver does not fail we see that the hamming rate for sgr x or s prime gr x or er has to be less than t. Because s and s prime are not equal sgr and s prime gr are code words for different plain text and as such have a hamming distance greater than 2t plus 1. But because er is a meccalese error vector it has a hamming rate less than t. So this contradicts with the inequality that the hamming rate of sgr x or s prime gr x or er is less than t. Similar considerations will yield that the case when both the decryption for the sender and the receiver succeed but compute different plain text messages is impossible. Now my colleague Rebecca Schwert will continue the talk. Thank you Roland. Time to look at the next part of our contribution. How can we actually use crealize secure message transfer from int sbcp a security? We'll first clarify the involved functionalities for everyone who is not intimately familiar with them. Both falth and fmsmt are concerned with authenticated message transmission i.e. a sender hence the functionality a message m and an intended receiver r and the functionality hence the message and the idea of the sender to the receiving party. With falth both the identities of the sender and receiver as well as the message content is handed to the adversary. The adversary can block messages by not giving their okay for transmission but cannot change its content or the parties involved. In contrast fmsmt does not leak the message content hence it is very natural to think of secure message transfer as adding encryption to authenticated channels. A further difference for our paper is that we use a one-time functionality for falth but a multi receiver multi message multi sender version of fsmt. Note that single message secure message transfer is easily realized via int cpa secure encryption but not very practical as it requires a new setup for every message. Let's see what the protocol looks like that we use to realize secure message transfer from authenticated channels and sender binding encryption. When some party s wants to send a message m to another party r they essentially just encrypt this message via the int sbcpa secure sender binding encryption scheme and send the resulting ciphertext over an authenticated channel. The receiver decrypts the ciphertext and learns the message. Of course there are some details we need to take care of like key generation and distribution. We handle this on demand i.e. when a receiver s key is needed but not known yet the sending party asks them over falth to initiate. The receiver generates a new key pair if they do not have one already and broadcasts the public key to all other parties again via authenticated channel. We show you that this protocol realizes secure message transfer we need to define a simulator s which makes the ideal world indistinguishable from the protocol for an environment that. Our simulator the gray box basically simulates the whole protocol as honestly as possible. So for each honest party in the ideal world there is an in the head party which conducts the protocol while in the head corrupted parties directly hand through what the environment asks them to do in the protocol. Falth is played in the head as well. The extra part denoted by behavior defines how the simulator translates between in the head honest parties and corrupted parties interacting with the functionality. Let us clarify this with an example. Assume a corrupted party s sends a message to an honest party r. In this case the environment asks s to send a ciphertext c to r. This request is handed through to falth which asks that for permission. If permission is granted the ciphertext is handed to the in the head copy of r which owns all keys. Remember there are no keys in the ideal world. In the head r decrypts the ciphertext according to the protocol and outputs that is for send message m from party s. With this information the simulator can now feed fmsmt asking via s to send m to r. The simulator instantly grants the request for transmission as the environment did so as well and the message is delivered to party r. Now assume as a second example that an honest party s sends a message to another honest party r. In this case the environment gives s the message and receiver id who hands it to the ideal functionality in turn. The ideal functionality now asks the simulator for permission to transmit a message from s to r. To learn whether or not the environment grants permission for transmission of the message the simulator needs to generate the corresponding request from falth to the environment. And in this case it has no way of learning the content of the message. Hence it instead asks the in the head party s to send an old zero message to r. In the head s encrypts the zero message and asks falth to deliver to r which in turn prompts the request from falth to the environment. If permission is granted and in the head r receives the message the simulator allows fmsmt to transmit the real message. Note that this case, messages between honest parties is the only case where the simulator cannot simulate perfectly and the only difference in this case is showing the environment an encryption of zeros rather than an encryption of the real message. In essence the indistinguishability between those two ciphertexts is what the employed encryption scheme needs to provide. I now want to try and give you a rough idea of the proof. What was it we wanted to prove again? That if we use an ind sbcpa secure sbe scheme as the encryption within protocol pi this protocol realizes the secure message transfer which in turn means showing that the simulator we just had a look at indeed makes the protocol and ideal functionality indistinguishable for the environment set. We now conduct our proof by assuming we have an environment which does distinguish between the two and use it to construct an effective adversary against the underlying sbe scheme. As mentioned before the simulator s simulates everything perfectly apart from messages between honest parties. For this case the only difference is that the environment sees encrypted zeros instead of an encryption of the actual messages. We now define a chain of hybrids between those worlds. In hybrid HK for the first K messages between honest parties the environment sees encryptions of zero. For all later messages the encryptions of the real messages. If there is an environment Z which distinguishes the real and ideal world there has to exist at least one K such there is an environment ZK which distinguishes the two consecutive hybrids HK and HK-1. For this environment only the encryption of the K's message differs. This difference the message MK and zero is used as the two challenge messages for the sbe adversary we construct. The resulting challenge ciphertext is shown to ZK. If ZK now determines it is in the real world the sbe adversary answers that the challenge ciphertext encrypts MK. Conversely if ZK answers with ideal world the sbe adversary hands back zero. This way we get an sbe adversary with non-negligible success probability which concludes our proof. As the last part of our contribution we want to talk about how our new security notion fits into the landscape of prior game-based security notions. We compared ourselves to classic PKE as well as TB inertions. Note that in both cases there is some slight interpretation necessary to make the settings comparable. Subject to the we think very intuitive interpretation we chose the only relationship to PKE notions is that in sbcpa security implies classic CPA security while there are no other implications. The connection to the be notions is a bit stronger as the only assumption there is that the respective text base is at least as large as the number of parties. The weakest prior TBE notions were ATAC and STAC week CCA. In our paper we weakened those notions further to arrive at GTAC week CCA which we then derived as BCPA from. I will briefly explain the differences between the three TBE notions. Each of them has the usual setup. The challenger generates a key pair hence the public key to the adversary their oracle faces, the adversary chooses the challenge messages and so on. The differences now lie in when and by whom the challenge tag is chosen and what the oracle provides. For adaptive tech week CCA the tech is chosen together with the challenge messages by the adversary. The second oracle face does not provide any descriptions for the challenge tag. For selective tech week CCA the tech is chosen by the adversary as well but at the start of the protocol before they learn the public key. Now both oracle faces exclude the challenge tag. For given tech week CCA the tech is randomly chosen by the challenger and handed to the adversary together with the public key. Both oracles again exclude the challenge tag. From this it should be easy to see the implications between the three TBE notions as the adversary gets less power moving up and less oracle access. Identifying the tech space with send IDs, SPCPA is very similar to GTEC week CCA. There is a second key pair i.e. the keys of the challenge tag ID and a second tag i.e. the receiver ID drawn at the start and the oracles are further restricted in that they now do not allow description for either of the known tags. Now although these implications all seem straightforward and a bit boring there is an actual benefit here. ATEC week CCA was already previously used to construct SMT via authenticated channels. S-Tech week CCA was as well but only with a detour via CCA2 security. With our work it is now obvious that S-Tech week CCA itself is already enough to get SMT without the need for further encryption constructions. To conclude let's recap what we have seen in this talk. Finding an encryption scheme to construct secure message transfer from authenticated channels is a common problem. It was previously solved by taking an RCCA secure PKE or a week CCA secure TBE scheme but both of these notions are unnecessarily strong. We developed a new type of encryption scheme which unifies prior approaches and a corresponding security notion which is weaker than prior notions in an intuitive sense. This notion can be generically obtained by various transformations. Together with our new DOE construction this generic transformations yield more efficiency than prior SMT solutions. We then proceeded to prove SBCPA security to be strong enough to UC realize SMT from authenticated channels and provided a classification of SBCPA security within the current landscape of other game-based notions. Thank you for listening to our talk and I hope you have fun with our paper.