 So welcome to the session on post-quantum cryptography. We have three talks. And the first talk has a large list of authors, Mingxing Chen, Andreas Hulsing, Yust, Rinevelt, Timonus, and Peter Shavaba. And Yust, Rinevelt is gonna give the talk. So I'm gonna talk about building MQ-based signatures from five-pass MQ-based identification schemes. Yeah, let's just start. Why do we want to do this? So the problem is we want to have signatures in a post-quantum setting. The current signature schemes are not gonna cut it when quantum computers arise and we wanna have a secure signature scheme. Basically we want two things. We want security arguments for these schemes so that we know that we can trust them and we want them to be acceptably fast and reasonably small in terms of signatures and key sizes. You can debate about what is acceptable here but let's just assume we have some notion of what is, for now let's just assume we have acceptable term. There's a bunch of people that have already come up with solutions. There's letters based on MQ. They all have upside to downside. We're gonna focus on MQ here. For MQ, the current situation is that the stuff that's out there, the security is not very clear. Many of them have been broken. There are some that still stand. And we're gonna try and base the signature scheme on MQ that is a bit more conservative. But before we get to that, let's first go for the general construction and an overview of what we're gonna do in this work. First, we're gonna in general transform five-pass identification schemes into signature schemes. To do this, we extend the Fiat-Chemier transformation. This is typically traditionally defined for classical IDSs. I'll talk about it later in a bit. Then we'll show that an earlier attempt to do exactly this did not suffice. And then we're gonna look at a specific application of this and then look at an MQ-based signature scheme that you can obtain by using this transformation. Signature scheme bases its hardness on the MQ problem, which I'll also introduce in a bit. And then we instantiate and implement and show how fast this is and how big it is. There's some footnotes. There's stuff we don't do. The reduction is in the random model and not in the Q-ROM. The proof is also non-tight. There is a reduction, but yeah. So let's get started with some preliminaries. Canonical identification scheme. So this is the typical three-pass identification scheme. The prover commits to some random value using the secret key. Since these commits over to the verifier, he comes up with challenges. The prover commits compute responses based on the challenges that he gets. And since he's over, the verifier checks if these responses match what he would expect based on the commits and the challenges, or the commit and the challenges. This is the traditional setting. And then what do we require of this identification scheme? We require it to be passively secure. And we define security in terms of soundness, which means the probability that the tertiary can convince a verifier should be small. So only a real prover that knows the secret key can convince a verifier. And we also want it to be honest verifier of your own knowledge so that basically, the verifier could simulate the entire transcript, showing that he does not know the secret and he's able to compute one of these conversations without actually knowing the secret. If you go from the bottom up, this is a convincing way to show that your secret is not actually leaking. So for soundness, there is some chance that the tertiary can guess right. We define this with the soundness error kappa. This should be small enough so that, yeah, this is a negligible, I don't understand, but for one round of the IDS, this would typically be like a half or two thirds, something along those lines. But we'll come back to that. So how do we turn this into signatures? You'll apply the Fiat-Chimé transform, but before doing that, we first need to get rid of the soundness error. I just mentioned it. Typically, this is a number of the order of half or two thirds, and by composing a lot of instances of this IDS in parallel, we can reduce this because basically, you're multiplying the soundness error for each parallel composition that you're doing. So you compose until you get to a negligible level of error in your security parameter, okay. And then we transform this into signatures. The end result is non-interactive. So before we had this two-party thing where you had a prover and a verifier, now we just wanna have a prover that computes the signature. So the signer is the prover, and he uses some hash function to, or some function H2 compute challenges, which he then responds to, and this conversation ends up being the signature. And we wanna generalize this because this is the classical three-pass setting, but by scaling it up to five-pass, you can benefit from a lower soundness error. Typically, the three-pass schemes would have a higher soundness error, and then you would need to have more in composition, but generalizing this to a different setting could make for a more efficient scheme that has less rounds, so smaller transcripts and easier to compute. But then the current Fiat-Chemere transform works on the canonical ideas that I just showed, so that's where we're aiming at now. So as I mentioned before, there was an earlier attempt to do this, 2012 Africa Crip, a paper appeared that defined end soundness to apply Fiat-Chemere, transform any two end-plus-one-pass signature scheme. And basically what they did, they said if you have two transcripts that agree up to the last challenge, and then you can extract the secret key, then you have this property called end soundness and then the transform applied. We show that this actually does not gain you anything, because all the schemes where this would apply can be transformed back to three-pass. So you can restructure such an ideas. Basically what we're doing is we show that if you have some three-pass ideas, you can prove on a sphere of our knowledge by taking, for example, if you're going from a five-pass, you would combine the first three messages into one, then get a three-pass scheme, and for special soundness you would show that you can extract from some three-pass scheme using the extractor that this five-pass scheme would provide. Basically you're proving an equivalent three-pass scheme based on an existing five-pass scheme that has this property, which would be great, because then you could apply the traditional fiat-shamia transform to this resulting three-pass scheme, only none of the existing five-pass or seven-pass schemes, whatever pass schemes apply, because they don't satisfy this condition. There's no such extractor that from two of these transcripts you can actually get the secret key. Then the authors ended up picking it in the general version of this paper this year, and they redefined, and now it doesn't reduce the three-pass anymore, but still it does not apply to existing schemes. So that's the gap where our work comes in. What we're doing is we're doing a fiat-shamia transform for specifically five-pass, as opposed to two n plus one pass, and we're restricting it to a very specific instance. So we're looking at schemes that have to form the first challenge. So if you're doing five-pass, you typically have two of these challenge phases. The first challenge phase, you take a challenge from some queue, so that is a parameter you define, and the second one is a binary challenge. So it's either a zero or one. That restricts the setting we're in, so it's not a general five-pass scheme, but one that confines to these limitations. And then we're gonna prove that this is CMA using an unfortunate, anyway, we're gonna prove this using a dedicated instance of the forking lemma, specifically tailored to this Q2 IDS constraint. Basically, we assume a successful forgery, then we generate four signatures following a pattern on these specific challenges you would have for the first challenge, you would have one that agrees and one that disagrees, and then for the second one, also one that agrees and disagrees. This is a very specific pattern for these that follows from the fact that this is a binary second challenge, and then we can obtain four of these traces and use an extractor to show that this works. This would apply to IDSes that follow this pattern. Now, before going into the very specific instance that we're applying this to, because this looks like we have some instances in mind where this condition holds, let's first look at the context of this, the hard problem that we're basing this on, that's the multivariate quadratics, the MQ problem, and it's defined as follows, we take a function family MQ over some M and FQ, and all of these are polynomials that are quadrat, so basically they consist of quadratics, quadratic terms and linear terms, and they have coefficients, and together all these coefficients make up an instance of such a problem, so basically the problem is given some output of this function family for some inputs you need to find the pre-image x that went into it, so basically you're solving a system of equations where you have coefficients a and b and you input the x's and then get the y's out, then going back, if you have this y factor, you cannot easily find the x's. That's in a nutshell the hard problem that's behind this, and then we're looking at an identification scheme that uses this, now I'm not expecting you to read this protocol in detail, but just to get a general idea of what this IDS would look like, well it looks like this five pass setting that we're looking for, it has first challenge alpha comes from some FQ, and then the second challenge CH2 comes from the set zero one, so that's a binary challenge, first the prover commits to some randomly chosen vectors from FQN, commits to these, responds to the challenge alpha, there's an evaluation of F there, that's this MQ problem that we just discussed, and there's also G up there, which is a variant on this, I'll come back to that on the next slide. Basically this follows exactly the pattern that we just looked at, but the assumption is that the proof would hold for. So this is the scheme that we're gonna look at, so how does the scheme work in a bit more detail? It relies on just the MQ problem, typically MQ, a scheme based on the MQ problem would also have other related problems, which typically introduce the security problems that we've seen with other schemes based on this problem that would rely on isomorphism of polynomials or other related problems, and then people would claim that they are based on this MQ problem, but there's also related problems and these typically lead to attacks, while for this scheme it's only this MQ problem that we're looking at, because that's the only thing we're evaluating here, and what Sakamoto et al did for this IDS, they showed that you can take this MQ problem and split it into parts, split the secret into parts, and then using some baleenier function that won't go into detail here, but this allows them to split it in such a way that you can either reveal these three factors or the other three factors, which basically give you the responses of the prover here, and this shows that you can have some sort of proof where you're proving knowledge of either one half of the secret without revealing the other half, because the split is random and does not allow you to compute the other half of this secret S. I won't go into detail on this any further, but that's the general idea. So what do we do with this? Basically now we build a signature scheme out of this by applying the Fiat-Chimere transform we saw earlier. Start by sampling some seed and picking a random secret key value that serves as the X for our problem F. Basically we had this X of input elements that would go into capital F to evaluate to get to some Y. Here SK is the X and PK is the Y, and that instance is basically our key, and then we take some seed to sample F from because F is this large set of all the coefficients and it will be very impractical to have this as part of your key, so you would typically just have a seed to expand this from. You could also have this as a system parameter, but yeah, that's not necessarily a reason to do that instead of just having it as part of your key. So what does signing look like? We sign some random digest M at D over M, so we hash it and then use this as an input bit string, and then we perform our rounds of this IDS. Basically we're doing this Fiat-Chimere transform where we first parallelized this IDS. We've made a composition of our instances of the identification scheme, and this consists of doing two R commits because you saw earlier that there's two R, or two commits per instance of this, and there's also two R evaluations of this MQ function because there's F and there's G up there. I'm not sure how legible this is, but people in the back will just have to believe me on this. So there's two R commits, some multiplications in FQ for this challenge alpha, and then two R MQ evaluations, and in terms of how much effort this is, like where does the computation go? These commits are just applications of hash functions, or some string bit commitment, but these two R evaluations of MQ, that's the costly part. And then of course there's some size so we can play a few tricks to reduce the signature size. That's typically the bottleneck here. You don't want to have a very large signature and you want to somehow limit this to as much as you can. And you can do this in a couple ways. One of a few of the tricks we pull is you only include the necessary commits. Basically the verifier reconstructs one of the two commits and the other one you would need to supply, but the one that the verifier is reconstructing anyway, you wouldn't need to make part of the signature. And you could commit the seeds that's instead of committing to like full sets of random data, you could commit to some seed that produces this random data and then later reveal the seed. For R parameters that last trick didn't apply, but in general it could work. And then how does verifying work? Basically bottom up of the same story. You reconstruct the digest and this system parameter F because the seed is part of the public key. Anyone can just reconstruct F. You reconstruct the challenges from whatever is part of the signature because the prover used the message and is commits to generate the challenges. You verify the responses. You reconstruct the missing commits that we omitted by only including the necessary ones. And then you check if the commits that were omitted actually match whatever checksum or hash or whatever was included to account for like leaving out half of these. And then there's a bunch of parameters that we leave out that we've omitted to give instances of so far. So there's K, the security parameter and there's N and M, the dimensions of our MQ problem where N is the number of inputs and M is the number of outputs. We're doing this over some finite field FQ. There's a commit function, there's a bunch of hash functions and there's random number generators. So let's now look at a specific instance of this. So MQ DSS 3164 is what we define as the instance in our work. For some security parameter, K is 256. This results in the general post-mono security of 128 bit. And then we have some soundness error kappa that depends on Q, so that makes it important to choose a Q that is not two. Typically people would choose Q is two for one of these problems, but then if you increase Q kappa decline, so you would need to have less of these composed IDSs in parallel, which makes it interesting to choose a slightly larger Q. So we go for Q is 31 and N and M are 64. These are restricted by a text that would be feasible if you have lower N and M or you would have them vary because you could have a slightly larger N and a slightly smaller M for example the other way around. But they are also an artifact of wanting to choose nice parameters for code. Come back to that briefly in a second. And then there's a bunch of functions that you would need. We have some commitments, some hashes, some certain anomalies generators. All of this is not really much of a factor in terms of how fast the scheme becomes. So we use the reasonable choice of just going with catcher functions here. So to summarize, the signature then contains some R to have the randomized message digest, some hash over these commits that we're leaving out. And then for each of the rounds, there's gonna be 269 of those. We have these response factors, T, E and R and one of the commits that you would need to include that the verifier cannot reconstruct so we would need to include half of them. Which comes down to roughly 40 kilobytes of signature size. So a slightly more detailed look at how this MQ problem works. So going from FX to X should be hard but from X to FX is something we do a bunch of times during the evaluation of this, during the creation of the signature. So let's be evaluating this FX. That should be easy. And when I say easy, I mean fast. Basically, you look at the MQ problem as a triangle. You have a bunch of axis on the X axis, a bunch of axis on the Y axis. What we're trying to do is we're multiplying each of those to create the quadratic terms. And then you have a dimension basically for each of the coefficients A that you would have for every element in the output factor where you're basically evaluating one triangle for a pair of elements in the output. Which are triangles are not that great to work with. So what we're trying to do is go to a rectangle. And that's also where the parameters come in because then we want to have a rectangle that fits nicely into registers. And then we look at, we earlier discussed we had an anemone 64 and then we have elements in F31 and these elements are nicely represented by five bits and you can place them into slightly larger spaces or you either put them in eight or 16 bits and then have some space to do your computations. So this all fits nicely in the architecture we're targeting here. That was like a reason to also come up with these parameters. To give you some conclusions and benchmarks, the signatures are 40K which is roughly what Sphinx is also getting. Sphinx is the current state of the art hash based signature scheme which is the most conservative signature choice you could seem to make right now. There's probably a private keys of 72 and 64 bytes. So those are very small. It's a result of choosing just a seed and this input to the MQ function. Signing time is not comparable to letters based signatures but definitely faster than what Sphinx is getting. Purification and key general are similarly reasonably okay. But more importantly, or also important, we now have a general FHMU transform for IDSS of the form Q2. Yeah, and we present a signature scheme that actually does competitive signatures with a reduction to just the MQ problem. That's it. Code is publicly available and public domain and that's it. Question or questions? I'll ask a quick question then. So I was interested in whether you can do something five parts that would make code based signatures more efficient, anything about that? Yeah, so actually in the journal version of the paper I referenced earlier where they had this updated version, they also present the code based signature scheme and while their reduction does not immediately apply, ours would apply because it's of the same form. It's a Q2 IDS, so typically what we're doing here would directly apply. I'm not sure about what the performance would be like or what size it would be like, but yeah, it would definitely work. This is why we're not accepting power. So please send us the slide before the session or you can put your slide on the computer of the conference before the session starts. I did try before the session. Any other no? The problem is that the conference computer does not have power points, so. We did. No, you don't. You have WPS off it. What? I can't. The laptop that was here before didn't have power points. No, you don't. I mean, you did it earlier when I tried. You did the slide a little bit earlier. Yeah, that's not power points. That's WPS off it. I don't think that's not being used to it.