 Here at Plankstage, we have a very special guest for you coming up. I want you all to give a warm welcome and a big round of applause to Jeff Bridges. He will talk about the cryptography for killing proof of work. And yeah, when everything is done and you're ready, I want you all to have much fun and enjoy the talk. Okay. Do we have video? Somehow, oh yeah, we do have video. Okay, cool, thank you. All right, so this is not really much of a talk about. This talk may get a little bit mathematical. I'll try not to be too mathematical. I'm not actually going to say too much about the protocols for using the two constructions I'm going to tell you about. But I'm going to, I'll say something, like general like what security of these things looks like and stuff. Okay, so two things. All right, so there's this thing that has become kind of popular lately, which is using proof of work to try and build blocks on some chains or something like this. And we don't really like this very much. It uses more power than like a number of countries at the moment. This is kind of, this is a problem. So I'm going to, seems my thing advances automatically if I don't. So I'm, okay, so I'm going to tell you about sort of two general categories of solutions here. And there's kind of an interesting parallel between them. All right, okay, so the general one category is don't do block chains. Just use fiat money. And then we have this other, when we do that, we have this problem. Okay, so one of the things we actually kind of like about block chains is that we like quite a lot is that they, people have started building privacy tools that run on them. Ccash actually works. You know, there's a number of these privacy chains that are not that great, but so or, you know, it's unclear. But, but we know these tools can work even if they require some sort of Herculean effort. And so one option is just to use the fiat money but fix the privacy. Another option is to invent this thing called proof of stake. And then you still have to do all the other stuff on a blockchain to fix the privacy. So the first thing I'm going to tell you about is sort of how you would, if you do like fiat money, how you would fix the privacy. And then I'm going to tell you sort of one of the core sort of, not completely unavoidable but mostly unavoidable building blocks of doing proof of stake. All right. Okay. So what is a blind signature? So a blind signature is a signature where the signer doesn't know what they're signing. So the first thing you notice here is that normally when I sign something, it's just me. And of course, if it's a blind signature, then somebody else has to have made up the thing that I'm signing. So I obviously, now I need some kind of multi-party computation or some kind of protocol to do the signing. It's no longer just an algorithm. Okay. The other thing is that what does it mean to sign something I've never seen? Well, probably what it, one interpret, there's other things you can do, but the normal interpretation is that the, sort of the easiest thing is that the actual contents of the message, so the message that's being signed have no meaning at all. And the real message is just the name of the public key. It's what the public key is for. In concrete terms, the blind signer tends to be some kind of bank and they sign with a public key that says, this is worth five euros. So they're minting money. I'll make a combined slide talking about that in a second. Okay. And then in that context, what really happens is that the signer makes, they limit how many times each of these signatures, they don't let you use the signature more than once, and that's what gives it some, that's your double spending protection. And then the actual security construction for these things tends to be that you need a, that the clients can't obtain more signatures than they asked for. And then this is actually really sticky. I'm not going to talk about it, but this is actually really cryptographically, there's a lot of sticky stuff there. Okay. So if you're interested in these things, there's this thing called GnuTaller that I'm not going to say very much about, but it does a nice, it has a very nice implementation. It does a whole web whatever thing you can look at the demo and install. It's a browser plugin and it lets you pull money out and spend things. For people who like blockchains, at the moment, Taller is not very blockchain friendly because you need this issuer. Somebody has to sign something. You could, you could threshold sign. There's, in general, in cryptography, there's threshold signing where you have many parties do the signing. You could do that maybe on some kind of blockchain, but then it wouldn't, there's a lot of security problems with that. So, okay. There's other things in this general category of blind stuff that I'm not going to talk about. Like there's this thing called coconut, which comes from Planche Velsander signatures who, if you're interested in this category of things, then there's a number of interesting constructions here. But in general, they're not the kind of things you would reach for when you're trying to build something blockchain-y. Okay. So just a picture of what this stuff, how one would actually deploy one of these things. So you have the guy who actually does these blind signatures, a case called an exchange or an issuer or bank or whatever he is, and it's fiat, it's, there's some authority that's keeping them from signing too many things, because that's the underlying problem, is that if you have a key, you can sign, you can sign as much as you want. So then you have some customer, they give, they give the exchange some money, the exchange blind signs these things for them, and then they spend them and the merchant redeems them. Okay. So it's a fairly, it's actually a very simple protocol. It's been around for 30 years. This was invented by David Chum ages ago. And, okay. So I promised a little bit of math. So I'm going to talk just a beef. So how many people have known what an RSA signature, how an RSA signature works? Okay. Like, almost everybody actually. Okay. Great. Then, okay. So we have the usual RSA for the public key generation. There's really nothing special here. Now, the blind sign. Okay. So the layout of this slide is, I'm jumping back and forth between what the signer does and what the user does. So, okay. So now the, this customer who wants to get some coins, what do they do? So they have to get this public key from the RSA via some, via the other guy, via some kind of PKI. And they have a message that they want signed. And this message, as I said, will basically be meaningless. But the thing that's different from a normal RSA blind signature is that they have to pick some random number here. And they multiply, they encrypt this, raising this B to the E is an RSA encryption. So they encrypt it to the public key that they want the signature by. And then they multiply that by their message. And so in this case, the message, it has to be the output of some hash function that's less than, that's just less than N. All right. Okay. And then they send this M prime over to the blind, over to the, to the signer. And what the signer does, just the usual RSA blind signature algorithm, they, they raise this thing to the D mod N. And okay, so the important thing that I don't have on this slide is that raising to the D and raising to the, and raising to the E are inverses of each other. This is really what we get from, yeah, so here it is. So in the exponent, the D and E are inverses of each other. So what this, what the, at this point, what the, what the signer has done is they have, they have, they've taken the original message. So if we distribute this D across the product here, they've raised M to the D and they've raised B to the, which was raised to the E here to the E times D. And so what pops out is just, is just the, is just the M to the D times B. Because this is they've, we've encrypted to them and they've decrypted it for us. And now, so now when the, when the user, the wallet or whatever gets back this, this S prime, they, they just unblind it and they have a perfectly reasonable signature. Okay, so I'm happy to answer questions about this thing later about sort of, there's a number of little technical points here. So like I, I probably should have done a better job here. It's actually extremely important that M can go anywhere up to just below it to one minus N. And it's also extremely important that that's true for B as well. The, okay. And it's important that M is the output of a hash function. It's important the user can't control it. So there's a number of actual security assumptions here that are, that are a little bit unusual, but okay. Right, so this, the thing that I probably should, yeah, so this thing about the M are, about our message actually being a number that the, that the user doesn't have control over mod N is what's, is what's called a full domain hash. So technically, so the underlying RSA signature here that is, it would be described as RSA FDH or as the usual RSA signature that everybody uses is RSA PSS where there's some randomness put in. Okay. So, oops, sorry. All right. Yeah, so that's actually what this slide was about. So, so there's some kinds of security proofs here and we really need the, we really need this full domain hash property in the security proofs in, and the, in practice however, so this is kind of a nice signature scheme because RSA is very familiar. There's still some weaknesses so you can't run one of these things in any kind of cloud provider. Okay. There, there's, it's kind of weak, the way in which you actually optimize the signing algorithm makes it weak against side channel attacks. Okay. So, all right. There's another kind of blind signature scheme which is normally people don't use which is called BLS signature. So, this is just the normal BLS signature. So, there's, we're going to be using elliptic curves so the whole setup would be much, much more complicated. I don't want to go too much into this but the important, one of the really important things here is we have to have this hash to curve function. So, this is a way that I can take a string and I can get out of it a curve point and there's no, and there's no way that I can know from this, like, if I, if I do this with two strings or then there's no relationship between, there's no way to, I can do, do then algebra in the curve to get from one of those to the other. It's like, one, essentially a way to think about it is that, so this curve is some finite object but it's almost like we imagine it as being an infinite dimensional vector space and whenever I just give you a string, what I get out is some other thing which is linearly independent to everything else and I can't, like, add them up and get between them. Okay, but what was really going on is that we just don't, whatever this thing gives us we don't know the discrete log for it. In practice, how this hash to curve function, how is it implemented, so one way to implement it is you just hash and try and make a curve point. You literally just make the curve point and maybe the thing you make doesn't satisfy the equation then you try it again and you, and again and again until you get something that works. All right, so the other feature of these, so this hash to curve we can do on any elliptic curve, these BLS signatures require a curve that is a pairing. The important thing about this is that when I, if I take, that if I have a, so all right, we'll back up here just a second. So I have this elliptic curve. I have two subgroups of it. One is realized over, one over the elliptic curve in some field and probably normally the other one I need some kind of field extension, whatever, and I have some generators for them. But the important thing is that when I multiply elements on one side of the pairing, I can flip them over to the other side. All right, so to show that sort of, okay, so what is the signature here? It's literally just I hash the message to the curve and I multiply it. So I've got all this very complicated elliptic curve stuff, but then the signature is completely trivial. And the verification equation is just that I, I literally am just flipping the A that was multiple, the private key that was multiplied here to make the signature. I'm literally just flipping it over across the pairing. Okay, so be honest, there's a lot of interest in them lately. So how do you make a blind signature out of them? So basically exactly the same way you do it, almost exactly the same way you do it with RSA, except it's easier because now this, when I'm doing, when the user is blinding the thing, they multiply, they sort of hide the message and then they send it to be signed and the signer just blindly does this, just does this scalar multiplication. And then when they hand it back, they just multiply by the inverse of this guy. Okay, yeah, so this is, so all right, so it's a, and then the verification equation, just like in the RSA case, the verification is exactly the same. All right, so any questions so far? Sorry for the going kind of fast, yeah. Microphone and yeah, please use the microphone and state your question loud and clear. So we have it on the stream. Sorry? Can you please speak up? The step one of blinding is create B? Yeah, it should be create B, sorry. Yeah, anyway, yeah, yeah, yeah. The S here should be an S prime. There's, okay, my slides are a little bit messy. All right, okay, so these are kind of cute. So two things I want to emphasize in both of these constructions. What I needed was that, so in the FDH construction, I had to remove the usual randomization that I didn't talk as much about this as I probably should have, but I had to remove the randomization that often happens in the RSA padding and just use this full domain hash. And here, also this h, this hashing to the curve thing gives me this nice very deterministic map. There's not really, there's nothing random here. So in both of these signature schemes, there's nothing random in the signature scheme at all. And that's, as some of you may know, that's not true in the signatures that we really use every day. Well, we do use RSA every day, but in the signatures that we really like to use every day, well, this is these Schnorr signature, the ED25519 signatures or ECDSA, they need some actual randomness in the signature. Okay, so yeah, okay. So I'm gonna now talk just a little bit about this sort of consequences of having randomness in signatures. Okay, so there's a thing cryptographers do called a pseudo random function and it's just a formalization of basically what we do when we have these message authentication codes, that there's a key and you hash some stuff using, essentially hashing with a key is just you hash the key first and then you hash the rest of the stuff you want to hash. But with a good hash function it is, that's what it is anyway. With older ones like SHA-1, it's not, you have to do a little bit more. But okay, a verifiable, there's these things now, they're not pseudo random functions anymore, they're verifiable random functions and they're this kind of public key analog of a hash function with a key. So I want to be able to put in a message and get out something and what I mean by public key analog is that anybody, who if I show them the input and the output, then I can show them some kind of proof that that output was computed correctly by someone with a public key. Okay, with that particular key. And it should be a function, a particular key should determine exactly where it goes. Okay, so only the secret key holder should be able to compute this guy and if we think about what would happen with a hash function, you know, when you do like a Mac, you're sharing the secret between you and somebody else. That's why, but okay. All right, so we've sort of already seen one of these things, so in this kind of map where we take, I probably should have had something about RSA here too, but if I have a message and I just hash it to a curve and I multiply it by A, well, this is actually one of these VRF. Well, this is almost a VRF. This is giving me something completely deterministic, so these BLS signatures, I'll talk about it in a second. Those would give me a VRF, and also this RSA with a full domain hash gives me a VRF, and there's others. Let's see. Right. Okay, yeah, let's just stay on this for a second. So what's kind of cute is that the same kind of making the signature scheme deterministic that I needed to do the, to do the, really to make the blind signatures work, that's not true for all blind signature schemes, but it's true for the ones that make sense. This kind of making the thing deterministic is exactly, it also makes the thing into a VRF. Okay, now, I'll say something, so both of these signature schemes that we've seen, the RSA with the full domain hash and BLS give me VRFs. Now, in fact, neither of them are probably the ones you actually want to use. The thing you actually want to use is this weird construction. It's very much like a Schnorr signature, but with extra stuff thrown in. And, okay, what do you do? You do have to hash something to the curve, just like with BLS, except now we're not over a pairing friendly curve. We're just over a normal curve. There's not going to be any pairings. And we pull out of it a, okay, so we again have some kind of curve point, which is our secret key multiplied by something hashed to the curve. But now we're going to, so we've done, that looks so much like a BLS signature, but now we're going to make it look like a Schnorr signature. We're going to make up, or an ECDSA signature. We make up a nonce, and we construct this challenge, what's called a challenge in that sort of short NISIC terminology, which is, but if you think about what would happen in a, so if I drop, let's see which one. So if I drop all the ones in which, so if I drop this guy, this guy, and this guy, then I have a Schnorr signature. And it's these, including these messages is the actual, sorry, if I drop this guy and this guy, then I have a Schnorr signature. These are the ones that include this message point multiplied by something, give me something new. I compute the actual sort of signature scalar exactly the same way as the Schnorr signatures, which, admittedly I didn't tell you about, but the, okay, and this, the resulting thing, and there's this, the verification looks very much like a Schnorr signature. So I don't want to go too much into why this works or anything, but the the point is that it's actually blazingly fast compared to both BLS and the RSA with a full domain hash. So it's probably in practice if you want to use, most of the time if you want to VRF it's actually what you want to do. And there's a few implementations. It's used in DNS SEC to sort of to prevent basically to be able to sort of, yeah, so it's used to hmm, actually I can't describe how it's used there very well off the cuff. Anyway, so Trevor Perron has an implementation, I'm not, which I think it's used in Signal somewhere, and I have one that we use at work for some things in this library called Schnorr Coal. Okay, now I promise something about proof of stake, so I have to say something about how you would actually use one of these VRFs. So the main thing that I didn't okay, so I didn't tell you too much about the security assumptions for using one of these things, but one of the, okay, we have this message and we're hashing it to we're hashing it to the curve and then we're doing something by multiplying it by a secret key. But one of the things that I want out of this is that I want the result of the, okay, so, sorry, back up a second. So if I want the, if I, one of the ways I might use this thing is I might use the VRF output to determine when I should make a block in some blockchain. Like, so instead of having proof of work what I do is I actually say, okay, let's look at this VRF output and decide if it's my turn or not. So what I want, one of the things I have to worry about there is whether the is whether the person who makes up the key gets to gets to bias it somehow. So for example what they can do is if the message is just block height you know, just the numbers and that's the block height and I get to see if it's me or not and then what will happen is the users can just, they can go back and do proof of work again. They can try and guess public public, guess private keys until they get an answer that has them making a lot of blocks in the near future and then do whatever they're going to and then make a bunch of blocks and then go away. So that's not really cool. So we have to, we have to prevent that somehow. So what we need is we need in this message that goes into the VRF, we need some sort of randomness and so this is a thing called an Auroboros. It's from ancient mythology and there's a bunch of papers labeled after this but the basic idea and the idea existed before this, these papers was that you can take a bunch of these VRF outputs that are coming from people making blocks and you hash them all together and you take a bunch of them and in one epoch you hash them all together and you use that as randomness in the next epoch. And so proving that secure is kind of hard and questionable but it's well actually not that question, sorry. So there's a number of things there that are quite, that are kind of tricky but the general idea that what we're going to do is if we have a number of participants in the network and they, the different parties are producing these private sources of randomness and then proving they're correct then when we combine these all together with a hash then we get something that nobody should actually have been able to foresee. And there's other constructions so sometimes people, there's some constructions that do threshold VRFs and other things like this but okay. So yeah, I'm going to stop there and just ask some people, or welcome to ask questions about sort of how these the different schemes play together and things like this. Alright, thank you Jeff. Big applause. So if you have any questions please come forward to the microphone. Alright. Well looks like each and every one of them is ready to kill proof of work. So, alright. Thank you all, thank you for coming here and hope you enjoyed the talk. We have a short break and half past sixish we will come here back with new content new fresh content for you and so long. Stay well hydrated, enjoy enjoy the nice weather and see you later.