 Hello and welcome to my talk about the paper on pairing free blind signature schemes in the algebraic group model. This is joint work with Julian Loss and Jiayu Ksu. First I would like to explain what is a three move blind signature scheme. In the three move blind signature scheme we have two parties a signer and a user and the signer has a secret key whereas the user has a corresponding public key and a message M that he would like to have signed. The signer first computes a commitment R and sends it to the user. Then the user gets to choose a challenge C and sends it back to the signer. The signer then generates a response S and this allows the user to compute a signature that is valid for the message M under the public key of the signer. We want two notions of security. The first one is called blindness. In the blindness setting the signer is played by an adversary. The adversary first chooses two messages M0 and M1 and he sends them over to the challenger who will play the user. He then gets to interact with the challenger two times and in one of the sessions the challenger uses M0 and in the other he uses M1. If both of these sessions which may be interleaved yield valid signatures in the end the signer gets to see the two signatures and has to decide which signature comes from which signing session. If he guesses correctly he wins the game. The other property that we want is called one more unforgeability. One more unforgeability means the user is played by the adversary and he gets to see a public key. Then he gets to interact with the signer who is played by the challenger and he can either do this sequentially which means he has to close the signing session before opening the next one or he can do it concurrently which means he is allowed to interleave the signing sessions. After L such interactions he is supposed to output a one more forgery. That means he is supposed to output L plus one message signature pairs that are valid with respect to the public key of the signer. The original motivation for why we want blind signatures was electronic cash. So if you want to go to the bank and withdraw some money so that you can buy something your bank could issue a blind signature to you that you can use like you could use cash. So you can go and spend your blind signature and buy a bicycle for example. And the reason why we want to use a blind signature is if your bank is malicious and wants to spy on people and the bank interacts with multiple users and issues multiple such signatures and then at some point someone goes and deposits a signature the bank cannot tell whether this person bought a bicycle or this person bought a bicycle. Also due to the one more forgery ability if one of the users is malicious and he interacts with the bank a bunch of times and gets some money he cannot generate more distinct signatures than he got from the bank. So he cannot do this. So if he interacted once he cannot generate a blue signature and a green signature. However of course there is still the issue that he could copy the same signature several times so we still need some detection mechanism for that sort of attack. Another property of security that we may want is partial blindness. So this would replace the full blindness. In the partial blindness setting we want to include some additional information in the signatures so that they are only blind with respect to this information. So this could be any info that the user and the signer can agree on which is something like the date or time or an expiration date or it could also be in the setting of electronic cash the value of the signature. So you could have signatures that are worth 50 euros 100 euros 200 euros. In this work we consider two blind signature schemes. The first one are blind snore signatures. Blind snore signatures are used currently in blockchain protocols that use snore signatures as their underlying scheme. The blind snore signatures are vulnerable to something called the ROS attack which you can apply when there are many open signing sessions at the same time and then you can linearly combine hash queries together to generate a one more forgery. We also know that in the standard group model but with only the random orco model you cannot provide us proof of security for blind snore signatures using the standard forking technique. But in the AGM plus random orco model under the ROS assumption and one more D-LOG we know that blind snore signatures can be proven secure but we also know that this ROS assumption does not hold for polynomially many open sessions because there has been recently discovered a poly-time attack on ROS. On the other hand there's ARBE scheme which is immune to this ROS attack but the original proof of ARBE scheme was flawed which was discovered by Okubo and ARBE who provided a proof in the GGM instead. In this work we reconsider ARBE scheme and we show that it is secure in the AGM plus ROM under D-LOG. We also show that in the sequential setting snore scheme is secure in the AGM plus ROM under the one more D-LOG assumption and we provide a proof that you need as many one more D-LOG queries as close signing sessions so in this sense our reduction is optimal. Let's look at our main technical tool that we need for our reductions. We work in the algebraic group model and in the algebraic group model whenever an adversary gets a group element as an input and he outputs a group element he needs to explain how he computed the output group element from the input group elements. So more formally this means the adversary needs to output this representation vector which is a vector of exponents that explains how you can get to the output element using the input elements. Let's look at the first signature scheme. This is blind snore signatures. In the blind snore signature scheme we have a secret key that is an exponent X and the public key is just a group generator raised to that exponent X. To generate a signature first the signer chooses an exponent R and he sends over G to the R to the user. The user then blinds this value and hashes it along with a message to compute a challenge that is also a blinded hash value. He then sends the challenge back to the signer and the signer computes this response. From the response the user can unblind it and generate the actual signature. Our reduction which uses the one more delock assumption works as follows. So first we need to embed our delock challenges somewhere. The reduction therefore exchanges the public key for one of these one more delock challenges and embeds all the other delock challenges in these random values R in these commitments. Now the reduction can no longer sign. So the reduction needs to sign using this delock oracle and now we have a way to simulate the signing protocol. We now need to extract a discrete logarithm. So for this we use what is happening here. So we use these hash queries and there's a group element contained in the hash queries. So because we're in the AGM we know that our adversary needs to explain how he computed them. So he needs to provide this representation. And now we hope that the representation is different from what is in the end presented to us as part of a signature. So let's look at when can the adversary make these hash queries. Because we're in the sequential setting we can either have hash queries that are made like this. So there's two hash queries that are made within the same signing session or alternatively the adversary makes a hash query outside of one of all the signing sessions. So in between when there's no open signing session at the moment. In the first case causing the representation to be the same as the values of the signature would mean that the adversary has solved a one was problem. But we know that the one was problem is statistically hard. On the other hand if the adversary manages to provoke this bad case in the situation where the hash query was made outside of all the signing sessions the adversary must have guessed the hash value. This only happens with a probability of about one over the order of the group. Therefore we know that our reduction will very likely succeed in extracting the discrete logarithms. First of the public key and then through the information it has learned during signing. It can also compute the discrete logarithms of all the commitments. We also show that our reduction is optimal in the sense that it uses as many one more deal queries as it has to but not more. So assume we had a reduction that uses one less one more deal query than it closed the signing sessions. And assume also that this reduction is algebraic. Then we can employ a meta reduction that will simulate a one more forgery adversary by just looking at the algebraic representations that the reduction outputs and from them trying to create a one more forgery. So it can solve a linear equation system and then the reduction will actually solve one more discrete log. This must mean that actually the one more discrete log problem was easy in the group. Therefore our reduction is optimal with respect to the amount of one more deal queries made. So let's consider what our reduction can do to simulate signatures. Because we're in the D-LOG setting we only need to embed one challenge. And the reduction can do this in some different ways. So first it could embed the D-LOG challenge in the public key. Then it needs to know the discrete logarithms of the other two group elements. So know the witness to the pink branch of the OR proof. It can do this by programming the random OR code accordingly so that it knows the discrete logarithms. The other option is it could embed the discrete logarithm in one of the pink parts. So here in this H or in the set and then just generate signatures like the normal signer would. Because it doesn't need to know the discrete logarithms of these parts then. It only needs to know the secret key. So let's look at what happens with the linking components. As we have seen before there is a hidden link between a signature and a signing session. But when there's more signatures than there are signing sessions there's two cases that can occur. Either there must be a signature where the hidden link doesn't match any of the signing sessions. Or there's two special signatures that belong to the same signing session. We now want to look at the hash queries that are made for these special signatures. So here is a hash query that was made for a special signature. We know that for each of the group elements that is contained in this hash query the adversary has to submit a representation. So from this representation we can compute what we call preliminary components. And these correspond to components of the actual signature. And we want them to not be the same as the corresponding component in the actual signature. So for the green part we have an omega prime. And for the pink part we actually get three preliminary potential values. We also know that omega plus delta needs to be the hash value. So we hope that these preliminary components will not be the same as the components in the signature. And now we want to look into how can the adversary maybe provoke this so that this bad case happens where they are actually the same. The first way the adversary could provoke this is by just guessing the hash value. This is the same as in the Schnorr case but it only has probability one over all of the group. Then we also show that if the adversary manages to do this while still behaving like we expect him to he must have solved some discrete log problem. So we provide a reduction that solves discrete log if the adversary generates these matching preliminary components to the actual components. And then the last cases of course for honestly created signatures these preliminary components are the same as the signature components. And so this means first of all this one special case where the linking components are mismatched cannot occur. And the other case is we now have two signatures that belong to the same signing session. But in order to match the preliminary components here the adversary would need to solve a one loss problem. And we have seen before the one loss problem is statistically hard. So this means that for our reduction the probability that the adversary generates the bad case for the reduction is very low. Thus our reduction can solve the discrete logarithm problem. To recap we showed that our scheme is concurrently secure in the AGM plus ROM under the plain D-LOG assumption. We also showed that Schnorr scheme is sequentially secure in the AGM plus ROM under the one more D-LOG assumption and we saw that we need as many one more D-LOG queries as our reduction makes. So our reduction is optimal in this sense. It leaves the open questions of what happens to our scheme in the random oracle model only. So is there maybe a way to provide a forking proof without having to employ the AGM or the GGM? Also it would be interesting to look into what happens to Schnorr scheme when we have a setting with low concurrency. So not many open signing sessions at the same time but a few. So maybe a constant amount. This concludes my talk. I thank you for your attention. Here are my references. And I hope to see you all at the conference.