 Hello everyone, my name is Jesus Diaz and I'm going to present joint work with Ania Lehmann entitled Group Signatures with User Control and Sequential Linkability. So as probably many of you know, Group Signatures are a very well studied cryptographic primitive. I mean so which group of users can create a digital signature that does not reveal the identity of the signer and can be verified by anyone that has a group public key. There is however, a central party that is able to extract, given any group signature that is able to extract the identity of its signer. This operation is to be called open or in other cases with a similar thing that it's called another way like bringing. However, in all cases, this operation is by this invasive that this needs trust on the party that trust party that's that is able to execute it. So the question that we make, the challenge that we place ourselves is whether we are able to get rid of together of this central party. Of course, we know that there are schemes in which it's possible to distribute this trust this this trusted party but we can get rid of it at all completely. So, um, take this example as illustration. So say that we have a group of two users are users of users who are create signatures over some data and the signatures are stored in a data link. Now we want all these signatures to be animals, not to not reveal the identity of the signer, including any trusted party that was involved in the creation of the group or something like that. With the exception of the cases in which users are themselves interested on revealing the links, doing that, that so they created some signatures, for instance, the reducer may be interested in showing that he was the creator of signature one and in that case, any observer, not only any possible trusted party like the group is here, but also any other observer should be able to verify these these proofs. So the functionality that this group seems was variant. Provides is very similar to the usual one. So there's a setup function, which creates a group of the key and the group security. There's an interactive join easy protocol between the prospective member and the blue manager by means of which the new member receives membership secret key or potential. Then of course, sunny number five operations as usual. And instead of opening. We have a function in which is typically parameterized by the group secret key. We replace it with a link operation that in this case is parameterized by the specific member that transit, but the secret key of the specific member that turns this operation, and even a set of messages and their corresponding signatures it creates a proof. So we that the signatures were created by the same group member and the verifying compression gas verifies that. And I emphasize that only the users can run link on their own signatures, of course. And I think it's very similar to commercial, commercial groups in other schemes. But the modeling is not so similar. Mainly because traditionally, in order to state the non-premability and traceability properties of your signature, we rely on the open function, which we do not have here. So usually, in a nutshell, the non-premability is stated by saying that no signatures should open to the identity of a member who did not create it. And all valid signatures that visibility property is cheated by saying that all signatures should open to a valid member of the group. Since we do not have open, we cannot phrase them like this. Instead, what we do is to leverage the name approach of dynamic anonymous decision and other similar groups in other schemes. And instead, what we do is to accompany every group signature with pseudonym or name, which is a terministically produced from a user chosen scope, which is chosen per signature. So this name is computed from the scope and the user security, of course, and it has the property that if the user picks the same scope, it always will produce the same name. So just by looking at the names of a set of signatures, if this set of signatures have the same name, then we know we will know that they came from the same user. Of course, they will have also the same scope. This gives us what we call implicit user control link ability. But we want more. We want also to be able to our users to create what we call explicit user control. So this means that even though two signatures have different names and different scopes, if they come from the same user, then we want this user to be able to create a proof that he or she created those signatures. This is the explicit link ability that we need. So now, non-framability and traceability, we have to phrase them in a manner that captures the same meaning or similar meaning that user commercial groups here just keeps but instead of using the open function, we use other alternatives that we have, the link function. And specifically, we state non-framability by saying that signatures by different users cannot be linked and traceability, we stated by saying that all signatures should be, must be associated via identified to a valid group member. Here identified is a helper function that given a signature and a user's secret key returns to our falls. So meaning that this signature comes from the user in control of that security. This has also been used in related work. And of course, since we've support both implicit and explicit link ability, we have to create variants of non-framability and traceability for those cases. But still the yeast of the properties are the same. So our specific instantiation is built from BBS plus signatures for the members of credentials and this BBS plus signatures, the thing is that they allow the efficiency knowledge profile of knowledge of that signature, which is what we use for creating those signatures. And then we also introduce a batching technique that allows us to create efficient link proofs, explicit link proofs. Okay, so far so good. The user control including groups here to skin that we present is efficient. We model it. But there may be cases in the real world in which this full privacy that we give to the users is not good. So in the UCL groups in the scheme the users have full control of the privacy meaning that they are the only ones who can decide to reveal that some signatures came from them. Since there is no opener, there is no other entity can do that. And this can be good and can be not good for real use cases. Specifically for some use cases that we were targeting, we were interested in proving statements. That's gave some certainty about the sequence, the order in which a sequence of signatures was created, meaning that we wanted the prover to be able to show that he is presenting a sequence of signatures in the same order in which they were created originally without omitting or inserting signatures or swapping the order. This is what we call sequence handling it. So take this example for illustration again. Think of an automated driving use case in which we have smart vehicles that are sending telemetry data continuously to a data lake. In this case, this blue car is sending speed measurements. So it sends for digital signatures, while he is driving through a highway with speed limit of 100 kilometers per hour. In this specific case, the driver respects the speed limit, number goes beyond 100. So if for whatever reason he needs to reveal that he was the originator of these signatures, he will probably have no problem in doing so because he kept the limit. But in this other case in which this red car at some point goes beyond the speed limit. And then it has an accident. If after the fact, probably the insurance company will ask him to reveal the link all the information that was sent to this data lake and only was designed. So the red car has probably good motivation to hide these these these messages and in plain UCL sequences he can just not exclude this from the set of signals that he links and verify will have no way of detecting that. And the driver would be interested in doing so because he overspeed it in that in that case. So we want to prevent that kind of the functionality that we support is very similar to the basic UCL case. And basically just the sign function is extended with some sequencing information this makes the dysfunction stateful rather than stateless as before. And the link in a very fine link operations now become sequencing link and verify sequential link. The sets of signatures that are passed are now ordered sets rather than an ordered and the proof carries some extra meaning. The order in which the signatures are created. With respect to the modeling and non primarily the place of the properties are basically the same. And for anonymity, although the notion is very similar. We have to account for more to the winds that the adversary can exploit by means of which the adversary can exploit the order in front of to get to achieve this deal means. So it's cumbersome but however the notion is, you know, there are more details in the paper you are interested in. What's interesting here is how to model the sequential property. What we do for honest and corrupt users. And what we want to capture here is a security that we get that no honest then corrupt user will be able to swap from it or insert signatures in and then create a valid like a valid sequence sequential group. So this definition is raised as a game with two phases. In the first to the choose phase, the adversary has to commit to a sequence of signatures, which can be honest or dishonest and my different users. And he also has to pick a target user, which up to this point is honest, then in the in the fourth phase the adversary receives the secret key of this target user. And he is challenged to create a sequence, a sequential proof that includes at least one honest missing one honest thing about these target user. And also any other signature that the other ones but as long as it was included in that previously committed set of signatures. So the challenge is that the adversary has to create a valid sequential proof with these conditions. And he will see if he does so. Now for the instantiation, in our case we rely on an app and on the balloting board, which of course can be seen as a kind of trusted entity. But I want to emphasize that we only trust it to verify all signatures before appending them to the balloting board. And specifically, this, this balloting board does not need and cannot open or link any signature. So, we can think of this as any kind of up and on the balloting board it's also easily implementable to a kind of decentralized blockchain or similar application or similar infrastructure. Then for the sequencing information in our case we use basically has seen approach. Every roughly every every signature contains some random value Xi the IF signature will contain X by value, which is obtained from a PRF function. And the sequencing information included in the signature, not this Xi the sequencing information contains a has of this Xi value and also has that combines the Xi value the X value of this IF signature and the one in the previous So in order to sequentially link to signatures, the user just has to reveal these two values. Now for evaluation, we did some measurements of our limitations. Sorry. Signatures and linkability groups are pretty efficient here than the line and in red that is so the overhead of adding the sequential functionality and the time of every major competition is also quite good. It's also worth noting that we made some tests for up to linking up to 100 signatures and it's still in the order of a few milliseconds. This implementation, this results are based have been obtained through this library that this open source, the libraries in C but has rappers for Python Java NodeS and it's also, it does not contain also this scheme contains much more and it's easily acceptable just in case someone wants to replicate. There is also a demo for, for this for our scheme. Just in case someone wants to play a bit with it. Let me show it. Okay, so this is the demo that we have prepared hopefully it will help convey the idea of our schemes. Anyway, please note that the user interface and user experience has not been tested so we do not be very good. So, you can choose the mode by clicking this toggle here. You can also start by adding members and then you see others and so on or you may just want to refill as a system to produce some data for you, so that you don't have to meet everything. To create a signature yes, be quite scope on message as the user you want to want to create it and click sign and you will see that the new Spencer appears to the right. With the data that you specified and some visualization of the producing. If you want to verify any signature that has already been created. And what the one of you just produced. Yes, click the information scope assets. Choose the signature. And, and it says but I want to emphasize that this runs under the hood. So, you can also add new sequential proofs from the sequential link proofs or verify existing ones. Let's say that we will go slightly to the reply part. So we have to add three sequester link proofs that have been created for us. First fruit. It's about a sequence that contains person to one missing it to two and then to three. So let's pick here for one and then drag signature one to three. With the patient in this part may not be easy at first. If we can verify this work. Because it's actually the order that was used to generate this. But then if we change the original order say for instance, signature one signature three and signature two. Since we are in the sequential mode. This proof does not very well. For that, for that order. Which is good. This is what it was. Okay, so now let's go to the to the basic mode to the non sequential mode. And again back to the verification of groups. We have the same sequence, which has been regenerated for us for the non sequential mode. And then we pick signature one signature to signature three. Also to one. The proof verifies correctly for this case, but if in. Now if we enter around order. Since we are in the non sequential mode in the basic mode. This should also. Again, very fast. So it works. That's it. So you can keep playing with it. Hopefully you understand. I don't know. Get a better idea of how this works. And that was the demo. Okay, so just to end the presentation. Some notes and part of the work. Okay. The scheme does not support groups of not link signatures, meaning that there is no way for a user to prove that he was not the creator of some signature, or that he was not the creator of. So he could, if you get it to enter one and see a two, but not created signature to he cannot create any proof. So in that fact, it would be useful, for instance, to build somehow something like that. And this can come in handy for your world application. Also, we modeled security against initially honest, but then corrupted users. It was, we would also be interested to study what security can we get against initially corrupt users, probably not max, but we may be able to get something. And of course, efficiency, efficiency wise, it would be very, very interesting to include some kind of box verification of independent signatures, not linked groups, but individual signatures. And that was all. Thank you for your attention. If you have any questions, I will be much more than happy to answer them. Thank you.