 So, in this presentation, we are going to talk about modular protocol design. So basically, what do we understand by that? Modular protocol design consists in designing a protocol for a complex task by composing protocols for single tasks, for simple tasks. And how do we do that in the UC model? So this is done by using hybrid protocols. A basic hybrid protocol basically is protocol where parties are allowed to call ideal functionalities for different tasks. And designing protocols this way has several advantages. So basically, a hybrid protocol allows for multiple instantiaciones because you can replace a call for any ideal functionality by any of the secure realizations of the ideal functionality. And also, a hybrid protocol allows for more structured proofs because it's better to have proofs for secure protocols for each of the ideal functionalities and the proof secure the composition of those ideal functionalities to realize the complex task than having one monolithic proof for a complex protocol. So let's look at it through a simple example. Let's consider that this is a complex functionality, functionality F12, which basically does the following. A party P sends an input A and the functionality evaluates the functions F1 and F2 on that input and finally sends the result to the party Q. So basically we want to provide now a modular protocol to realize this functionality. How do we do that? So we split the task, the first idea that comes to mind is to split the task into two, one functionality that computes evaluates function F1 and another one for function F2. So we design these two functionalities as follows. Party P sends the input to the functionality and later on party Q requests the output and the functionality evaluates the function on the input and sends Q the result. So how do we use these two functionalities to create a protocol in the hybrid model for functionality F12? So the first idea that comes to mind is very simple. It would be just in step one, the party receives the input A sends it to the functionality F1, step two sends it to the functionality F2. Step three, party Q receives from party P that the functionality has already received the input through a secure channel and in step four, party Q requests the evaluation of the function from functionality F1 and finally the party Q does the same with functionality F2 and it can output the results. So this is an idea very simple to compose to create a protocol modularly for functionality F12, but it doesn't work. And as we can see now, this protocol is not secure and when there are security holes, terrible things can happen. So the reason why it is not secure is simply the following. If the party P is adversarial, if it is corrupt, then it can send different inputs to functionality F1 and F2 and F1 and F2 have no way of checking whether P has sent different inputs to them and the party Q cannot do that either. So we need a mechanism to prevent the adversary from doing that, from sending different inputs to the functionalities. That is, we need a mechanism to ensure that different functionalities receive the same input. So in order to fix this security hole, the first idea that comes to mind is to use commitments, right? So in the real world, how do we use commitments to ensure that different protocols receive the same input? So let's consider that we have a protocol by one for functionality F1 and a protocol by two for functionality F2 that receive committed inputs. So the idea is simple. We compute, make P compute a commitment to the input. This commitment is sent from P to Q and then P and Q could input the commitment to the protocol both for functionality F1 and functionality F2. So what we would, thanks to the binding property of the commitment scheme, it is guaranteed that both protocols receive the same input. So what we would like to do is to mirror the same idea but in the ideal world using a hybrid protocol. So we would modify first of all the functionalities F1 and F2 we proposed before so that they accept committed inputs and then use a functionality FCOM to compute commitments in a hybrid model. So the protocol would be as follows similar as before. Parti P sends the input to FCOM and FCOM produces a commitment, P sends the commitment to Q and then P and Q send the commitment to the functionality F1 and to the functionality F2 and then Q can obtain the result and thanks to the binding property it is guaranteed that both functionalities receive the same input. However the problem is that existing functionalities that have been proposed so far in the literature for universally composable commitments do not allow for that. They don't, in particular they don't output cryptographic commitments. I mean they are not all the same but the basic behavior they do is the following. The party P sends the input to the functionality and the functionality tells a party Q the receiver that a commitment has been sent and at a later stage when party P decides to open the commitment then functionality sends the input to the party Q. So what we have is that existing functionalities do not output cryptographic commitments or a string that represents a commitment. So what we are going to do in this talk is to fix this problem by proposing an ideal functionality for commitments in C-framework that actually outputs cryptographic commitments and then we will show how to be designed a protocol for our toy example using this functionality. Finally in the second part we will talk about how do we design modularly attribute tokens with revocation by separating the tasks of attribute token and revocation and we are also going to talk about a new revocation scheme we have. So first of all the idea of making an ideal functionality that outputs cryptographic commitments is not strange. There are other functionalities for other tasks in the literature that output strings as cryptographic values such as for example the functionality of public encryption that outputs cypher text or for signatures or even for non-interactive ceremonies proofs as we can see in this example the behavior of these functionalities could be as follows let R be a completely binary relation and for a proof that the witness and the instance being the relation so the prover in this case would send the witness and the instance to the functionality the functionality would check that the witness and the instance belong to the relation. In that case the functionality would produce a proof that is sent back to the prover and then party q here receives a symbol of the proof and the instance sends it to the functionality and the functionality verifies whether the proof is correct or not and sends a verification bit. One thing we can realize here is that normally in this all in all these functionalities the simulator is called to provide a proof or to verify a proof and this actually reveals when the party p computes a proof or when the party q verifies a proof. So in our functionality of commitments we would like these tasks to be local so we are going to propose a different mechanism using algorithms to do that. So basically our functionality would call it for non interactive commitments because it actually does not imply interaction between the committer and the verifier. And we apart from the commit and verify interfaces that compute and verify a commitment we will have a setup where the simulator provides algorithms so that the functionality computes and verifies those commitments and validate interface which as we shall see basically is to verify that a commitment is uses the right parameters. So let's look into the details of our functionality. Our functionality as I said requires that computing and verifying commitments are local processes. So what we do is that there is a setup interface that any party can call and in this setup interface the functionality calls the simulator so that the simulator provides algorithms commit to compute commitment open to compute an opening for the commitment and verify to verify a commitment. And this is along with parameters of the commitment scheme and the trapdoor. So once the simulator provides this the functionality tells the party that the setup is already done. In this setup the functionality also creates initializes a table with the following values. I mean the table is empty at the beginning but it will have the following structure. So a commitment a message and an opening and a bit that basically tells whether the commitment is correct or not. So in the commit interface basically the functionality receives as input a value from a party and it computes a commitment as follows. It will run the commit algorithm to compute a commitment as we can see the commit algorithm doesn't receive the message as input it receives a trapdoor. So the trapdoor property implies the hiding property and we will require trapdoor commitments in order to realize our functionality. Then the functionality will abort if there already exists in the table a commitment with the same value associated to a different message because this will violate the binding property of requiring commitment schemes. Then the functionality runs the opening algorithm so that it creates a correct opening for the commitment and the opening algorithm does receive the message as input. Info can contain the trapdoor that allows the algorithm to open a commitment to any message. Then the verification algorithm is used to ensure that the commitments and open is produced by those algorithms verify correctly so it's necessary to run it here. And finally the functionality will put this commitment in the table and with a bit one it indicates that the commitment will always be accepted. And the functionality will send the party a commitment so a cryptographic commitment and an opening for the commitment. And also the parameter and the verification algorithm which as we can see parameter and verification algorithm are needed by later on functionalities that receive committed inputs in order to verify that this is indeed a commitment for that input by running the verification algorithm. So in the verification interface as we should expect the functionality receives a commitment and a message and an opening along with the parameters and verification algorithm. First of all the functionality will check that the parameters and verification algorithm are the same as the ones stored before in the functionality. Later on if the commitment is already stored in the table it will output the same result to ensure consistency. And if there is already a commitment that commitment in the table associated to the different message then it will reject it because this will violate the binding property we require for commitments. And if the commitment is not in the table then it will run the verification algorithm and append the result of the verification algorithm to the table finally send back the result. So as we see both in the commit and verify functionalities the simulator is not queried by the functionality so the simulator doesn't learn when parties compute commitments. Thanks to the fact that we use algorithms to compute them and this ensures the binding property because the functionality will never accept two different messages as valid for the same commitment. So finally we have a validate interface which is basically used to for a party that only has a commitment but not the opening of it to check whether that commitment was computed with the same parameters and verification algorithm used by the functionality. Alternatively we could also make a functionality where those parameters and verification algorithm are output at set up and then the validate interface is not needed both things well. So as for constructions of our functionality as we can see we require trapdoor commitments which implies the hiding property and we require that the commitment is binding and we prove that any commitment scheme that is trapdoor unbinding realises our functionality. So in particular in comparison to the functionality of com that is in the literature that could require other properties such as extractability or sometimes non mollability we do not require that properties which allows our functionality to be realized efficiently by for example commitment pedersen commitments. And apart from that having said that we also propose a variation of our functionality that requires extractable commitments and the relation between these two functionalities FNIC and FENIC would be similar as functionalities for synonyms proofs that require soundness or functionalities for synonyms proof that require extractability. So in some case you use in your protocol the one you need in our example FNIC suffices because mainly because commitments are used always along with synonyms proofs which already provide the extractability property. So back to our example now we have described the functionality for non interactive commitments we are going to show how we use that functionality to provide a secure protocol in a modular way for our functionality F12 that we described at the introduction. So basically when the party P receives the input it will first of all set up the functionality of commitments then it will send the input to FNIC to the functionality of commitments to obtain a commitment. Then we modified functionalities F1 and F2 so that they accept committed inputs so apart from the input the functionality also receives commitment and opening and the verification algorithm so that functionalities can check the validity of the commitment. Then the functionality the party P would communicate to the party Q the commitment is in a secure channel and also the verification algorithm and upon receiving those the party Q would validate checking that those verification algorithm and parameters are the ones used by the functionality of commitments. And finally the party Q when requesting the result it will also send the commitment and the functionalities F1 and F2 will check that the parameters and the commitment are the same as those sent by P and in that case they will compute the result and send it to F1 and F2. So basically now thanks to the fact that they receive committed inputs and the functionalities have this verification algorithm that can be used to check the validity of the commitment we have proposed a mechanism that ensures that F1 and F2 receive the same value as input. So basically what we do in the paper is to prove that actually running this verification algorithm which is provided by the ideal adversary to functionality of Nick will always ensure the binding property so that the input is always the same. So we prove that running verify the verified algorithm will never accept two different messages for the same commitment and that ensures that the input is the same. As we have shown this example of sending the same input to different functionalities but we know that this could also be used in different ways for example ensuring that the output of a functionality equals the input of another functionality. So in the second part of the talk I'm going to describe briefly how we use this idea to design modularly a protocol for attribute tokens with revocation. So attribute tokens is basically this application where user gets a user gets his attributes certified like for example name municipality etc. Personal data certified by a credential issuer that issues a signature and then the user uses that credential to prove that he fulfills an access control policy. For example this credential verify requires that the user proves that age is more than 16. So the user produces a presentation token which is basically an interactive proof of signature possessing that only reveals to the verify that her age is more than 16 but not any other personal data in the credential. Apart from that presentation tokens also have a linkability in the sense that different verifiers cannot link presentation tokens sent by the same user even if they collude with the credential issuer. So attribute tokens need revocation attribute credentials can be revoked for different reasons and we add to the setting a revocation authority that basically will establish whether credentials are revoked or not. This sends information to the credential verify so that the credential verify can check that. So what we do in the paper is basically we design a functionality for attribute tokens with revocation which is a complex task and then we propose a hybrid protocol which is modular and it divides the task into two. One is a functionality for attribute tokens and another one a functionality for revocation. Basically the functionality for attribute tokens is an extension of the non interactive synonox functionality where issuer users get credentials issued on different attributes and on a serial number for the credential. And the functionality will also compute un verified proof of signature possessing and the functionality is also an extension of the non interactive synonox functionality that issues revocation statuses for the serial numbers in the credentials. So what we have now is that both functionalities get as input serial numbers and we employ our functionality for commitments to actually ensure that the serial number received by the functionality of attribute tokens to compute a proof of credential possessing equals the serial number received by the revocation functionality. And we propose also constructions for both the attribute token functionality and for the revocation functionality and we are going to describe only a bit the construction of revocation because it has some advantages over previous constructions. So previously revocation for attribute tokens was non mainly using accumulators and accumulator can be seen as a commitment to a set of values. So basically the accumulator will take the serial numbers and associate its number to a bit and this bit indicates whether the serial number is revoked or not depending it's zero or one. So basically this is a binary revocation situation where either a credential is revoked or not. But in many cases credentials can be revoked locally by different credential verifiers or not. So different credentials verifiers can have their own revocation list. So in that case accumulators are unsuitable because there is some inflexibility that if you want to have multiple revocation list you need to create one accumulator for each of the lists and then adding and removing revocation lists would imply establishing setting up a new accumulator or removing it. Additionally accumulators are not hiding so they could reveal the revocation status associated to serial numbers. So what we do is to propose a construction similar to accumulators but based on vector commitments because vector commitments actually allow us to associate to each serial number sequence of bits and each bit would describe the revocation status with respect to a different revocation list. So if for example a credential is revoked with respect to the video streaming but non revoked with respect to the commerce that could be all accumulated in the vector commitment. And as we can see then we have the advantages that the vector commitment allows us to revoke to introduce to commit to n revocation lists and this is flexible because it also allows to add and remove revocation lists without extra cost. And it allows for some privacy because the vector commitment actually hides the revocation status of its serial number. So in conclusion we have proposed a new ideal functionality for commitments that we call non interactive commitments because it doesn't involve interaction between committer and verifier. And we have shown an efficient construction for it which can be based on feathers and commitments and we have shown how to use that functionality to actually provide a mechanism so that different functionalities in a hybrid protocol receive the same input. And this allows modular design for example a fact that basically revocation and we have also proposed this construction for revocation so thank you for your attention.