 Hello everyone, and welcome to this presentation. My name is Sia Vashriyahi, and today I will present the paper Two-Party Adapter Signatures from Identification Schemes. This is a joint work with Andreas Ewig, Sebastian Faust, Christina Ostakova, Monaziz Mitra, and me, Sia Vashriyahi. Andreas, Sebastian, Monaziz, and I are from Tuddamstadt in Germany, and Christina is from ETH Zurich in Switzerland. Okay, let's start with some motivation. Consider the following scenario. We have two parties, Alice and Bob, where Alice has a secret value W, which he would give to Bob in exchange for Bob's signature on a message. Bob, on the other hand, would give Alice a signature, but he would like to be sure that upon his signature being revealed, he would learn the witness W that Alice promised. And by revealed here, I mean that the signature is published on, for example, a bulletin board, a website, or a blockchain. Now, you might be asking, is this a scenario which happens in protocols, actually? And the answer is yes. There are many protocols over the blockchain that need to tackle with such an exchange. For example, we have conditional payments, atomic swaps, and payment channels, as examples. Let's see on a high level what type of protocol do we need in order to handle this exchange. So Alice and Bob would start to communicate with each other. Alice sent some message to Bob, Bob sends to you too. And eventually, Alice would like to be able to get a signature on the message M that she wanted from Bob. And she can extract the signature given the transcript of her communication with Bob and her witness. She can now, of course, send the signature and message pair to the blockchain. Bob would be able to get the signature from the blockchain. And Bob wants to, on the other hand, have the guarantee that given his transcript and the signature which he extracted from the blockchain, he would be able to get Alice's witness. A recent primitive called adapter signatures satisfy what I just described here. I will later in this call go into more details how adapter signatures work. But now I want to give you the history of adapter signatures first. Adapter signatures were introduced in March 2017 by Postera in a mailing list. He proposed a schnore-based construction for adapter signatures. A year later, Pedro Monero Sanchez and Anikid Kate proposed a threshold ECDSA-based variant of adapter signatures in a mailing list. In 2019, adapter signatures were used by MoloVolta et al. in order to construct payment channels. They, of course, require the threshold variant of adapter signatures. However, they did not formalize adapter signatures as a standalone primitive. It was first in 2020 that Aumaya et al. for the first time, proposed the formalization of a single-party adapter signature scheme and provided constructions based on schnore and ECDSA signatures. Later that year, Ezgin et al. et al. proposed two different post-quantum secure adapter signatures from different underlying assumptions. However, until this point, it was unclear from which class of signature schemes one can design and produce adapter signatures. It seemed a little bit ad hoc, the construction that were presented from schnore or ECDSA and it wasn't really clear if there is really an inherent property that can be used from signatures in order to transform them into adapter signatures. Furthermore, the threshold variant of adapter signatures was never formalized until this point. This brings us to our contribution. We know from the work by Klitz, Masny and Pan that ID scheme, identification schemes, can be generically transformed into signature schemes. I will call this class of signature schemes CIGID. In our work, we show how CIGID schemes can be transformed into adapter signatures, in the single-party case. Furthermore, we show how CIGID schemes can be transformed into two-party signature schemes and how these two-party signature schemes can be transformed into two-party adapter signature schemes. Note that our transformations are not generic and the underlying CIGID must satisfy some properties which I will go into more details later in this talk. Okay, now that I have given you some introduction and motivation, I will next follow with some background on adapter signatures, then give you the generic transformation in the single-party case and finally present our two-party adapter signature. Let's continue with some background. Adapter signatures in a more formal explanation work as follows. Alice has a pair of statement and witness where the statement and witness are from something which I call a hard relation, which means that given the statement, the witness cannot be extracted. Alice now sends the statement and the message for which she wants to receive the signature to Bob. Bob at this point generates something we call a pre-signature, a pre-signature which is basically an incomplete signature. Bob sends his pre-signature back to Alice and Alice can now verify if this pre-signature was indeed valid. If so, she would adapt this pre-signature to a full signature. This full signature looks just like a normal signature that Bob would have produced using his secret key. From the naked eye, it is not really clear for someone who just sees the signature that Alice and Bob actually executed an adapter signature protocol. Alice can of course now submit this message and signature pair to the blockchain. Bob would naturally be able to see it and he would be able to run an algorithm called extract which would give him a witness which is in relation with the original statement. So as you can see an adapter signature has four additional algorithms, pre-sign, pre-verify, adapt and extract. The high level idea when designing an adapter signature scheme is to hide this witness in the randomness used for signing. I will go into more details regarding this idea later but first I would like to give you the four properties that adapter signatures must satisfy in order for them to be called secure. The four properties are correctness, unforgeability, pre-signature, adaptability and witness extractability. Let's start with correctness. In correctness we have honest Alice and Bob who start executing the protocol honestly. Bob honestly generates a pre-signature. In this case we expect the pre-signature to be valid. Then Alice would of course adapt this pre-signature to a full signature and sends it to the blockchain. We again expect that the full signature generated in this case would be valid. Finally Bob would be able to extract a witness for the statement originally provided by Alice given the signature and pre-signature. Basically by correctness we just want everything to check out and the algorithm to behave as we expect them. A similar property which is a little bit different is pre-signature adaptability. Pre-signature adaptability is the situation where Alice is honest but Bob might be malicious. Alice sends a statement and message to Bob. Bob generates a pre-signature but he may actually deviate from the algorithm which generates the pre-signature. We want that if the pre-signature is valid and Alice adapts it to a full signature the resulting full signature is valid. So Bob cannot cheat by generating a valid pre-signature which cannot be adapted to a valid full signature. This is a guarantee for Alice because Alice wants to be sure that when getting a valid pre-signature she would actually be able to use it to get a valid signature and send that signature to somewhere as an evidence that Bob signed the message. Okay, let's continue to unforgeability. Unforgeability for adapter signatures is similar to unforgeability for normal signatures except the adversary has an additional capability. The adversary can get pre-signatures on his challenge messages. This means that the adversary should not be able to generate a valid signature on a message M even if he knows a pre-signature on the message M. This is a guarantee for Bob because Bob wants to be sure that no malicious party who is listening to his communication with Alice would be able to actually forge a signature on his behalf. Finally, let's talk about witness extractability. In witness extractability, Bob is honest and he's communicating with a malicious Alice. What Bob wants as a guarantee is that if Alice is able to generate a full signature, a valid full signature by executing this protocol, it should not hold that Bob is unable to extract a witness for the original statement. In other words, Alice should not be able to adapt the pre-signature in somewhat of a malicious way such that she would get a valid signature but Bob is not able to extract a witness. Okay, at this point I will stop talking about our background regarding adapter signatures and we'll continue with our generic transformation in a single party case. To present our generic transformation, I would start with how Schnorr adapter signatures work and then motivate how our transformation actually works. So let's recall what Schnorr is. Well, for Schnorr, we need a cyclic group of order, prime order Q and a hash function which maps elements to ZQ. The generation algorithm simply samples a random element from ZQ and the public key would be G to the power of X. Signing would start by sampling a random element from ZQ and computing G to the power of R. This would be the public randomness and R would be the private randomness. Then the signer computes the hash of G to the power of R, concatenated with M and this S would be R plus H times X. The whole signature would be the hash value plus S. Verifying would involve extracting the public randomness using G to the power of S times Pk to the power of minus H and seeing if hashing this R prime with M would result in the same hash value that the signature included. I will not open the statements here but you can verify that if the signature is valid, this would actually return G to the power of R. Now how can Schnorr signatures, signature scheme, be transformed into an adapter signature? Well, first let's say that the heart relation required for Schnorr is a deloc relation. So the statement would be G to the power of W and W would be an element from ZQ. The pre-signing algorithm simply differs with the signing algorithm in how the hash value is computed. Basically, instead of G to the power of R, G to the power of W times G to the power of R is computed. So we are shifting the public randomness with the offset W here. Verifying would also simply involve putting back this offset when computing R. Now what would we get as a pre-signature upon running this algorithm? Well, we would get R plus H of G to the power of W times G to the power of R. So as you can see, the randomness used here and here do not match the same way that it matched here. But you might already see how we can actually adapt this into a valid signature. We simply have to add the witness to this pre-signature because now the randomness used here and in the hash function are exactly the same. Exactly the same meaning that this value is now in the exponent. Extracting would also only involve subtracting the pre-signature and the signature. This brings me back to my high-level idea which I explained originally. The idea is to hide this witness in the public randomness used when generating the signature. But let's back up a little bit. What is a Schnur signature scheme? Schnur signatures are basically applying Fiat-Shamir heuristic to Schnur identification scheme. So if we do the translation to SIG ID, we would get the following. First, generate a private and public randomness, apply Fiat-Shamir heuristic, generate a signature. And for the verification, we simply need an algorithm that extracts the randomness, but that is given in SIG ID schemes. So it seems possible that SIG ID schemes may be able to be transformed into adapter signatures. Let's see how such a transformation would look like. Well, let's say we have a statement witness paired from a hard relation. Pre-signing would look as follows. Generate the randomness, shift the randomness and continue as in SIG ID, which means apply the Fiat-Shamir heuristic, generate the signature and output H and the pre-signature. For verifying the verification algorithm, first extract the randomness and then shift it. And checks if H is equal to the shifted randomness concatenated with M. Naturally, we would need two additional algorithms. Adapt, which would adapt the pre-signature into a full signature, and extract witness, which would extract the witness given a full signature and a pre-signature. Naturally, we cannot expect that this transformation would work for any hard relation and any SIG ID scheme. There must be some properties that these two, that the signature schemes must satisfy with respect to the hard relation. In more details, there are two properties that SIG ID schemes must satisfy for such a transformation to work. The property one is as follows. Let's say we have a pre-signature. We adapt it and then we extract the randomness from the adapted pre-signature. We would get some random value. On the other hand, if we first extract the randomness from the pre-signature and then shift this randomness, we expect to get the same random value. So if we adapt first and then extract, or if we extract first and then shift the randomness, we should get the same public randomness. This is, for example, necessary in order to prove pre-signature adaptability, where you have a valid pre-signature and you want to make sure that if you adapt it, you would get a valid final signature, a valid full signature. The second property is simpler than the first property. It simply states that if you adapt a pre-signature and then extract the witness from this signature and pre-signature pair, you would get the same witness as it was used originally in order to adapt. This is, of course, needed for, for example, proving extractability. Now, at this point, I will not go into more details regarding our single-party transformation of sig-id to adaptor signatures, and I would now summarize our contribution with respect to single-party adaptor signatures. First, I would like to point out that many signature schemes satisfy these two properties that I mentioned before. It is not only Schnorr, but, for example, Casvang and Julia Quizquat. So it was not a coincidence that Schnorr could have been turned into adaptor signatures. Actually, these other two schemes can also be transformed into adaptor signatures. Second, unique signatures such as BLS cannot be transformed into adaptor signatures because there is no randomness to actually play with in order to transform them into adaptor signatures. We actually proved this in our paper, and if you're interested in the proofs, please take a look at our full paper. Okay, let me continue to go to the final part of this talk and talk about two-party adaptor signatures. So what we saw by now, we saw that we can transform sig-id schemes into adaptor signatures. I will now talk how to transform sig-id schemes into two-party signature schemes and how we can transform two-party signature schemes into two-party adaptor signature schemes. I will not go into too much detail on how these transformations work. I will give a high level overview regarding them. If you're interested, you can check our full paper for more explanation. First, let me motivate why we need two-party signatures and adaptor signatures. There are some applications which require signatures from both parties. However, we would like to have a single signature instead of two signatures. So we don't want to get one signature from Alice, one signature from Bob, and concatenate them. We want to have a single signature on behalf of both parties. On the other hand, we do not wish to run a distributed key generation protocol because some applications would require Alice and Bob to generate such signatures time and time and time and again. And if you have to run a distributed key generation algorithm for every execution of the protocol, this would be quite inefficient. So what we want to have is that Alice would run her key generation algorithm separately, and Bob would do that also separately, so they have functioning secret and public keepers. But they would be able to generate a single signature after running a protocol, which is valid under the aggregated public keys. So the solution to what we want, basically a mechanism which Alice and Bob can use in order to generate a single signature without using distributed key generation, is two-party signature schemes with aggregated public keys. Now, let me show how we can transform CIGID schemes into two-party signatures with aggregated public keys. First, Alice and Bob need to exchange some randomness. This is a very traditional random exchange protocol where one party commits to the randomness, the other party then submits randomness, and they can open the commitment eventually. What they get after running this protocol is Alice would get her private randomness and two public random values, and Bob would also get his private randomness and two public random values. Then, both parties would generate a signature. How does this actually work? Well, first, the two public random values must be combined, then the Fiat-Chama heuristic must be applied, and then the signature can be generated as we discussed previously. Bob also does the same, but he uses his secret key. Alice uses her secret key. By this point, Alice and Bob both have the same hash value, but they have different SIs. They now exchange their SIs, and they would combine these two signatures that they had, and they would eventually get one full signature, which is valid under the aggregated public key. Now, the question is, how can this transformation, this two-party signature scheme, be transformed into a two-party adapter signature scheme? Well, the only thing that we need to change is to shift the randomness first before applying the Fiat-Chama heuristic, and that's it. Okay, I will not go into more details regarding two-party signatures and two-party adapter signatures from SIGID. If you're interested, please take a look at our full paper. Let me conclude the talk now. We actually analyzed which signature schemes can be transformed into adapter signatures, and we provided the generic transformation from SIGID schemes to adapter signatures. Furthermore, before the first time, formally defined what two-party adapter signatures are and provided the generic transformation from SIGID to two-party signatures and two-party adapter signatures. Now, the area of adapter signatures have gained a lot of attraction in the past few years, especially in the blockchain area, so there are many things that can be analyzed. Here, I would mention two future works. One would be to analyze other classes of signatures and see if they can be transformed into adapter signatures. For example, we can think about transforming signatures in the standard model from different assumptions, and by standard model, I mean that we are not in the random oracle model. Second, the main applications of adapter signatures by now have been in the blockchain area. It would be quite interesting to see if this primitive can actually be used in other areas, similar to the way that it was used in the blockchain area to solve some different problems. With this, I would like to thank you all for your attention, and if you have any questions, please feel free to contact me, any of the co-authors, or use the live session to ask your questions. Thank you very much. Thank you.