 Okay, thank you very much a question for the introduction so this talk will indeed be about the picnic signature scheme. So basically the picnic is a new signature scheme that is based on symmetric key algorithms and as such it hopefully resists attacks on quantum computers and in fact picnic is a second round candidate in this post-quantum standardization project. Okay so although it is based on symmetric key algorithms the design of picnic is kind of unique and it is completely different than the classical hash-based signature schemes. Okay and because this is kind of a new and interesting design the hope is that there is a lot of room for optimizations in the scheme and this is work that is currently going on. Okay so the picnic team has as you can see many people coming from various institutions. Okay so in this work what we do is we're going to devise a multi target attack on the initial version of picnic and the attack is a bit unusual in the sense that it is actually not evident like standard multi target attacks unlike standard multi target attacks it is not evident from the high-level overview of the scheme and in fact there most of this talk I'm going to describe to you how picnic works that they're kind of a detailed level because otherwise it's not really possible to understand the attack so we're going to really dive into the design and I think this is also would be kind of interesting because if you don't know how picnic works then like I said it's a very new and innovative design so in this sense it's quite interesting and the attack like I said it will require kind of careful analysis of the internal components of picnic and it turns out that it actually exploits a weakness that exists in additional related schemes and finally this this weakness was fixed in the latest version of picnic. Okay so as I said I will start and actually most of this talk will be just to explain to you how picnic works. Okay so basically picnic like in many signature schemes you start by selecting a secret key and the public key is just some function of the secret key some function f and obviously you don't want the public key to leak the secret key so this f must be hard to invert and in particular in picnic it is implemented by a block cipher. Okay and what is a signature in picnic and basically in a signature is a proof that the signer knows this secret key or the signing key where m the message is embedded as a nonce in the signature. So obviously this signature or proof cannot leak the secret key you don't want it to leak the secret key so it must be a zero knowledge proof. Okay so let's go into a bit more details what we're going to do is basically we're going to represent this function f okay we're going to represent it as a circuit as a Boolean circuit we're going just its implementation and we're going to denote the secret or the secret signing key or the private input to the circuit by x with bits x1 up to xn okay and we're going to denote the output public key by y with bits y1 up to ym. Okay so the only thing that's unknown here basically in this picture is the input to the circuit is the x's right okay so now what the signer wants to do is to prove in zero knowledge that they know some x such that when plugged into the circuit c evaluates to the public value of y okay so this is kind of the goal okay the main building block for doing this is going to be multi-party computation and in fact we're going to use an approach for building zero knowledge that is called MPC in the head by Isha' et al. Okay so let's go into a bit more details so at first I'm going to assume that the signing and verification process is an interactive process between a signer and a verifier okay so later we'll see how to remove the assumption but basically the prover or signer starts the the process by choosing three random input shares that xor such that their xor is this secret of secret key or secret signing key that the signer knows okay he's going to pick them at random such that their xor is equal to x okay now he's going to imagine in his head that there exist some three virtual players okay and he's going to give each one its corresponding share this w share and now he's going to internally run a multi-party computation among these three virtual players okay and the output basically of this multi-party computation is going to be the final shares this final w states and basically the property that we want these w's to fulfill is that their xor is just the output of the circuit which is the public and known value y okay and what we want of this multi-party computation we want basically to preserve the following privacy requirements such that if two of these virtual players combine their information then they learn nothing about this secret x okay so how does this have to how can we actually use this protocol to build a signature scheme so let's assume that the prover or the signer run this run this mpc protocol okay and now the prover what is going to do is going to commit to the view of each player so what does that mean in particular is going to hash the the input of this player for each player it's going to ask its input its randomness that maybe he produced its states and the messages that it sent and received all of this is going to be called the view and the prover is going to commit to the view by basically hashing all this for each player is going to hash all these values okay so we have these three commitments and we're going to send them to the verifier okay now the verifier chooses a challenge which is just a number one two or three and it's going to send it back to the prover or the or signer and now the signer is going to reveal two of the views to the verifier of the players of the players except player i okay and now the verifier can what can we do we can check that the actually that the mpc computation is going has been done correctly on these two players and you can also check that the initial commitments were computed correctly that the prover sent okay so this is basically the the main these are basically the main ideas of the protocol and what does this protocol kind of buy us what what the what are its properties so first of all it's clear that it is zero knowledge because the verifier gets to see only two out of the three views of the players okay and therefore by the properties of the mpc scheme he learns nothing about this this x right this input secret input okay um what about soundness is the proof really convincing well if the prover does not know x and tries to cheat okay and then it is easy to see that either either a player has misbehaved or two views are inconsistent in a sense that messages received and sent and received are not consistent and it is quite easy to see that the verifier can catch the cheating prover with probability one third at least one third okay of course this is a very low probability and we want to amplify it so we just repeat the process say r times and particularly if we choose r equals 2 to 219 we can get soundness probability to be one minus two to the 128 okay so we get very good soundness okay so we said that the process we described the process the signing process is an interactive process of course the signature is not an interactive process so we have to remove the interaction is and we do it actually in the standard way such that the signer generates this random challenges that the verify should have been sent by the Fiat Chameer transform so basically by hashing the commitments uh that he produced with the message okay so this is the basic uh basic idea here and it is quite standard so to sum up a signature for picnic includes for each run one two r it includes three commitments right the three commitments for the players and the views of the the full views of the two players that were opened right and of course the third player is not open because it will reveal the the secret signing key okay so this is basically a signature of picnic okay so now we actually have to look into a bit more details we're going to have to look into the actual implementation of the this mpc protocol okay so how is the mpc protocol of picnic implemented basically remember that we have this bullion circuit c okay and this bullion circuit has several wires and basically let's look at the particular wire with some value let's call it a okay basically we have three players and each player is going to have have kind of a duplicate of the circuit so it's going to hold the a wire with corresponding values a one a two a three for the players okay and what we want to do is to maintain an an additive secret sharing invariant in the sense that the xor of all these two all these three values should be equal to the original value of the circuit of the circuit a okay so how are we going to do that we kind of need to propagate this invariant through the gates of the circuit okay so if we start for example by a linear xor gates then the propagation from inputs to outputs is kind of easy because each player can just xor its inputs and then this invariant this linear additive secret sharing is propagated to the output this is not very difficult to see however for AND gates maintaining the invariant is more difficult okay and this actually requires the players to communicate and to generate random bits okay and for this picnic employ some npc in the head optimizations and particularly remember that the prover actually does not really have to run an npc protocol it's everything is virtual so actually messages don't have to be sent so what we're going to do is basically have the output value of pi depend only on the inputs on its own inputs and the inputs of pi plus one okay so this is basically kind of the dependency graph among the players and the protocol okay so let's again go a bit deeper so how in particular is the AND gate implemented okay so the players will basically generate random bits correspondingly we're going to denote them by r1 r2 and r3 okay and this is this is right we kind of have to to say how the players kind of propagate this this invariant from input to output we have to say what are the computations that they do and well the computations are just given by these formulas respectively and for example let's assume that players the views of players p1 and p2 are open so now the verifier knows the red and green values so we can actually check the consistency for the first equation so because it only contains red and and green values okay so finally i'm going to describe an additional optimization so you can see that the AND gates blow this blow up the signature size because the players generate kind of a lot of randomness and the the compute additional states so a final optimization as that player i is going to have instead of generating the random seeds every time is going to have just a short random seed and it's going to compute the random bits using a pseudo random generator a deterministic one okay so now the view of each player and the signature only needs to include a short seed instead of you know this many random bits okay so this kind of shrinks the signature size which is good okay so finally i'm going to get into the actually the multi target attack and let's see how how this works um so let's start by a very simple overview let's consider say a picnic variant with 128 bits of classical security okay so let's assume that the attacker is given a signature that contains say 219 partial mpc runs okay so each of these runs exposes remember two of the three player views these virtual players and it in particular it contains two random 128 bit seeds and in particular the third seed of the under open player is not exposed okay and it is easy kind of easy to see not from what i described but it's not very difficult to see that if this third seed is actually exposed and it is easy to compute the signing key okay so this third seed cannot be exposed okay so here's a very trivial attack attack attempt so given some run out of the 219 we're going to guess this unknown seed okay but this has complexity to the 128 because the seed is 128 bit long so this is not very efficient this is not a really a valid attack so let's try something maybe more useful we're going to try multi target attack and what what do i mean by this so remember that we have 219 run runs available so what we're going to do is we're going to guess the seed of some unopened player in one of these 219 runs okay and this in this case we actually have 219 targets and the complexity of that that drops proportionally okay so we're kind of making progress and we this is kind of already looks like an attack however there is a kind of a problem here because how do we actually detect that we guessed right okay how do we know that we get some seed how do we know that it matches some seed of an unopened player okay in fact this should be in kind of intuitively it should be impossible because the mpc protocol should protect the privacy of the unopened player so this kind of does not seem to be possible however there is a small subtlety that kind of makes a big difference here and the subtlety is that the mpc promises to protect the inputs of the players and not the random bits that they generate okay and this kind of subtlety makes a big difference here and let's see in practice how this how we can actually compute random bits that that the unopened player generates so let's assume again that p1 and p2 are opened okay so we know all the red and green values and we want to determine the this R3 this random bit that was produced by the third player so let's focus on the two and the second equation here remember we know the red and green values okay and and initially it seems like we cannot do this because there exists some additional green values here that that get in the way however let us assume now that a2 equals b2 equals 0 and remember we know that when this occurs because we know the green values and in this case actually all these terms cancel out and we can then in this case we can just factor out R3 as a simple linear combination of c2 and R2 okay so we can actually compute with these random bits okay so now I can tell you how to actually detect this match by a guest seed and the seed of an unopened player okay we're just for each one in the signature what we're going to do is we're going to derive the prg bits that are produced by the unopened player just as I have shown you in the last slide and we derive these strings we sort them in the table and now we're going to make a guess for the seed we're going to compute the prg on this seed and we're going to search this table okay so this is already an efficient process and actually we can generalize this given some s signatures signed by one by one or by many users then the complexity ideally drops proportionally okay because we again we have many targets okay actually in practice it turns out the attack is more complicated than that I won't have time to get into details but the problem basically is that remember in order to determine this value of R3 for the end gates we can only deduce that if a2 equals b2 equals 0 but the view of each player in each run is different and this is a problem and why is this a problem because we actually can compute different prg output bits for the unopened player in each run so we don't get these nice strings we got kind of the strings with unknown values and we cannot sort these strings okay and this is a problem and we kind of have to optimize the attack in order to make this work and I'm not going I don't have time to to actually show you how this is done but basically the main idea here is that random bits are reused in the circuit and we can actually extract more randomness out of the circuit and it turns out that these optimizations that we do are relevant for maybe additional attack scenarios on related protocols again details are in the paper and if you look at the kind of the final numbers of our attacks let's say on 128 bit variant of picnic then you can see that the time is much smaller than 2 to the 128 and actually we get the improved attack when in the case all the signatures are signed with the same key again details are in the paper okay and finally similar weaknesses turn out to exist in related mpc protocols in particular protocol presented by katz et al at ccs 218 that was actually integrated into the newest version of picnic picnic 2.0 okay so it turns out that kind of this weakness this hidden weakness is not just common to picnic so how do we fix this the fix is actually quite simple I mean when you know all the details the fix is quite simple the fix is basically you have to solve the prg so when you basically what you add a salt when computing the random bits in the prg this kind of forces the attacker to choose the salt and it forces the attacker kind of to focus only on one target instead of having many targets each time the attacker evaluates this prg he has to focus only on one target and this basically this is basically the fix okay so let me conclude the stock so picnic is a new and promising post quantum signature scheme with a lot of room for improvements and we devise a multi target attack on picnic and this is quite unusual as you have seen it requires kind of a careful analysis of the internal components of picnic and an efficient attack actually requires optimization so I think that the most high level conclusion here is that picnic optimizes for practical use what is traditionally considered as theoretical cryptography however when you make these optimizations you kind of have to be careful in order to avoid these so-called real world attacks thank you very much thanks it's a so we have time for some questions yes yes please either use the microphone on the side or I can give you mine so I wonder if is it working yes is a salt affecting the performance of picnic by enlarging a signature it yes it does enlarge the signature but actually the salt I mean you embed some kind of initial salt into the signature and then from this initial salt you can actually generate the salts for all the runs and in a deterministic way so the signature is not blown up by very much so actually the performance penalty for this is not very big so I'm wondering some of those optimizations where you know like using pseudo random seeds in theory I guess you know in the npc setting it it's probably okay to use pseudo random seeds as long as I don't reveal my randomness so some of those weaknesses were they predicted by theory and namely if you would say okay here is a random oracle model here is a bound and the random oracle model I can model perg is a random oracle so there is an actually and there was an actually a security proof for the initial version of picnic and the security proof kind of missed this attack because you kind of have to again look into the details and know that this attack is possible and add kind of you know there is an additional bound on the adversary's advantage so there was kind of this term missing in one of the equations and I mean I mean so it is easy kind of to correct this proof but again you kind of have to to know that this is actually possible in order to to to embed this term correctly but at least in theory I just want to make sure if it's a theory yeah yeah yeah there is a proof there is an actual proof of a picnic security and a random oracle model so but I'm saying if you're saying there was a mistake in the proof yeah there was a mistake but you're saying if the proof was done correctly and you would do the translation it would account for this kind of attack exactly yes right so this in this case it's not like a hacky optimization just a mistake no no it's a just a mistake in any more questions if not let's thank it again thank you