 Thank you. This is Daiki and Amalix and we talk about campus crypto protocols and global bonds for them. This is a strong work with Seria Kastner, Stefan Balzer, Ryuchi Hayashi, Takaki Mizuki and Hideo Akasol. It first puts us into a scenario where we may arise in real life. Let's assume you want to do a movie evening and you would like to watch some movie acts. But that would be very embarrassing, except if my flatlay might like X also. So maybe you have experienced this situation. The most natural thing to do would be running cryptographic protocols for this. Everything is already there, so we can write a small app for our smartphone. Players just select their choices. We run this protocol and in the end it puts out which we will be to watch. So this is all nice and shiny and we can just use it, but there might be a problem. Here we might just not trust our smartphone, so it might just intercept our choices at the moment we put them in. So we have cars and physical assumptions for that. So the second motivation for this topic like cryptos or computers is also that they might be used in detective context. So I'm actually using them to teach cryptographic privacy directions to junior high school students. So they are kind of like 13 and 40 and they were able to understand the protocol I'm talking about right next. So don't feel pressured, but it will be simple. Okay, actually it's 5 and 6 years old and it's already a couple of years old from 2009. So we can compute an ant, which is like a private set in the section. We only want to find out whether we want to watch the same movie for one movie with playing cards. And we can do so by putting Alice putting like a hard card for example here to the left side. She says yes or no. On the other side it puts the club card on the remaining position. Same for Bob. We have a club at the heart encoding a zero at the remaining position as helping cards. Of course these are face down because otherwise we would already learn the results of the inputs of the both players. So this puts us into one of the following configurations and both players say yes. We have here hearts clubs, hearts clubs and clubs hearts is zero here and so on for the other positions. So a short observation you can make is that under the side of Alice's heart there's always like the correct result. Like if both players say yes then the output should be hearts clubs encoding a one. And here it's zero, here it's zero and here it's also zero if one of the players is both saying no. So you can observe that this invariant kind of is preserved under exchanging both sides. So we can just split this into two, put them in envelopes, exchange them quite fast so that we don't know whether they have been exchanged and put them back. And now we can like open Alice's cards because now they do no longer encode a result because they have been inverted this probability one half by exchanging the two sides. But we still have that the result is under the side of the heart. So here or here. So this is a very simple protocol and our main question is can we do with less than six cards? So we need at least four cards for already like encoding the inputs but maybe we don't need the two helping cards here. And so we already know the answer three years ago in Asia Crypt we knew that there's a four card and a five card protocol but the remaining question is can we still be very practical? So these protocols I will show one of them in a minute are in a side story I'm practical. So it's not usable in practice and like in the tactics context or really in practice. And here we give like a partially no answer. So for some meaning of practical we can show that there's no five card or four card protocol so that this six card protocol we just saw is optimal. And the second part for arbitrary circuits we additionally need a copy because our inputs are kind of physically on the table. So if we want to input a bit into multiple gates we need to copy them. And there's copy protocols for this. And there the open question is already the question which paper addresses is how many cards are necessary there. So we want lower cards for both of these codes. So let me quickly describe a short way to describe card-based protocols in an enriched fashion so that it encodes not only the protocol description but also some information. So protocol state is just like a box where we write down all possible sequences of the cards which might be lying on the table at this particular moment in time and we annotate them with symbolic input probabilities like for example in this sequence hardstops hardstops both players put a one. So this card sequence is lying on the table when with the probability of symbolic probability of both players saying one. And if we do it like a shuffle which introduces the randomness we need for the security we can easily calculate the state which comes after that. So in our exchange of the two sides shuffle which is written like this there's a set of two permutations where we choose one our probability on half and the other as well. We can just write for example all states which have been here before again because identity doesn't change anything. We have to multiply them with one half because this permutation will be done with probability one half and the other permutation we just have to look where each sequence ends up after this permutation and add the one half of the original probability to the sequence. So after the shuffle we end up in a state like that. And we have like shuffling and turning in card-based protocols so if we turn to the first two cards as we did in the protocol before we just branched the tree and branched down all the sequences which are compatible with what we see in this step. So here's how it's clipped and here's how it's clipped and for security we have to ensure that the observation does not depend on the inputs of the players. So the probability of going right has to be a constant. It should not depend on these. So all these x1s and so on they sum to one and after summing up to one we get the probability of one half of going here and probability of one half of going here and we will normalize by multiplying with two after we see this observation. So security is an easy check at each turn operation we have this local check of looking whether the probability sum to a constant. And correctness is even easier, we just have to look at the each nodes and see whether the output of cards are compatible with the inputs of the player. So this enriched description from this you can easily see security or correctness of the protocol. Okay this is a four card protocol which I was advertising as not being very practical as much larger than the six card protocol as you can see. But here the main point is that this shuffle operation I'm not sure you can read it but it has a general probability distribution on the permutations so it does not use the uniform probability but the identity is done with probability one third and the other permutation was two thirds. So this is very hard to do in practice actually so I will talk about it in a minute on why this is hard to practice but the second habit is that you might run on circuits so there's always a small probability of going another round so this is only a Las Vegas type of result and not a finite round time so we don't have an a priori bound on the round time. Okay so we don't call this practical and now the restrictors have to certain shuffle operations which we can easily do in practice and here I will quickly motivate why so called uniform closed shuffles are nice so uniform as we want the uniform probability on this permutation set we do in the shuffle and closeness is that this permutation set is a subgroup so that if you take two permutations and do them one after another we actually end up in the permutation set again so these are nice because there's like a very simple passively secure implementation of that so first the statement we want a shuffle operation should perform a permutation from this permutation set at random and no player should know which permutation was done so we can do this by first Bob looking away and Alice just doing some random permutation from the set and then Alice looking away and doing this permutation and in the end it's kind of a secret sharing on the permutation side we end up with a random permutation which is also in the set because of closeness and it has uniform probability because both players have uniform permutations so these are nice but not only a passively secure but there's a e-print paper stating an actively secure permutation using only uniform cuts and helping cards and there you then to ensure that the other player kind of does not do any permutation on the set okay so this is like a quick speech of the proof idea of the lower bounds so we want to show that there's no finite one time close shuffle and protocol so if you want finite one time so no loops and if you want to assume that all shuffles are closed which shows that they are easy to do then the 6th protocol we just saw is often and we do that by induction and we classify a number of bed states the sub state is also like bed state and we show that we cannot kind of completely leave leaves a set of bed states in this protocol free so that if there's for example a loop where we kind of leave the set going to a final state which might opt for the result there's always like another vertex going into the bed states again so we kind of never leave it completely so I can't really go into the proof but kind of this is the classification of the five types of bed states we did and we describe the final states a bit more regularly and with that we were able to, and using a little bit of proof theory we were able to show impossibility okay my name is Daikimi Hara and X is for free protocols from my good commitment to X and some other general codes a code-based protocol is to make N-commitments we sometimes write N-commitments like this and please note that at least two N-codes in total are necessary for N-commitments then we are that these code protocols are as I thought that primitive in code-based computations and the state of the code protocols are shown in this table in the experiments using two N-codes while in the simulations using two N-codes although this is the last one and in this presentation we showed one one on the number of required codes for code-based protocols that is we proved that there is no code-based protocol with two N-codes and in addition there is no code-based protocol with there is no code-based protocol with two N-codes one-codes in the case of finite runtime so these with Xonus and Ishimas are optimal in terms of the number of required codes in the cases of finite and infinite respectively then we first outlined the opportunity group with two N-codes we assume for contradiction to the existence of code-based protocols with two N-codes let's consider the final state which we call Nif state like this if input is there there are N-black to red colors red pairs and if it is one there are N-red to black pairs although we omitted the detail a sample cannot be the last action because a sample usually increases the number of sequences in the state after the sample so we now assume the last action is time over the code but in this case all the time the codes must be the same color upon contradiction so we need two N-plus one codes to have a code-based protocol let me move on to the second possibility that is the possibility with two N-plus one codes for finite and finite also we assume for contradiction to the existence of finite code-based protocols N-black and N-plus one codes so because of finite and finite there must be the GPS leaf like this box and we assume the last action is time over the code and you move the first code and the red is revealed that is the first code both the first code is dense and the rest are output components and so by the way when we turn the first code there must be a possibility that a black is also revealed like this box both the first codes are black but in this case there are exactly N-1 blacks and N-plus one lengths so in this state we can't construct N-commitments so there must be there should be a derivative upon contradiction so we can conclude that two N-plus two codes are necessary for finite code-based protocols so let's just conclude our talk we'll give you a quick summary of what we did so we saw before the six codes are needed for finite runtime and with closed shuffles finite runtime is denoted by F and closed with C in the diagrams below and there's another result which I didn't talk about is that five codes are needed for N with uniform closed shuffles so without the finite runtime requirement but using uniform and closed shuffles and we just saw that two N-plus one codes are needed for copy general and for finite runtime two N-plus two codes are necessary so let us because it's kind of there's multiple possibilities of finite runtime or non-finite runtime uniformity or non-uniformity and closeness or non-closeness so we can put them in a nice little husset diagram where MTSA has no restrictions and we know that there's for example a four-card protocol so this is optimal and for finite runtime there was a five-card protocol and we knew that that was the optimal by AsiaCraft 2015 so this is kind of how it looked before our new work and this is how it looks after the color encodes the tightness of this bounce so greenness has a tight bounce so because copy was not really studied before we get a lot of new tight bounce here and the image was talking much well as before and we get new bounce here so there's still some colored, long green colored things that might be already solved but there's a nice other open problem maybe we can achieve actually five cards in the setting finite runtime enclosed but if the fifth card is not a hard or club which is used for the encoding but for example a different symbol like a spade symbol like a thumb color so for example this is a nice open problem okay so thank you for your attention do we have any questions if you're provided a Boolean circuit does your result tell you what the minimum required number of cards are? no not directly but from this low bounce in the reading box you can compute it so you have to you can't directly read it from our paper but you would have to do some calculations but I think these bounds make it easy to calculate that we actually did do it thank you any other questions or comments? answer there are only there are only there are only maybe three lower bounds in card based computation mines and protocol and the order is next door and the copy so we can't we can't so any Boolean circuit we can't already construct any Boolean results or study any lower bounds I was assuming that you build the blocks together with a Boolean block but of course it's a more efficient solution to do it not using this add and paste we have any other questions? we let you know so last time the speakers and the other speakers are the same name my thoughts are it's better to be brave