 Does this work? Yeah. Oh, there we go. Great. So thank you very much. Thanks to the organizers more generally and actually before we get Started, I just want to highlight a few excellent people that Dan and I have been working with in and around the IETF So there are the other authors of the BLS signatures and hash to curve drafts And there are plenty of people who have given very careful and very useful feedback And if I've forgotten anyone, I'm very sorry. Thank you too. So let's start We've seen this a couple times, but maybe We'll think about it one more time. Why are we standardizing things? So one obvious thing is well, we want to be able to interoperate So if I tell you I'm going to be using HmaxShot256 and I send you a Mac tag You're going to be able to you know understand what it means and verify it And this means that we want to be sort of detail-oriented and precise about you know, how things are specified But that feels almost Like a like a bother like a cost whereas maybe we should be thinking about this in terms of an opportunity Like we can do careful thinking up front and we can make sure that things are secure and efficient So that you know there aren't these problems later So let's think about a specific example just to see the kind of thinking that maybe we want to do and why maybe those things tend to get missed so let's think about the invalid curve attack So this was described at Crypto 2000, Beelmeier and Muller And so here's some cartoon protocol, right? I'm going to send you an elliptic curve point and you're going to take your secret scaler Multiply it by the curve point and send me back the result But the problem is your software was badly written and it doesn't bother to check that the point is on the curve So the result is that I can sneak a lower-order point to you and you will send me back the the your Essentially your scaler mod some small value and then since discrete log is easy mod small values I'll be able to figure out your points. So if we interact in a you know a dozen times. It's game over. I have your your secret so this actually happens for real and things like blind signatures OPRFs and Actually even in key exchanges we can get something very close to this and so the question is something like okay Why why is this happening? Well, there are a couple things that come to mind So first when we think about protocols in general, we tend to think like you know in a crypto paper We think about mathematical objects, right? I told you I'm sending you an elliptic curve point But in some sense that doesn't make any sense right what I'm really going to send you is a string of bytes And then you have to interpret that as a point on a curve, right? And that interpretation is prone to error. Why? Well, we have some in some sense Ambient knowledge right all around us there are these attacks and we know that they're there But we ignore them because look there's only so much room in the background section of the paper, right? So you don't write it down every attack you just say of course well There are other attacks, okay, but when we actually write a standard We need to sort of distill that ambient knowledge into concrete statements on the page like check this point this sort of thing Okay, so this is Again, maybe this feels like a bother But actually maybe what we should call it is polite crypto with apologies to Dijkstra so the idea is something like let's this look if I can spend an hour and Make sure that you know you don't have to you know read the standard ten times and maybe go off to ten other documents Or maybe I save you from writing bad software. That's definitely a worthwhile trade-off Okay, and in some sense we should regard that as like a statement of like an optimistic statement, right? Like of course a hundred people are going to read this document or maybe even a thousand right and so of course It's worthwhile to spend an hour on this, right? So let's let's be polite in our standards, okay? And okay, so finally one maybe one more reason maybe this only applies to me to standardize things is We have to be pragmatic about it and look I have a tendency I'm writing software Oh, there's a little knob that I could add a little dial that I could add that would give us You know 2% more efficiency in this case Well, the problem is every one of these knobs has a correct setting that gives us 2% more efficiency And then it has a hundred incorrect settings that gives us you know sort of a hundred percent overhead, right? The users don't want that they want a sort of a reasonable set of defaults and And you know make some decisions for them So this is a good thing in the sense that you have to make decisions But it's a bad thing and that you have to make the right ones, okay? So that's enough philosophy So let's talk a little bit about what it is to standardize crypto with the ITF and then at the end I'll give you maybe last half. I'll give you sort of specific Information about what we're doing with BLS signatures and has to curve and things like this, okay? So the ITF is sort of this fascinating organization And I say this sort of as an outsider. It's almost like a It's like a testament to the power of almost constrained chaos and that's a loving statement Like if you go to an ITF meeting, there's something like very impressive about it There's a lot of work going on there people that were excited and there's just a lot of people who are very good at what they do So the unofficial motto that they have kind of reflects this Anyone can go to an ITF meeting and you don't have to be a member anything You just go you show up and you shout into the microphone because you've got a problem and maybe they listen to you But maybe they don't because not everyone has to agree. It's only rough consensus and the running code part Maybe we can interpret it a bit broadly. I mean something like this Look, the stuff is made to be used. So it's our responsibility to make it usable Okay, so how about crypto? Well the CFRG is sort of the research group within the ITF Whose job is to sort of consult on security matters and also to standardize kind of new crypto And since what we're here to talk about today is advanced crypto I'm gonna ignore like the other routes that you might take to standardizing crypto So for example, the TLS working group doesn't fall under the CFRG. They do their own thing But but you know, that's sort of more that's not the advanced stuff. So we're gonna ignore that So the standards that the CFRG publishes. Well, they're not actually standards. They're called informational RFCs RFC is request for commentary RFC 793 is TCP. So like lots of things are RFC RFCs and informational ones aren't standards per se but things like TLS can incorporate informational RFCs Into, you know, the documents. So for example, the curve 25419 RFC is incorporated into TLS 1.3 It's an official thing even though it's only an informational RFC So, you know, don't don't be disheartened. You should write informational RFCs And finally a lot of the business in the CFRG is transacted on the mailing list You know, if you have fond memories of like the the news group PsyCrypt from 25 years ago Then this will be very familiar except probably they're a bit more polite on the CFRG mailing list Than they were on PsyCrypt So it's a good first step to, you know, jump on in and sort of acculturate yourself on the mailing list and get an idea of How things are going. Okay. So what is it like to write a draft? Well, the official process is documented in an RFC and For research groups like the CFRG basically there are four steps written in the official document prepare a draft review it a few times and then publish it and so like really the CFRG is responsible for the technical content The IRTF is sort of there to make sure that competent implementers who aren't Experts in the area can parse the document the IESG is there to make sure you're not stepping on any toes So for example, if you really want to you know, standardize a new kind of DNS The CFRG isn't the right place for that And so the IESG is going to tell you no and then finally the RFC editor is doing copy editing They do an excellent job, but they're very hard or very overworked. So nice to them, please Okay, that's the official view of the world But it all of the work that you will do if you write a standard is hidden in step one So let's zoom in a little bit So the first thing that you should do if you're going to standardize something at the IETF is Make sure you should be standardizing something at the IETF in particular Like identify some people who actually want to use the thing that you want to standardize and talk to them about it also talk to the CFRG chairs maybe other people in the CFRG and Kind of get an idea look there's a consensus that we need this thing and that we should be the we should be writing down a standard for it So once you've got that idea in in your head, then it's time to write an individual draft So this is like the first draft of the standard And you know, it's not going to be perfect. That's okay It can have to do spread all over the place totally fine The idea is to give people a notion of what it's going to eventually look like So that now people on the CFRG and you know your users that you've identified can give you feedback like well What we really need is this other functionality that's not covered here. That's the kind of feedback you want Once you've gotten to the point where oh, I should mention before I continue When you write an rfc the the official format is this horrific xml thing you don't want to write that by hand It's it's a total nightmare. Um the the workflow probably will feel a little primitive if you're coming from tech You know, it's getting better nowadays you can use markdown and sort of automatically transform things There there's a github workflow I totally recommend that because it's really nice to be able to get you know feedback from people via issues and pull requests and this sort of thing Okay, so now we have an individual draft people are basically okay with it So it's time to call for adoption So now the CFRG says yes This is a thing that we're going to work on sort of as a group and at this point It becomes a working document in the CFRG and people on the mailing list are going to you know volunteer to read your document To give you feedback that sort of thing. Okay, so now at this point This is where you're really going to get the get the document in shape. So you're going to edit it You're going to implement most likely a reference implementation of it And probably you'll go to at least one ietf meeting and give a presentation. They're short five or ten minutes There's a lot of interaction people come up to the microphone. You know, it's kind of a fun interesting atmosphere This is where all the work is getting done. And so it's kind of nice to go At some point you're going to say look, this is it. We're done Then there'll be a last call which is sort of a speak now or forever hold your piece Once that's done, then we you know, we go to those other steps that You know that we're in the last slide. So the irtf, etc. Okay, so how long does all this take? Well Um an example is the curve two five of a nine rfc, which took about a year end to end So from the first individual draft that got uploaded to rfc editor releasing the document was you know I don't know within 30 days of one year And there were in that time there were about 12 drafts Most of them were small edits, but you know, there was sort of a bunch of editing process going on And if you look in the data tracker dot ietf.org they give you sort of all the information about the history of documents And so what's interesting here is um irtf and iesg Basically takes zero time and the reason for this is they're They don't just happen sort of in series Everyone is sort of paying attention to documents as they go through the process And so you'll already have gotten some feedback from you know, for example, if you're trying to standardize dns under the cfrg The rfc editor queue unfortunately, it takes a little while that's because like I said, they're a little overworked But you know, they do very high quality work. So work with them So the drafts that we're working on BLS and hash to curve BLS has been in progress for about six months Hash to curve is more like a year and a half We'll see why I think a little bit later But the the high level reason is Hash to curve is more like a toolbox than a than a protocol and the result is you know, we get pulled in a lot of different directions Okay, so I want to jump into these two standards But first there's one more maybe slightly unpleasant thing to talk about and that's patents So you might guess that there's an rfc for that and there is And here's the idea if you're gonna if you're gonna standardize something with the itf And you own a patent on it or your employer does then you must disclose that If you know of a patent, but you don't own it Still it would be nice if you disclosed it though. You're not formally required to And so once once any kind of intellectual property issues have been identified The cfrg chairs and the itf administration will go to the company that owns the patents And they'll say hey, can you please promise that anyone who implements the standard will you know have some fair reasonable and non-discriminatory terms Under which they'll be licensed The problem with this. I mean that's that's great But there is this issue that i'm nothing like a patent lawyer But my understanding is that the words fair reasonable and non-discriminatory can be interpreted very broadly And so understandably there's a lot of you know trepidation when something that's patented gets standardized And as a result basically the itf security area that's not the cfrg That's things like the tls working group and the ipsec working group They have essentially a policy that they won't Require anyone to implement things that are encumbered by royalties So if I have to pay a royalty to implement this thing it will at best be optional There are other ways that even if it's patented maybe it's okay So reasonable and non-discriminatory with zero licensing ran z That's okay Even better is if the owner sort of says we promise we won't patent But really from everyone's perspective in terms of standardizing The the best ones are the ones that don't have any patents associated. So in short If you want your work to be used It probably it's best not to patent it Because people will be nervous and you know rightfully so even if right now everyone is happy with the You know with the way that the patents are being treated, you know in five years They can get sold to somebody who will act very differently Okay, so Let's take a deeper look at the specific stuff that we've been working on with bls signatures and hash to curve And i'm just going to sort of review the technical content But then along the way sort of point out little things where you know The stuff that you write in section two differs from the stuff that you write in The standard, okay, so um the bls signatures draft Is you know it's one document and it needs pairing friendly curves So it's going to rely on a separate document that that defines pairing friendly curves And that's also currently being worked on Um, it also relies on hashing to curves So it depends on that document and in fact hash to curve defines hashes to pairing friendly curves So it depends on pairing friendly curves And then there are a few other documents that I think right now don't actually depend on hash to curve But at some point in the near future may Depend so you end up we ended up with these sort of interesting dependency graphs This is I would say not unusual it's frequently the case that Documents depend heavily on other rfcs and that's kind of a good thing It means you're going to be interacting a lot with those people And it means that you don't have to you know write down everything that that your protocol needs because probably it's already been standardized somewhere else Okay, so topologically sorting we'll start with pairing friendly curves and go from there So just very generally as a reminder so pairing friendly curve defines Sort of two groups g1 and g2 both of the same prime order q that are subgroups of some elliptic curves And we'll say that we are generators p1p2 and then there's a third group the target group of prime order q as well And of course there's the pairing operation So the idea is it's a bilinear map from g1 cross g2 to gt And you know very intuitively what's going on is the bilinear map multiplies the exponents of its arguments So as we'll see this is very useful So this is you know sort of the background section version of it But let's think about what else do we need to write down if we're actually going to make a standard for this Well, presumably one thing that we want is we again, we don't want to be talking about mathematical objects We want to be talking about bytes on the wire eventually So we probably need to define serialization and deserialization And you'll notice that the pairing operation it takes points in the subgroups not points on the curve generally So probably we have to tell people look if there's a fast way to do a subgroup check You're going to have to do subgroup checks So we may as well standardize the ones that are good or fast or at least point you to them, right? and probably Maybe this surprisingly we want to probably put test vectors in the document And you might say well look it would be even better if we just had a reference implementation And that's true and probably you should have a reference implementation But the reason to put a test vector is well If I just I mean just imagine you print out the document and you start writing code And at some point you want to test whether your code is correct It's nice that you can sort of type in a you know a few hundred hex digits And then make sure that your code actually does the right thing No, probably you have to do some spell checking first Okay, so that's enough preparing friendly curves. Let's think about hashing to curves So the way that we're going to define it in the document is in terms of three primitives I think you can see that this will kind of fall out nicely So first we're going to need some family of hash functions from arbitrary strings to field elements And we're going to model them as random oracles Second we're going to need some deterministic map from field elements to points on a curve And there's been a lot of work on this And in fact Dan and I have a paper appearing at chess next week That makes hashing to lots of curves including pairing friendly curves a bit faster So in particular we can basically match the cost of alligator Like one square root in the field for almost any curve Okay, so So that's mapped to curve And of course for any curve with non unity cofactor We're going to want to hash into the prime order subgroup So probably we want to talk about how to clear the cofactor And obviously there's a naive way to do it But it turns out that pairing friendly curves tend to have very big cofactors And so in a lot of cases we want to have some exploit some endomorphism or something like this In order to make the cofactor clearing faster Okay, so there's all of that Now the question is how do we put all this together And there are some very beautiful results from Briar et al And Farshay et al that show basically for all the maps that I've listed here Evaluating the map twice on independent inputs and summing the result Is indifferential from a random oracle assuming that the hash to field is modeled as a random oracle Okay, so This is again sort of background section I'm not going to belabor this point about oh we need to specify this thing and this thing But I want to point out something that actually took a surprising amount of thought So here's the thing Like I said earlier this is kind of more like a toolbox than a protocol, right? So what we want to do is give people who are actually building protocols on top of hash to curve Some you know some dials that they can turn So for example a lot of people are going to want to say well my You know my hash function is orthogonal to your hash function, right? So we need to give them some way of doing domain separation And the the clear easy way to do that is in the hash to field function So but here's the thing Okay, let's think defensively for a second Protocol x is going to you know read the document carefully and they're going to specify a domain separation tag in just the right way And life is going to be good protocol z. Well, they're in a rush They didn't quite get things all right and the result is that now their domain separation tag Let's say is broken So here's the question Can we write the document in such a way that even if protocol z breaks things for themselves? They won't ruin life for protocol x, right? So this is you know the obvious approaches to this are maybe not going to give us that assurance But we want to have that sort of paranoid sort of defensive attitude like not everyone is going to read the document and implement it Correctly. Let's make sure that it doesn't break for the people who did Okay, so the details get a little tedious. I won't talk about them anymore, but the high level message is maybe be paranoid a little bit Okay, and finally The topo sort has led us to bls signatures So just a quick reminder a public key is a point in one of the groups Let's say the public key is in g2 And the secret is the discrete log of the public key to the base point And so to sign a message we're going to hash the message into the opposite group from the public key So in this case, we're going to hash it into g1 and then we're going to you know raise it to the You know to the secret exponent value And then verification checks that the pairing of what the hash of the message with the public key Is equal to the pairing of the signature with the base point and at least maybe I can convince you that it that you know, it's it's correct Security is another question. We'll leave that to the paper But okay in this theory in this theme of pointing out practical issues So here's one I've written down key gen as a randomized algorithm Which is totally fine if we're just specifying it But it's pretty bad if we're talking about you know if we're talking about it again in section two That's fine But in document it's probably not so fine because I don't want to have to tell you for example How to build a random number generator? So maybe instead what I should do is make key gen deterministic and have it take in some randomness And then I specify to you well it needs to be 32 bytes and please make it high quality and see this other document for You know for details on that And then uh, you know and again this issue we don't want to talk about points We want to talk about strings of bytes So probably we have to rewrite this interface in terms of serialized strings of bytes De-serialize the string of bytes make sure that it's on the curve make sure that it's in the correct subgroup this sort of thing Okay, but the real reason that people are thinking today about standardizing BLS signatures is because they're aggregatable Um, and so here's the idea so to aggregate signatures And we we can sort of you know squash all the points together into one point So we take the let's say the product of all the signatures give me a point to g1 And that's the aggregated signature and then there are kind of two things that I can do with that First I can check a multi signature. So that is you know, many public keys all signing the same message And that's that's kind of fast what I can do there is I can aggregate all the public keys together and then Use the verification equation And the other approach is is maybe we can think about as a batch signature So in this case we have one aggregated signature But we have a bunch of different messages and public keys paired together And we want to check that sort of the the aggregated signature corresponds to all of the message public key pairs And there well, it's a little more expensive because now I have to do sort of n pairing operations rather than n point additions But um, so it still saves us kind of a factor of two in in terms of computation over the naive approach And also it squashes the signature down Okay, but so um, here's a question. Is this secure? And uh, no, I'll give you a yeah, no So there's this nice idea called a rogue key attack So let's let's imagine that alice has some public key and bob has some public key And then mallory comes along and and creates a public key that's specifically designed to allow him to Forge signatures that look like they're from alice bob and mallory Okay, so in particular he's going to engineer his key so that it kind of cancels out alices and bob's key And then um, if we go back to the the multi-signature verification Equation what we see is look as long as mallory can sort of cancel out alices and bob's keys Then he can forge a multi-signature for any message. Okay, so how do we defend against this? Well, there are kind of four Four ways of doing it in the literature One is that we can we we require all messages to be uh unique The downside there is well, we can't do a multi-signature verification anymore So verification gets a little maybe a little slower because we can only sort of get the batch improvement Another approach is message augmentation. So here we just prepend the public key to the message before signing Which essentially you can think about that as ensuring uniqueness, but once again, we lose the multi-signature thing One way one way that we can keep the multi signatures is using what are called proofs of possession So here we ask the the Everyone who generates a public key to also prove that they know the secret corresponding to it how well they just sign their public key And intuitively what what's going on is now if you've engineered a key to cancel out someone else's key Well, unless you've broken their key, you can't you don't know the secret corresponding to your own claimed key So now this is a little complicated right because it means you have to generate proofs of possession And I have to verify them But the the signatures are deterministic so you only have to generate the proof of possession once And obviously I can sort of cash my decisions right if I've checked your key before I don't have to check it again And finally, there's sort of the most recent Work in this area is Using sort of a random linear combination of the keys and the signatures And the idea here is you know, even if the messages are the same We can sort of orthogonalize the signatures to make sure that there's none of this sort of rogue key issue So this ends up requiring a sort of a multi-exponentiation to do the aggregation, which is maybe a little bit of a disadvantage But but the advantages that we sort of recover without proofs of possession We recover sort of the sort of only one pairing in order to check a signature So in the standard right now We're going to standardize it seems like we're going to standardize the first three of these and you might say Wait a second that doesn't make any sense because look message augmentation already gives you unique messages Why do you need to have the unique messages one and the message augmentation one? And the answer is again because we're being paranoid. So here's the here's the worry Somebody is going to look at the standard and say Message augmentation seems like a problem proof of possession seems like a problem. Okay. Here's what I'm going to do I'm just going to pretend that I'm using proof of possession, but I'm not actually going to generate any proofs of possession Okay, so what we don't want is for somebody who is honestly and correctly using proofs of possession To get confused and interpret those signatures as actual correct proof of possession signatures So we have a sort of a domain separation between the unique message and the proof of possession case and actually Among all three and that way at least we build a fire firewall between the people who sort of maybe May or may not do things right and the people who really we hope are doing things right Okay, so I think I'm running out of time. So let's briefly recap. So I've hit this over and over again, but it's worthwhile to think about making things hard to break But also it's worthwhile to assume that people will break them anyway. So maybe build in some extra firewalls here and there Implement implement your stuff If other people are going to implement your standard Probably you should be your own first customer because certainly if you can't understand it then they won't either So it's nice to implement and give people at least a reference implementation And what I've sort of become What I've sort of realized more and more as I've interacted with with folks is Any decision that you make is going to make someone unhappy, right? Somebody's going to want that last 3% of performance or somebody's going to say you're crazy. There's a much better way of writing this down You can't take it personally, but certainly you can take their feedback and say thank you for the parts of it That are useful and finally, I hope I've convinced you that maybe the itf is kind of a pretty cool place to standardize your crypto And I'm happy to take more To take questions now or to talk about that more offline