 Good good morning real-world crypto. I'm excited to be here Kicking off the final day of what's always my my favorite event of the year So I'm going to be talking about the the noise protocol framework. Let me introduce myself first. I'm Trevor parent I do consulting on applied cryptography and protocol design and I'm gonna be talking about a Project that I've been working on in the last few years in this area. It's called the noise protocol framework It's a a framework that helps you in creating secure channel protocols By secure channel protocols, I mean things like TLS or SSH and IP sec Two-party protocols where both parties are online at the same time and they want to authenticate each other and agree on some shared secret keys For encrypting their communication. So This is a simple but important class of Protocols these are the workhorses of practical cryptography Most of the time when encryption is being used on the internet or probably anywhere It's within the context of some secure channel protocol. There's other types of protocols Of course, there's cryptocurrency or secure messaging where you might have multiple parties more than to communicating some of them offline at the same time Those are more complicated things. So we're gonna be the noise framework sort of restricts itself to just looking at this relatively simple case of Two-party online secure channel protocols. That's what I'm gonna be be focusing on today and You might be asking actually, why would we do this because we have Secure channel protocols. We have TLS. We have SSH. We have IP sec They were a lot of effort to build over over many many years You might ask why would we want to start down this road again and start building new new protocols from scratch You might also ask what is a protocol framework? Even if we wanted to build new protocols, why would we be? Why do you need a new framework for doing that? And let me just kind of tackle those questions off the bat I think we're gonna I think we're not done with secure channel protocols We haven't reached like a final state of perfection. We're gonna continue wanting to put more crypto new features New forms of resilience against more advanced attacks new sorts of optimizations for specialized use cases around smaller footprints Earlier encryption less compute time So I think we're gonna continue wanting to put more and more features and Optimizations and capabilities into our toolbox of secure channel protocols But at the same time what a lot of people want in specific cases is More simplicity and so there's a real tension that kind of arises here if you're trying to build a single general protocol in that provides all these things because you know the more features and capabilities we stuff into a protocol the less simple it becomes and as it becomes less Simple it becomes more dangerous because if you're carrying around Features and options in the gavic navigation negotiation for things. You're not using There's just a lot more risk than an attacker could negotiate through all that find some bug You know, that's a security bug. So trying to combine Deal with this tension is hard if we're just building one protocol because you're gonna build a protocol We're gonna put in a bunch of features It's gonna be not enough for a lot of use cases But it's gonna be too many for many other use cases and so that's the tension We're gonna try to sort of resolve by thinking about protocol frameworks and the idea behind a framework for for protocols that you have a small set of layers and elements they combine in a very structured and easy to understand a way to give you a large space of potential protocols that a Systems designer can choose from to give them something very specific So we're trying to manage this tension by giving you a large space of sort of possibilities You choose at design time, but the capability of very very simple specialized implementations And so that means interacting with a protocol framework like this is going to be very different from dealing with kind of a single Packaged full-featured protocol like TLS where you can just point two libraries to get at each other And they'll probably figure out how to communicate they'll do fallbacks and negotiations and retries and figure out the subset of features They support and you know, that's an impressive feat of engineering if you're a web browser and you need to support the last 10 years of web servers on the internet you you might need to do things like that, but There's a lot of use cases for secure channel protocols that are not web browsers and would probably be better served In my opinion by having you know, maybe more specialized protocols that do kind of exactly what you want nothing more than that even if that requires some more Effort upfront at design time to think about what you want and understand what exactly you're getting out of this framework. So that's The sort of framework goal of of this noise thing That's not really the goal. We started with the goal that We started with in building this framework was actually to do something kind of different Which was to explore the idea of just building protocols out of using a single public key primitive out of using the Diffie helman function in my opinion the best public key primitive and the You know, the reason we want to do this is because it's just a little different from The mainstream Secure channel aka protocols which mostly use Diffie helman just for key agreement and use signatures for authentication but in the last several years there's been some growing attention to just trying to build everything more minimally out of Diffie helman itself and it kind of looks a little bit like this you could look at a conventional kind of mainstream Authenticated key agreement and an aka protocol just is like the core of most secure channel protocols It's the part that agrees on the key and does the authentication. So a traditional aka protocol You know, this is this kind of like Sigma or kind of like tails 1.3 This has the party send a Diffie helman ephemeral public key back and forth Bob will authenticate himself by sending a signature over everything previous that's encrypted Alice will authenticate herself the same way the Signature key is kind of agreeing to the shared secret key by signing everything and the shared secret key is kind of agreeing with the Signature key by encrypting its signatures and so everything agrees with everything else. This is a good protocol It's a good way of doing things, but we could do things differently We could instead of sending signatures send max Calculated in the same way over the transcript, but where the Mac key is taken by these Diffie helman Outputs that serve to authenticate the parties and so, you know, I'm writing here Kind of a weird notation to describe these different Diffie helman outputs that are going to end up in our protocol I'm saying the ee output is going to be like the ephemeral to ephemeral dh ES and se are going to be ephemeral static dh's Let me try to make that notation a little bit more clear because I think it's going to be helpful for a lot of things I do later on if we imagine that there's Alice and Bob They each have a static and an ephemeral Diffie helman key pair Then we could imagine there's four possible dh operations they can do and we can label them just by reading left to right From Alice to Bob. So there's a an ephemeral to ephemeral dh they could do that You know is going to give them forward secrecy because they can throw away the ephemeral private keys after the dh and then you can't compromise their static keys and get that ee key back again the Ephemeral static dh's are going to serve for authentication because if Alice chooses an ephemeral Does a dh with Bob static? She's going to know that Bob's the only other person who could calculate that key if Bob uses that key in any way to Produce a Mac or something like that Alice knows that she's talking to Bob So this is going to be our notation to describe different dh operations in this context So if we go back to this we can kind of see what's going on a little bit better. This Mac 1 is using Bob's ES off dh that authenticates him Alice's Mac 2 is using the se dh that authenticates her so we have a sort of like dh-based version of a Sigma like protocol And there's some nice things to doing things to kind of translating protocols into this style Without signatures, we have less code. We don't have to implement signatures. We have smaller messages. We don't have to send signatures If we want to do zero round-trip encryption It becomes very easy because if the parties have static Divi helman keys, which you can just encrypt directly to and kind of an easy IES style without having to Do pre-shared keys and resumption and tickets and all that which you would have to do if the parties only had had signature keys And these sort of protocols will probably have better deniability than doing signature-based protocols because you're not Signing things in a way that's third-party verifiable So this this sort of protocol is the style protocols is well known You know the the kula Patterson papers where I sort of first ran into it But there's Naxos the Naxos paper in Goldberg's and tour he go crowd shakes opt he less proposal for TLS And these things have made their way into practice. There's again and tour used by a tour of Fort circuit handshake There's a number of dh-based protocols by Dan Bernstein and team like salt curve CP DNS curve and these are all really elegant designs But you know when I was looking at them a few years ago It struck me that every time someone builds a protocol in this style They sort of after to start from scratch and they they design their own transcript hashing and key derivation and message format And if they're doing security proofs, they'll Specify a unique security model and do their own gap DH wrong proof It's similar to everyone else's gap DH wrong proof, but still a lot of work So the idea that kind of gave rise to noise was to try to create a framework and a set of elements So you could build protocols in this style without repeating all this work and just by moving the Diffie Helmens around get a wide range of protocols So sort of trying to work on that in 2013 or 2014 I talked to Mike Hamburg Around that time and took some ideas that would later of his ideas that will later give rise to the strobe protocol framework of sort of Viewing symmetric cryptography is kind of a sequence of sponge-like accumulation steps I think that Lends itself well to this style of protocol and I'll explain a little bit more what I mean by that in a second, but With that idea we were able to do I think come up with a really nice language and framework for for building a range of protocols like this and You know in the last few years you've kind of built a small community around that that framework We've got a mailing list websites specifications a bunch of open source libraries for common Languages, and we've got even some users. So WhatsApp has deployed noise-based protocol for client server communications since first quarter of 2016 the wire guard Next-generation VPN tunnel by Jason Donafeld is a very nice piece of VPN software and protocol that's it's getting a lot of attention recently and we're getting interest from a few other Directions things like low and embedded internet of things systems back-end kind of data center systems for efficient encryption between computers you control and some more far afield things like cryptocurrency The lightning network proposal for Bitcoin incorporates a noise-based protocol and a number of anonymity network proposals are investigating noise-based protocols so kind of where we've got to at this point we have a sort of stable core protocol and Then a bunch of extensions were considering but we at least you have kind of a part of it It's pretty stable and constant since 2015 that we've got a fair amount of a certain amount of adoption form So that's a little bit about the history of the project and some of the goals of wanting to build a framework for DH base protocols now we're just going to kind of dive into it and Look at what goes into a secure channel protocol and try to break all those elements out into set of Reconvindable components that we can put together in ways to create a lot of different protocols so the components of a of a secure channel protocol are You know it's kind of two main phases There's a handshake phase where you send a few messages back and forth to authenticate and do key agreement There's a transport phase where you use the agreed upon key just to send in crypto traffic Using an agreed a shared secret key to send in crypto traffic is fairly easy So we're not going to say much more about it. We're really going to focus on what happens during the handshake and what happens during the handshake is primarily this authenticated key exchange, so a Protocol similar to this type of protocol I showed you before where you send two or three messages back and forth You do some authentication you get some shared secret key That's the heart of all these protocols, but there may also be some negotiation the parties might have to Agree on the parameters that are going to go into all these subsequent phases And so that could mean deciding the exact a ke algorithm deciding what types of keys to use Deciding what type of cypher to use for the transport phase and so on so You can think of negotiation happening sort of logically prior to everything else and determining the parameters everything else though in practice to Optimize round trips Negotiation is often sort of interwoven with the a ke so the first message the client sends might be an initial kind of Speculative a ke message combined with some negotiation data that says I'm trying to do this But I'm willing to do other things tell me if you'd like to do something different so there's a Kind of combination of these these protocol flows in practical a ke ask your channel protocols So if we want to take this this set of concepts and break it down into elements The first thing we're going to do is we're going to separate out the negotiation From everything that happens after that and the reason why is because negotiation is the the worst thing that happens in these types of Protocols because it involves making decisions based on talking to other people and that's a very risky thing to do in a crypto protocol We have to talk to people because we're a protocol, but we don't have to necessarily make decisions based on that Unless we're doing negotiation Making decisions is dangerous. It involves Parsing things that people give you and parsers have bugs it involves creating a state machine and having logic around what people give you and that's a source of bugs It involves conditional branching and processors, which is super dangerous these days So there's a lot of reasons we we don't want to make decisions at all in our important critical crypto code So what we're going to do is going to say everything after negotiation is going to be sort of just Decision-free and we'll call it a noise protocol and have this notion of a linear noise protocol That just executes one a ke does transport phase encryption and it's just one packaged thing with the state machine that looks like This it's a good state machine because it doesn't do anything. It just advances We can't quite get exactly that simple because bad things might happen And we're gonna have to abort the protocol when a Mac fails or something like that But this is kind of where we want to get to in our crypto In our crypto design in our implementations. This is easy to test. It's easy to think about and so on So and we get there by separating out negotiation and saying, okay, let's have a single point where decision gets made It's gonna be We're gonna only allow the server to make like one decision and the decision is gonna be I could Accept the client's initial noise protocol or I could switch to a different noise protocol So we're gonna try to condense everything down to one decision So we can just really try to limit the damage of decision-making in general and just allow it to be Transitioning from one thing to another and that will allow us to express Common protocol patterns such as the client saying I support two ciphers represented by two noise protocols And the server can choose one which one to use the client could say I'm trying to do zero roundtrip encryption to you based on what I think is your current key If you're not able to decrypt this message the server will say, okay, let's switch to a different thing Let's switch to a slower handshake so we can express zero roundtrip or basic negotiation things This is a very restricted form of negotiation, but these are this is a simple class of protocol That's mostly all we we need to do to do secure channels So once we've kind of pushed negotiation off the side We're gonna just focus the rest of our effort and really this is what then the noise project is mostly focused Except Ron is just designing these noise protocols these linear straight line Very simple protocols that could be used by themselves or with a bit of negotiation And so if we take this linear notion of a noise protocol, we're gonna break it down into further elements By separating out the the kind of abstract notion of what a handshake is a handshake pattern Is what we'll call that and then we can kind of separate that from the crypto We plug into it so we can plug, you know, public key crypto into it symmetric crypto into this abstract Handshake pattern to get a concrete noise protocol as a as a user of this framework You'll interact with this just by naming it so you there's names for handshake patterns There's names for crypto algorithms. You can catnate these names together and the spec tells you How to kind of compile that into a concrete noise Protocol and it's it's mostly, you know some parts of this are pretty easy to understand like you're plugging in a dh You're plugging in the cypher you use for encryption There's a couple parts I'm going to just expand on a little bit more and one of those is how we use the hash function to provide complicated features such as Transcript hashing and key derivation. The other thing is is the pattern so The hash function is going to be used to construct kind of like the stateful sponge like strobe like object that we're then just going to feed all of our inputs into and ask it to Encrypt things and this is just going to kind of take care of all of the the transcript hashing and key derivation that Can be a complicated part of these protocols if you try to be really fussy about it and only hash the exact things You need and so on and hash the exact nonsense or sign the exact nonsense you need but if you take kind of just an expansive view like Is probably the modern trend in protocols and just kind of hash everything together and just encrypt everything based on everything previous That's happened then it actually becomes kind of easy just to do all your symmetric crypto and hashing and we can sort of ignore that and Then just think about the kind of patterns that we want to build on top of that And so the patterns are that we're going to express is in a simple language based again just on this ability to We're gonna have a language that expresses protocols It can only do two things that can send to public keys and can do Diffie Helman operations And now we can just build a bunch of protocols on top of the symmetric crypto stuff kind of like this I'm gonna just run through a few examples a pattern like this describes public key encryption or ECI ES encryption We use this stuff before the three dots to indicate knowledge Alice has knowledge Either party has before the protocol run starts and then we describe the protocol so Alice knows Bob's public key She sends an ephemeral key. She does ephemeral static sort of chem dem style DH and then has a key that she uses for transport phase encryption of stuff This is encryption if we want to add authentication onto this We just throw in a static static DH now Alice is authenticating herself to Bob in a single message If she needs to tell Bob who she is she can send her public key And this is just going to be getting cryptid because it's fed through this symmetric Crypto object thing which already has this encryption key in it If we move to interactive protocols we can this is an unauthenticated Diffie Helman we express like this We add server authentication By just having the servers send it static public key if the client knows the service that a public key It doesn't have to send it and in that case we could even do something fancier We could do zero round-trip encryption in the first flow by just moving the ES DH to there We could also do zero round-trip authentication in the first flow, you know again by just throwing in an SS But in in the case that that the server static might have been compromised We'd want to refresh that with a fresh authentication So add an SE in the next flow. This is very similar to the wire guard pattern except wire guard adds an additional Pre-shared symmetric key that can give you some post quantum resistance if you manage to share that Pre-shared key in some other way so this shows how you can kind of just build up a bunch of complicated things by moving simple elements around And we can kind of extend this to different types of crypto like pre-shared keys We could even go back and throw and translate this back into doing signature based aka ease or Try to add post quantum comes into here. So I think we have a framework that is hopefully extensible Ends up looking kind of like this and I'd love to get other people showing up to help us kind of build it out extend it Help prove things about it and implement it or find use cases for it So thank you for listening and I don't know but I'd love to take questions if I have time for it Thank you very much. We do have time for questions. I Have not so many I mean I have questions for you too, but I wanted to make some comments First of all, I think it's a great work This modularity is something that is very welcome and very well thought on the other hand one has to be careful about Random combinations not not all combinations are equally secured. So But but overall, I think the modularity is great In particular, I want to I mean I want to Support this type of protocols that are based only on the field man. They have many many advantages They are simpler than those that combine signatures. They don't require just another primitive of signatures They are great for post quantum because you can build them with came them without post quantum signatures at all One main reason we I think we don't have that as a TLS 1.3 is that we don't have certificates for the field man keys and You know, I would like to see more movement towards having these certificates because then we will have these These better protocols and finally some self-promotion This protocol Ike version one has a public key mode of operation which is exactly these These protocol called scheme But that's exactly that. So it's more than 10 15 years. Oh, yeah, it's more like 10 plus 15 years so anyway Good work. Thank you. Yeah. Yeah, I mean Thank you. Yeah, and those are a bunch of good points in particular that there are certainly ways we could combine those tokens and move them around that would be bad ways so The way we kind of deliver this user with name sets of patterns and the patterns have to meet certain validity roles But there is some care that needs to be taken there Yeah, and certainly this is is similar to scheme scheme was kind of framed more around a public key encryption than just DH But I think you're definitely right. This is like a lineage of things that goes way back To like protocol for by Blake Wilson and other people. So this is a style of protocol. It's been around for a long time Super cool work. Thank you. I heard about this cool ratcheting idea that someone came up with Have you considered putting a sort of post-compromise forward? future secrecy ideas into noise protocols where you overlaid if you have any values in there You know, we haven't looked at that too much for this It does have we've kind of specified an ability to do like a symmetric key rekey thing where you just kind of Replace your symmetric key with some of its own output so you can just kind of roll forward and get some very lightweight Forward secrecy. I mean, I think these protocols tend to assume that you're online at the same time So if you needed to renegotiate and want it to kind of refresh your forward secrecy, you could just do another handshake Which is what something like wire guard does is just handshake every few minutes So, you know, we haven't thought about really trying to like merge all that stuff together I think it's kind of nice that these are simple and just address the online case Thank you Okay, let's thank the speaker again