 But Alice is really Amazon. So she's sending out, I don't know, how many orders does Amazon get a day? Probably in the millions. So there are hundreds of millions of Alice's signatures out there on hundreds of millions of different documents. And if you stop to think about it, it's conceivable that each of those signatures leaks a little tiny bit of information about her private key, OK? And each digital signature scheme you look at, you have to think about that and analyze it. And I'll leave you to think about, I mean, do RSA signatures leak a little bit of information? Well, I mean, in some sense, they have to leak information in the sense that here's a signature on this document. Before Alice sent the signature, you wouldn't have been able to sign the document. Now that she did, you can sign the document. So the signature leaks the information. Here's the signature on this particular document. But you don't want to leak information about the private key. You don't want to leak information about signatures on any other document. OK, so the issue is a long transcript, people call it a transcript, just a list of signatures might leak information of some sort. And this is not at all an idle threat. Gentry and Sidlo, in the early 2000s, and Win and Regev later in the 2000s, showed that many of the lattice-based digital signature schemes that had been proposed, including at least one that I was involved with, were quite susceptible to these attacks. I mean, we kind of knew there were possibilities of these attacks, and we tried to make it harder by sort of randomizing some stuff and things. But they found some very clever techniques, in essence optimization techniques, to take advantage of the tiny bit of information in each signature, and somehow amplify it, and go in the right direction. And I'm trying to remember, I think the final Win-Regev paper. I mean, we had predicted that a transcript of 100 million signatures might be enough to break the thing, and I think they broke it with about 5,000 signatures. So this is a big issue. And at that point, it became clear you really don't want to be leaking any information. So let me show you how this might work for GGH. Why do GGH signatures leak information? Well, what is a signature on GGH? Remember, the signature, Alice created the signature S by using her good basis to write D as a linear combination, and then she rounded the coefficients to integers. So if you think about it, what that means is that S minus D is a linear combination of her good basis with coefficients between minus a half and a half. That's how she got this close vector. Now, of course, Eve, the attacker, doesn't know the Vs, and she doesn't know the Ts, but she does know S minus D. Now, if you think about it, if you take lots and lots of random vectors that look like this for lots and lots of random Ts, they all lie in a fundamental parallel pipette. Well, shift did, I guess, so it's centered at the origin. So think about that. Every signature tells Eve the information. Here's a vector in a parallel pipette that's spanned by Alice's private key. So that's some useful information, potentially. So to illustrate it, obviously, pictures are in two-dimension. In your mind, imagine 500 or 1,000-dimension, which I'm sure is not a problem. But we'll just stick to two for pictures. So there's Alice's parallelogram spanned by. So this is one of her good basis vectors. This is her other good basis vector. And I just shifted the parallelogram. And there's a few signatures. And if you look at the dots that kind of blot out the parallelogram in your mind, those dots aren't really very helpful. And I literally generated these dots just using a random number generator. Those dots do start to give you an idea of what the parallelogram looks like. And that many dots, you can pretty well reconstruct the parallelogram. Now, it's harder in 500 dimensions, you need more dots. Compensating that are these clever optimization techniques people like Win and Reg Ebb that help you. So anyway, you can see what happens. Alice's fundamental parallelogram is compromised. And of course, the sides of the parallelogram are her private key. And if three different people have their own three private keys, so would I use Carl? Alice, Bob, and Carl. So this is Alice's fundamental domain, Bob's, Carl's. And you can see the dots really do distinguish between them quite well. So in order to prevent this, it'll be on the next line, I guess. A mathematician named Lubechevsky. We'll get it on the next thing. And he came up with this idea of using rejection sampling, which is a method from statistics. And ignoring the crypto, let me give you a problem. Does everyone know what a normal distribution is? It's kind of a bell-shaped curve. Suppose I give you a random number generator whose output is a random number between 0 and 1, but uniformly distributed. And suppose you want to create an algorithm whose output is a random number that has a Gaussian distribution, a normal distribution. Turns out you can do that. You can change one distribution into another distribution. And if the distributions aren't that different and are reasonably well behaved, it's fairly efficient. So Lubechevsky's idea was that you can think of the output like in the pictures there. Alice's output, Alice's signatures, are uniformly distributed in the parallelogram. And that's bad because that parallelogram gives away her key. So let's change the distribution to be something else. And we want to change it so that Alice's distribution, Bob's and Carl's are all the same. And then the transcript can't leak any information because the list of signatures looks identical. OK, so he called it aborting because you kind of stopped the signature process and started again. But I'll call it rejection sampling, which is the statistics term. So the idea is Alice generates a signature, checks if it's a signature she wants to release, if it is she uses it. If it's not, she rejects it herself and goes back and generates a new signature. And she keeps doing this, hopefully not too many times, until she finds a signature that she wants to publish. So first issue, how does she generate lots and lots of signatures on the same document? Well, we've already seen the same kind of thing, which how do you encrypt the same document lots of times without compromising security? You introduce some randomness, OK? So what Alice would actually do is rather than signing a hash of her document, she'd pick a random number and hash her document concatenated with the random number. And if the signature she generates is one she doesn't like, she throws it away and does it again using a different random number. So the hash would look different. Then at the end, when she publishes her signature, she also has to publish the random number, so that Bob can reconstruct the thing that she's signing, OK? So how would this work for GGH? Remember, the signatures are essentially uniformly distributed in Alice's parallelogram. My signatures are uniformly distributed in my parallelogram, which is different from Alice's. Well, how about if we choose a region that's common to all the parallelograms and only release the signatures in those? So Alice's signatures, the one she generates, are all the dots in this picture, but the only one she uses are the ones that are in the box, the square box in the middle. Bob generates all the dot signatures here, but only releases the box ones, same with Carl. Then all three of them, if you had a long list of signatures, what it would look like is just a set of dots that's uniformly distributed in this box, in the square there. They're identical. So they can't give any information to Eve because the distributions look identical. All right, now this, in principle, is what one can do. In practice, no, I guess I actually wrote the algorithm out. Time to go through it quickly. Let's go through it quickly. I mean, I think the picture conveyed what should happen, but what you do is you choose a cutoff value, b. That's the side of the square on the previous side, and you only get to release signatures that are in a box whose side length is, I guess, side length b. OK? So what you do is you want to choose b so that everyone's fundamental domain contains this box whose side lengths are b. Then when Alice computes a signature, she hashes her document and some random bits. She uses her good basis to find the s that's the signature, but she only uses that s if all of the s minus d coordinates are less than or equal to, this b should be a half b, are less than or equal to one half b. So they're in the box. If any coordinate of s minus d is too big, she rejects it, goes back to step two, chooses a different random bit string, tries it again. So this loop, 2 to 4, could go on quite a while. But eventually, hopefully, she finds one that works and then she publishes that s. And it's only at this stage that Bob and Eve and everyone else gets to see s, so they don't get to see any of the signatures that Alice doesn't like. OK? And she also needs to publish the random bits that she used. Why? Because when Bob is going to verify the signature, he needs to recreate this hash of the document and the random bits. Question, remember, speak way up so I can hear. How would you find the b? OK, so yeah, well, it depends on the original parameters of how people choose their private keys.