 Okay, well, what is the signature? What does it look like? It looks like the thing in the big parentheses here. That was just how Alice created them. The i-th signature is her private key times the thing that came out of the hash for the i-th signature, times the random polynomial she chose for the i-th signature. Notice something very important here. In each signature, the C sub i's are different and the y sub i's are different, right? But her private key is sitting there waiting to be plucked off the data if you're clever enough to figure out how to get at it. But I mean, it's obfuscated. It's hidden by being in this expression. Okay, so the big parentheses I just substituted in what s i was. The C I just copied. Now I simply do a little algebra. I've used the distributive law. I split it into two sums, because I have a sum there. The f of x doesn't depend on i, of course, right? So I can move that out in front. So this line to this line, just a little algebra. But let's think of what these sums look like. So let me first think about what this sum looks like. The y sub i's and the C sub i's really have essentially nothing to do with each other. Alice picked the y sub i's at random. The C sub i's came out of a hash function. The hash functions produce things that look very random. So these products look quite random. And their coefficients of the y's and the C's were sort of uniform. We're symmetric around zero. Okay, so when you take these products on average, as t gets big, this is actually gonna get quite small. What about over here? We're here I have C i of x times C i of x inverse in some sense. C i of x and C i of x inverse, those are not independent of each other, right? They both depend on i. And if you do an analysis of this, this average actually converges if the C i's are chosen randomly to something non-zero. And I'll give you an intuition on it. Remember, a ring is essentially a cyclotomic ring, a ring of cyclotomic integers, right? So if you think of x as being an nth root of unity, then x to n minus one is really x inverse is complex conjugate. If zeta is a root of unity, one over zeta is the complex conjugate of zeta, right? So in that sense, essentially, if you analyze it from that viewpoint, the quantity here, this product of these two C sub i's is a complex number times its complex conjugate. Okay? And if you do that, you get a positive real number, right? So if you add up these positive real numbers, their average will be something non-zero. That's where it's coming from. And one can work out even explicitly. This, as you take more and more random C sub i's, it roughly converges to four n over three. So the top line is what Eve uses to attack the system. Right? Eve knows this top line. And she computes it and gets, well, and actually she should multiply this quantity by three over four n to get rid of the three over four n, okay? And she'll get a polynomial with real coefficients. And she runs the coefficients to the nearest integer because f, remember, has coefficients zero, one, and minus one. So if you know f to within the coefficients of f to within, say, a tenth, you know f, right? Because its coefficients are just zero, it's ones and minus ones. And that's how Eve would recover Alice's private key. If Alice were careless and didn't do the rejection sampling step, okay. Now let's suppose she does it, she signs things using rejection sampling. I claim that in that case, this transcript reveals no information about Alice's private key. Now the first thing I want you to think about is this is a perfectly valid English sentence. This list of numbers reveals no information about this other quantity. But how do you make that a rigorous mathematical statement and then prove it, okay? So, I mean, this isn't at the same level as Diffie-Hellman's idea that you could create a crypto system that used two separate keys. That was just a mind-blowing idea even if they didn't know exactly how to do it. But this is a similar sort of thing. It's mind-blowing that a list of quantities created using this secret information would contain no information about the secret thing you used. Once you realize that might be possible, one can think about how to do it and then figure out that, yeah, there are ways to do it. But just the idea, I found really, really astonishing. So, how do we quantify this? What does it mean to say it reveals no information? Well, I'm gonna phrase this as a conditional probability. Hope people have seen a little bit of probability theory. So, my claim is that if Alice chooses the private key F zero, okay, regardless of what F zero is and regardless of which, remember the signatures are in this box, that's the rejection sampling step, that all the coefficients of the signatures have absolute value at most K minus N, okay? So, signatures have to be in this box. But if I take a potential public key, a private key, and a potential signature, what's the probability that a signature created using F has S equals S naught, given, this is the conditional, that F is F naught, okay? And I want that probability to be independent of F naught. So, that would mean that if I used F naught to create signatures and you used F one to create signatures and that person over there used F two to create signatures, our probability of getting a signature that included S naught is the same. And can you see that means that the signatures convey no information about the private key because the probability of getting any particular signature doesn't depend on the private key that was used, okay? So, our goal is to prove that this probability, well, we'll compute it exactly, really, is independent of the F naught. Question, and very loud. I cannot understand you. Bjorn, could you take the mic back? And also, I know there was another question in the middle also, we'll do that one next. It's in the back. Where is he? In this last probability, you don't really take into account the fact that the signatures- Hold the microphone right in front of your mouth. The signatures, they are published always with a certain hash of a message. So, even if there's the same probability to generate a given signature for some C. Yes, I'm sweeping that under the rug. What this is actually doing, giving a security under what's known as a random oracle model. So, you're making an assumption on the hash function that it is completely disassociated from everything else in some sense. And even that's not a precise statement, but that's a good point and it can be made precise and I'm ignoring it. Yeah, Bjorn, there's also a question in the middle here somewhere, yeah. Thank you. Do you ever get the same signature with different private keys? Can you ever get the same signature with different, with different private keys? Well, the answer is yes and no. You can certainly get the same S's. You won't get the same S's and C's. Well, I guess even that could happen, but there would be different random Y's that were used to create them. But in fact, the sample spaces for all these things are so large. The probability of that happening is indistinguishable from zero. I mean, the space of possible S's and the space of possible C's usually would have like 260th elements in it. So you're almost, it's highly unlikely to ever get a collision like that. That's a good question. Okay, so we wanna prove this probability doesn't depend on Fnought, even though it's a conditional probability with an assumption that F equals Fnought. So let's do the probability calculation. The first line here is just what was on the previous slide, except I made it a little, I abbreviated it. So the probability that S is Snought, given that the F you use was Fnought, where C and Y are uniformly randomly chosen. C with coefficients minus one to one, Y with coefficients randomly from minus K to K. And this relates to that question back there. If there's actually any correlation that you know of between Y and C, then you might be able to exploit that. So we're basically assuming the hash function is really what's called cryptographically secure. Okay, so what's that probability? How do I compute that probability? Well, I take all the possible C comma Y values and I look at all the C comma Y values that make the Snought, which remember is C F plus Y, that the Snought uses Fnought. And I divide that by the total number of possible Cs and Ys, okay? So this is just how you compute this probability by listing the number of elements in the set that are winning numbers, divided by the number of elements in the set total. Number of winning tickets over number of total tickets. Well, let's analyze this a little more closely. How many C comma Ys are there? Well, once I pick my C, remember Snought and Fnought are fixed. Once I pick my C, there's only one possible Y, namely Snought minus C Fnought. And that Y is only allowed in this pair if its coordinates are at most K.