Bestand wählen
Merken

The Noise Protocol Framework

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
that was the name
of the and
the the so the next so could be from 2 repairing he has been called the wait for it leading evangelist in cryptographic protocol modernization and he of that design some of the protocols achieve your phone right now i is executing as ascending to that the period up like signal which awarded which gave him the word of the live Ching prize and the noise radical framework which is used by what's up for client server communication and why God they again from dissonance field which I don't see around here anyways the talk will focus about their noise radical framework what is the rationale behind it and how to use it to press the handle post have you're 1 for being here in this Trevor repair and I do mean a cryptography consulting and secure protocols on our memory talking to you this evening about a uh a project at work on for the last few years of in the field of protocols on which is the noise protocol framework
noise is a adds a framework that helps you in creating a cryptographic secure channel protocol so a this sort of protocol that addresses is white gown things like T a lesser SSH erectus where you have 2 parties their own 1 at the same time for example an Internet client talking to an server they're going to be no 1 to exchange a few messages to authenticate each other and then established and some shared secret keys which they can use for further communication secure Shell protocols like this are the workhorses of practical topography most the time when cryptos users within the context of some sort of secure channel protocol there's other shows the protocols like secure messaging cryptocurrency and and all sorts of other things but noise is specifically focus on secure channel so that's what I'm going to be be talking about in the stock and you know probably a
lot of people just kind of after that have a reaction out of of being liable why we we have a secure job the already we have still as we have SSH yeah like the 2nd these things have been a huge amount of effort to design over the last 20 plus years we've been bolted features onto them and picking bugs out of them while we wanna start down that road again and build different newer protocols I think that's a very legitimate question and answer of skepticism and my uh you
know my my feelings about this is as follows it's that what a secure channel protocol does is really a very simple thing it just sends a couple messages to a 3 maybe 4 sets up a secure channel so these protocols really should be pretty simple it should be simple to implement they should be simple design and I think a lot of the ones that we find ourselves with the mainstream ones are more for what they do for what they actually publish I think they're probably you know often too complicated too complicated and too difficult to extend and I think we need extend them within you to keep your adding features and extending them into areas and would the types of cryptography so support and have a good framework to be ways of doing this I think this is an area where we need a lot of room for improvement and some noise is a i have uh somewhat I guess ambitious effort in that direction is ambitious in the sense that I had been allowed to get to a point where people the use noise for for building all sorts of new and future protocols on the the 1st to admit that it's a it's a work in progress it hasn't achieved all of its ambitions yet achieved some of them by you know we're still working to to send it and if you know of by the end of this talk out than convince people in the next 20 minutes to to try to use noise for all years you protocol design challenges that's going to be OK what I anyone to get across is just something about how these protocols were at the components that go into them the design space there a part of who I think these protocols is so central computer security it's helpful for everyone to understand how they work and what they do and I just think of them as you know kind of black magic that only a few wizards can never touch so to understand
these sorts of Protocols Secure Shell protocols of men wanna start giving you some background on the type of cryptography that's involved in
them In the main cryptographic construct in a secure channel protocol is going to be what typographers call an authenticated key exchange or a AKT protocol in a key is just a sequence of messages they go back and forth between 2 parties between Alice and Bob so they can authenticate each other and then at the end of that have a shared secret key that they know they share with their authenticated parties these protocols is a key protocols can have different properties all the ones we're gonna look at have forward secrecy they might have a mutual authentication of both parties they might have 1 way authentication on how they handle identity information might be different in different eighties so maybe in some making these both parties start off knowing each other's identity in public key in some way he's got to transmit this information another Icke's on they might wanna transmit this information but do it only after the other party has some negotiated some encryption so that the identity information is encrypted is projected on the wire so there's different properties of how these things work there's different types of crypto we can use to design a keys that have these properties and 1 expand on this a little bit because most
taking is that people have experience with the mainstream once all do the acadian uh in kind of the same way we do it k using signatures ratification Diffie-Hellman for for a key agreement but in the last you know let's say 10 or so 10 templates years has been growing interest in doing a case there is purely based on the Diffie-Hellman key agreement without signatures and know there's been a bunch of papers that kind of analyze securely models and approves further the sort of a key that people put this into practice and things like towards the end toward the agreement by Ian Goldberg and a number of designs by BN Bernstein others like salt crypto boxes curves CPU etc. so there's been a kind of interest in doing this and noise is particularly and try to take this idea and run with it so explain a little bit more about how these sorts of Diffie-Hellman century Katie's
work and so will stop looking at just the the key exchange part of an AKT and this is part is going to be sort of generic to all the protocols all the acute KUP protocols and talk about which is just gonna be um In unauthenticated documents you change the way you think about the element is that there's Alice and Bob each other key pair a private key in the public key they're each going to exchange their public key with the others then they're gonna take the public they're gonna take the product the they're going to combine these 2 and get a shared secret which is the same for both parties so that's you know that as a of basic Diffie-Hellman and to add to the agreement to turn into an authenticated the United States thank you change we're going to add
authentication and so we can do that by adding signatures a very conventional way up the same both parties know each other's public keys bodies has to send an signature Alice Alice response intricate signature now we have an 80 in this design is called sigma it's our essentially sigma and it's essentially how something like the last 1 3 works where the 1st get a secret key then send on signatures as authenticators under the encryption and is nothing wrong with this designed to good design so we can kind of look at that schematically by imagining that what's kind happening if we don't consider the message sequences Allison Barber each kind of signed a key agreement so that once again a shared key they know that the other party agrees with the shared key by by verifying the signature if we want to do in a cave that's entirely signature-based wouldn't after place the signatures with some sort of Diffie-Hellman was still getting that same confidence in that same guarantee that the other party agrees on the ultimate final shared secret key we get out of the so the way we can do that is we can say well these these long-lived key pairs of people how will call on static the pairs are going to be Diffie-Hellman key pairs assessing tricky pairs and on each party's going to in addition to doing ephemeral the ephemeral DH for forward secrecy do an ephemeral th to the other party static key for authentication and then hash of these teachers together to get a finality and the reason why this convinces each party that the other party has agreed to the final keys because this final key is a hash that includes the DH of the authentication DH of their ephemeral key the other party static private key the only other party who knows the output of that DH is the other party and us if we do anything with the final shared secret key like receiving encryption message from that we know that he can only then capped calculated by the crack counterparties so we're accomplishing that authentication by using DHSs images here and so this is a you know so well understood thing
but I want to you can just touch on that before we talk about for the dive into the history of noise in the
history of noise is that in a few years ago I was reading from a lot of papers that talked about Diffie-Hellman based key exchange looking at it from a number of these designs were people were doing Diffie-Hellman based the exchange of ideas were of logical designs thought they were elegant of other efficient but every time someone I did a new Diffie-Hellman based thing like and Torah assaulted Courtesy Peter oculesics is sort of start from scratch and they'd say OK how are we going to do some key derivation how we going do transportation how EDT confirmation if they're doing security analysis they create their own security model they write their own gap th formed a security proof it's pretty much the same as the also securely proof but is still out of work to is a lot of reuse of sort of repeated work being done to build a solid protocol and so kind of the the motivating idea for noise was whether we could on capture that work into a framework that is provided using common elements that people could easily be combine combined as elements together and create a wide range of different protocols in this style and so I started working on ways of you know kind of connecting protocol pieces together of events that talked to my Hamburg was working on that something else is strobe protocol framework that was kind of based on sponge based and we can detect some ideas from that
and with with all those ideas were able to come up with I think a pretty good system for describing a wide range of protocols just taking the Diffie-Hellman operations into simple other cryptography and combining them in a bunch of ways and so that co-design head of noise is what we sort of arrived at by 2015 and it's been stable since then so we've seen a noise is still work in progress because you're trying to extend it and add new forms of cryptography and build more things kind of around the score but we do have a pretty good core this point I would build a small community around it with a mailing lists websites specifications testsuites only of open source libraries in a bunch of common languages and that we have a couple uses noise this protocols used by what's after for a client server communication from the AP to the server and the WhatsApp and the wire God which is the next generation the cantonal project budgets and on fell also uses a in noise based execution protocol and we're getting interest from some of some the directions from people doing like Internet of Things embedded systems anonymity network type systems script the network proposal for a the coin you in corporate and as this protocol so I think we're getting interest and people who are potentially 1 you know I kind of a customized secure channel protocol for a new area they're working in but don't wanna drag a lot of like extremes complexity they want something simple and efficient that addresses the use case that's what I think that's kind of the the sweet spot for noise so far so for the rest of the talk will want to do is you talk about what the components of institutional protocol are why I think it's a good idea to have a framework that kind of addresses the design of these things and fill in the details on what the noise framework actually
is Secure Shell protocols on what kind of the same structure they start with a handshake phase parties and a few messages back and forth to get a shared secret key these this year secret key for the flicker transport phase it is doing bulk encryption and the transfer phase is is a simple thing it's pretty easy to just use shared keys to encrypt data back and forth so I'm not gonna say a lot more about it and they Hanczyc phase is kind of where all the time you know the excitement and the interesting things here so of course via an the main component of a secure protocol your channels handshake is to be just a not authenticate exchange making of some sort but a lot of persecution protocols will also have some sort of a negotiation that happens before a set of logically before the rest of this that determines the type of a k in the parameters of the AKT and the parameters of the encryption such as which sigh for years and you can think of this negotiation happening logically before everything else because it determines everything else but in practice for efficiency via the negotiation making you usually kind of over later woven together a little bit somites and initial message from the client it says I'm speculatively executing this a protocol but I'm willing to execute these other protocols and I'm willing to use deciphers for the transfer phase the the server can respond by saying I want you to do a different AKEL 1 use deciphers at the end of that and so you have this negotiation making things happen kind of simultaneously which is 1 of the reasons is protocols are a little complicated to think about but anyways if we were if were building a single Secure Shell protocol we would be in trying to fill in these elements would be saying OK was aching easily why use had 1 instantiate the cryptography within them and how we wanna design negotiation structure that can you know us select 1 of these different things and and how to assemble a together we don't want to outsource not trying to build a single if protocol were trying to build a framework for building a protocol so we're doing something a little bit more confusing and the reason why is the for is the principal reason which is that if you're trying to build a sub single-protocol it's uh you know you have a hard decision and a difficult off to manage between adding features into this protocol in keeping it simple because the
more features you add more negotiation you have the more of a different branches you protocol can take the more of more complexity every employer has to deal with the war attack serves you have because if is any but many of these features that an attack can navigate to that's potentially a problem so you know we want our our our work on things that have a lot of features that address a lot of cases but we also I keep things simple so if we think of ourselves as creating not just a single protocol the framework of protocols we can kind of manager that
tension will the better by matching that we have all these features and all these capabilities kind of off to the side and like a library to look somewhere through build a concrete protocol risk and selected bunch of features and hopefully as a simple combination also putting them together and you get a very customize protocol if it does you know exactly what we want and not anything that we we don't want that means that the working with noise is is different from working with something like TLS because with a lot of problem most cryptographic protocols hedonistic uh just library pointed another tells library and you'll figure out how to connect still do you know negotiations and back retries and whatever but they'll find the intersection of Cyprus sweets in versions and so on that this support and will connect to each other and that's a feat of engineering but there's a lot of complexity so as behind that there's a lot of path opacity in this kind of understanding what you're where you really getting so nor on the other hand the but to use it you have to kind of thinking advance about what you wanna use wikis you want use work appropriate yet you can choose all these things you have to understand why you want the sequence of messages you put them together and you know it was something that on very much addresses your use case hopefully but is not going to have a lot of extraneous complexity so that's a different way of working with protocols and thinking about protocols but I think it's it's the right answer for a lot of cases early sets a goal as we want those a framework or we can some choose a bunch of things combine them together and then but then end up with a wide range of different of protocols but to get there is a little bit complicated to get there we have to take part in a structure of of the secure channel protocol and break it up into some different elements so that we can mix and match these elements and get protocols with a
break it up in arms a couple different ways the 1st were really do that is really a seperate out all the points in the protocol where I were run time decisions are made from all the points the protocol we can think of this just straight line linear code and the reason why is because if we have straight streamlined just linear cryptographic code that just as 1 thing after another and sends 1 message after another on end is nothing else except maybe airing if it detects a on the detector cryptographic authentication failure Rivkah like that it's very easy to test this is to think about the design things around because it just does 1 thing in a sequence and so that's noise is very much going be about forcing people to use straight line code with no branches as much as possible on our idea of being a framework hopefully help so that because of a lot of decisions that might have been one-time decisions negotiations seen a full protocol removing them to hopefully design-time decisions within a framework but we might so after negotiation decisions remaining about like which sigh for use or around you know like if tried use your trip encryption we mapped to fall back to something else so there might be some decisions that remain really try to compress all those decisions and to kind of 1 considers only 1 point in this framework where run-time decisions get made which is selecting war going to call noise protocol and the noise and this notion of a noise protocols and encapsulates everything else happens is just a linear sequence of codons can indeed be a K plus whatever transport encryption happens after that so With this framework we properly you know we a decision making at runtime going to compressor down to 1 if we have 2 and call everything else is a straight line sequence of code the next order due to make this for immersive manageable and break it down is zoom in on this note
this notion of a noise protocol and break pieces to Serena view that as a combination of what we call a handshake pattern was an actual cryptograms and AI ahead she Canada is going to be like a uh an abstract notion of any cases can AK protocol that just says do some sort of Diffie-Hellman encryptors in some way hashes in some way but it's not gonna tell you what crypto use you get plug-in trip so in Sec combination of things is going to give you a concrete noise protocol which is in kind implementable unit of of this framework
so the whole framework then it kind of ended being like this we this sort of course central piece is this notion of the noise protocol which is probably most of our engineering effort on where we combine some abstract notion AKT Ohashi pattern with some crypto together noise protocol re-imagining negotiation where they can really just make 1 decision which is does the server want to switch from the initialize protocol to different once running allow 1 transition just to make things you simple and can then the only other it where an ad is this uh this notion of an encoding layer which is that we might want to send their messages over TCP I you act at fields a rights and more HDP in which you slap encode the message the peer requests so we have this kind of abstract notion of our protocol we might need to add a little bit more encoding to actually fit it into a particular context and that's just the kind of just the way we build a a secure channel protocol so the main thing on that you're going to interact with this is or the castle pieces is a noise protocol main way that you're going to interact with noise protocols and designed them as it as a user is that is giving the names and so we have this
notion of you can be precisely protocol and images kind of like the entire protocol so here we have they known and noise protocol that's you know this is a concrete implementable thing use the annex pattern which I have explained what that means but it also combines that pattern that AKT notion With curfew 55 19 for Diffie-Hellman with AES GCM for encryption was shot 256 rationing weakened up plug-in out different popular any 1 of these things so we can have different patterns different sectors etc. to get a big noise protocol and then did the specification and most noise libraries can take this name was automatically know to deal synthesized all protocol around this just with some some pretty simple rules and so the pattern notion in the way word naming patterns others in naming convention here but I think more important understand the naming conventions understanding the simple language that it's that's built on top of and so we're going to have a sort of simple language for describing a range of 2 abstractly k patterns based on this on this set of concepts
this I'm just saying we have Alice and Bob some day each might have a static he and I might have an ephemeral key and the only things were going allow them to do as part of the protocol is send the public keys forth Hindu Diffie-Hellman operations and only Diffie-Hellman operations that can do are interviews for involving some combination the keys which you can just read from left to right so they can the static static Diffie-Hellman they can do the Alice static Bob's ephemeral was sort of authenticates Alice he do Alice's ephemeral to Bob static which authenticates Bob where they can do this he Diffie-Hellman for forward secrecy so relevance to combine these units in different ways and get a wide range of different AChEI's others so let's start us demonstrate amid budget patterns and how they go through them quickly in the throw something that's very simple which is just a public key encryption so this a key pattern doesn't even describe interactive protocol just Alison crafting a message to bob and so our little language here at 3 . to indicate when Alice has prior knowledge of something before the protocol starts is the protocol where Alice knows Bob's public key at the outset genus and 1 message which is an ephemeral public he she chooses to do in yes ephemeral Saturday the element to authenticate Bob and that's going to give her public key encryption that she's that keys that she can use 1st of the transport phase encryption of the message she sending to Bob so that's just as you could think of this is in like in the BCI ephemeral static public encryption we can make this more complicated by saying both parties and the public keys and what Alice to authenticate a barber now we just throw in the static static encryption now we have Alice authenticating herself to but we could make another 7 complexity and say we want us to authentic yourself to Bob Analysis Center public key to Bob and she must understand certificates and things like that to commence father public to be trusted that can go in the transfer payload but the point is now we've on you take analysis public say instead of adding prior knowledge about its transported in the in the message itself and we have this additional which is at any time we do it if it we we send a PUT static public key word unencrypted with all the other key that have come before so in this case allostatic public using cryptid with the output of the ephemeral sadeghi DH which provide some identity hiding so on looking at the wire doesn't know who else there's even though botanist we can move on to on to the interactive protocols look at unauthenticated Diffie-Hellman just looks like this an exchange of ephemeral public keys and a Diffie-Hellman but you cannot serotonin cation to that Ritzer descended static public key in does visited the element of you could imagine that the server's public key is known in advance by the in this case we don't have to in this case we had to on transport in this case we're not transporting it from the server some beautiful in this case we can use something even better which is kind of a a nice property of of the solid protocols we can move that a thermostatic DH from the 2nd message the 1st and the Alaskan actually do 0 round trip encryption of to Barbara to the server's public key so she does this the 1st messenger is essentially where earlier called the public key encryption she just encrypting straight away to bother 1st message and that's something we can do with the Diffie-Hellman this taking that you can do is say signature-based taking because if Bob static and assigning he would not be able to introduce some so you know that's kind of an example some nice features we get from the style they caII we could continue making things more complicated so we could add it not just of 0 trip encryption is your trip authentication in this 1st flow by having Alessandro identity and them doing additional Diffie-Hellman we can on and for doing that we should probably also refresh the authentication in the 2nd message with this yes so that it's so the Bob's authentication analysis based on a fresh ephemeral instead of a long-term static he which could potentially be compromised only if we do all this we get actually this is very close to wire guards pattern wire regard as an additional feature that is a pre shared symmetric key and that's something that uh you know we designed working with the well-regarded design adjacent felt that allows you to add an extra key into the gets mixed and everything the idea being that arm in a VPN context to parse 1 a share is a secret key you securely will depend on either that or all these Diffie-Hellman and so even if someone's able to break Diffie-Hellman through analysis quantum puta if you've shared uh secret key through some other means you would not be able to the bridge back and break your traffic so that's condition example how we can take this language that that is a fairly simple language extend it with new features and were interested in and continue that process and adding new features on this so I knew things that are at the end the next is trying to figure out how to add the you know I'll quantum resistant algorithms provide hybrid forward secrecy of these protocols even going back and adding on the notions of signatures into this because just like all this machinery had is good for Diffie-Hellman this protocols probably can take all these notions of patterns and of noise protocols and how a person initiation and apply them even to more conventionally keys into the other thing that's what so that's sort of our framework you it ends up looking kind of like this with
some you know very simple negotiation Layer switching to this very linear notion of a a fixed noise protocol the you can assemble together by taking abstract notion of patterns and finding it with cryptography of your choice of
you're still working a lot of extensions for this and love to get more people who wanted to experiment with the use of freezing but you can find more on our website which has links some illnesses well I'm happy to talk about with anyone that using the Awadh area tomorrow at at 3 o'clock in a probably be known around there as well that if you wanna talk to Jason another wired the people and see how all this works in a concrete context that would be no good way to learn more about it from thank you for listening and if you have time for questions maybe a brief note of if the yeah yeah I'm microphone 1 test test of of so in the context of light field of multi-party systems if you have like a person that has either multiple devices for multiple keys is there anything from so but you could use inside a noise to work with that so that you have like messages being sent to both identities or to recommend some doing something like that over like a central registry and then linking the keys and having that sense 1 answer but devices sharing with each other yeah that's in question I mean I think that really gets into the scopal warlike secure messaging protocols try to address and new notions of groups Monte consisting of the group and you want to talk to run Drupal maybe a random group is an online at the same time policy that's a different and more complex class of protocols that which kind of does not trying to handle here I think when noise hopefully we're looking at something that's a very simple and well understood design space so we can build a lot of machinery around it because it's a simple and these easily gives you time and I think she's had a lot of complexity about how you would want do all those things so it's would kind a narrow scope to make our this specific problem a lot easier I would say good things so they are there is noise include any of the retina sort key evolution over time properties we've seen in purple split this past I don't know some noise has a pretty simple model it is you have like a handshake phase transfer phase in the transfer pages uses a key now we have added a notion of being able to like update this key by just replacing it with like the you know some of its own output essentially so we can kind of role of for a very simple way and we have an efficient way of doing that so you can do things like have every 1 of your messages update the key the next key and then you have within the protocol forward secrecy we don't you try to like more complicated things with Diffie-Hellman ratcheted like that do let of 1 would be once the simple sales pitch for white these noise over T us no 1 nearby the simplest cells should be like if you want really really want a protocol that is to like 1 thing and you don't wanna drive around a lot coded as like a lot of things you know like noise let you produce a very high finding protocol it's a very small Malkovich's like 1 thing pretty easily it's it's what would have thank
was just if
if you if you the and thank you and eked complained it to people
Telekommunikation
Protokoll <Datenverarbeitungssystem>
Computersicherheit
EDV-Beratung
Information
Frequenz
Framework <Informatik>
Dijkstra-Algorithmus
Geräusch
Client
Datenfeld
Framework <Informatik>
Kryptologie
Festspeicher
Grundsätze ordnungsmäßiger Datenverarbeitung
Protokoll <Datenverarbeitungssystem>
Radikal <Mathematik>
Server
Projektive Ebene
Wort <Informatik>
Telekommunikation
IPSec
Protokoll <Datenverarbeitungssystem>
Computersicherheit
Adressraum
TLS
Kontextbezogenes System
Framework <Informatik>
Quick-Sort
Geräusch
Client
Framework <Informatik>
Prozess <Informatik>
Kryptologie
Protokoll <Datenverarbeitungssystem>
Server
Schlüsselverwaltung
SSH
Message-Passing
Zentralisator
Punkt
Protokoll <Datenverarbeitungssystem>
Computersicherheit
Kryptologie
Computer
Raum-Zeit
Framework <Informatik>
Quick-Sort
Richtung
Eins
Framework <Informatik>
Arithmetische Folge
Menge
Flächeninhalt
Komplex <Algebra>
Kryptologie
Mereologie
Datentyp
Protokoll <Datenverarbeitungssystem>
Zusammenhängender Graph
Message-Passing
Folge <Mathematik>
Subtraktion
Bit
Quader
Zahlenbereich
Identitätsverwaltung
Zentraleinheit
Eins
Chiffrierung
Message-Passing
Informationsmodellierung
Kryptologie
Authentifikation
Datentyp
Nichtunterscheidbarkeit
Protokoll <Datenverarbeitungssystem>
Schlüsselverteilung
Folge <Mathematik>
Transinformation
Datentyp
Protokoll <Datenverarbeitungssystem>
Kategorie <Mathematik>
Computersicherheit
Template
Kryptologie
Elektronische Unterschrift
Quick-Sort
Physikalische Theorie
Authentifikation
Information
Schlüsselverwaltung
Message-Passing
Public-Key-Kryptosystem
Hydrostatik
Addition
Hash-Algorithmus
Schlüsselverwaltung
Protokoll <Datenverarbeitungssystem>
Gemeinsamer Speicher
Element <Mathematik>
Biprodukt
Elektronische Unterschrift
Quick-Sort
Hydrostatik
Chiffrierung
Chiffrierung
Bereichsschätzung
Endogene Variable
Hash-Algorithmus
Mereologie
Schlüsselverteilung
Authentifikation
Schlüsselverwaltung
Bildgebendes Verfahren
Message-Passing
Funktion <Mathematik>
Subtraktion
Protokoll <Datenverarbeitungssystem>
Logiksynthese
Computersicherheit
Kryptologie
Element <Gruppentheorie>
Zahlenbereich
Derivation <Algebra>
Element <Mathematik>
Transportproblem
Ereignishorizont
Quick-Sort
Framework <Informatik>
Motion Capturing
Geräusch
Spannweite <Stochastik>
Informationsmodellierung
Symmetrische Matrix
Dämpfung
Physikalische Theorie
Beweistheorie
Protokoll <Datenverarbeitungssystem>
Schlüsselverteilung
Analysis
Bit
Punkt
Nabel <Mathematik>
Formale Sprache
Adressraum
Wärmeübergang
Element <Mathematik>
Komplex <Algebra>
Richtung
Client
Kryptologie
Protokoll <Datenverarbeitungssystem>
Skript <Programm>
E-Mail
Phasenumwandlung
Umwandlungsenthalpie
Nichtlinearer Operator
Parametersystem
Datennetz
Computersicherheit
Applet
Web Site
Entscheidungstheorie
Generator <Informatik>
Chiffrierung
Framework <Informatik>
Menge
Grundsätze ordnungsmäßiger Datenverarbeitung
Server
Projektive Ebene
Extreme programming
Schlüsselverwaltung
Message-Passing
Proxy Server
Telekommunikation
Wiki
Web Site
Framework <Informatik>
Open Source
Geräusch
Bildschirmmaske
Spannweite <Stochastik>
Internet der Dinge
Arithmetische Folge
Datentyp
Programmbibliothek
Skript <Programm>
Zusammenhängender Graph
Datenstruktur
Schreib-Lese-Kopf
Protokoll <Datenverarbeitungssystem>
Open Source
Einfache Genauigkeit
Physikalisches System
Internet der Dinge
Quick-Sort
Dechiffrierung
Flächeninhalt
Formale Sprache
Authentifikation
Speicherabzug
Folge <Mathematik>
Bit
Subtraktion
Protokoll <Datenverarbeitungssystem>
Computersicherheit
Schaltnetz
Adressraum
Versionsverwaltung
Verzweigendes Programm
Element <Mathematik>
Wiki
Komplex <Algebra>
Framework <Informatik>
TLS
Geräusch
Spannweite <Stochastik>
Framework <Informatik>
Mereologie
Programmbibliothek
Exergie
Figurierte Zahl
Message-Passing
Subtraktion
Folge <Mathematik>
Punkt
Schaltnetz
Implementierung
Framework <Informatik>
Code
Geräusch
Einheit <Mathematik>
Kryptologie
Mustersprache
Protokoll <Datenverarbeitungssystem>
Kontrollstruktur
Gerade
Sichtenkonzept
Protokoll <Datenverarbeitungssystem>
Verzweigendes Programm
Systemaufruf
Rechenzeit
Zoom
Quick-Sort
Entscheidungstheorie
Linearisierung
Chiffrierung
Linearer Code
Authentifikation
Ordnung <Mathematik>
Message-Passing
Zentralisator
Bit
Subtraktion
Hash-Algorithmus
Gruppenoperation
Formale Sprache
Framework <Informatik>
Chiffrierung
Geräusch
Spannweite <Stochastik>
Mustersprache
Protokoll <Datenverarbeitungssystem>
Programmbibliothek
Bildgebendes Verfahren
Umwandlungsenthalpie
Protokoll <Datenverarbeitungssystem>
Abstraktionsebene
Computersicherheit
Kontextbezogenes System
Quick-Sort
Entscheidungstheorie
Mustersprache
Datenfeld
Chiffrierung
Framework <Informatik>
Menge
Rechter Winkel
Server
Wort <Informatik>
Message-Passing
Public-Key-Kryptosystem
Hydrostatik
Subtraktion
Punkt
Prozess <Physik>
Gemeinsamer Speicher
Schaltnetz
Formale Sprache
Wärmeübergang
Unrundheit
Bridge <Kommunikationstechnik>
Element <Mathematik>
Framework <Informatik>
Hydrostatik
Geräusch
Spannweite <Stochastik>
Einheit <Mathematik>
Algorithmus
Kryptologie
Mustersprache
Nichtunterscheidbarkeit
Quantisierung <Physik>
Kontrollstruktur
Phasenumwandlung
Funktion <Mathematik>
Analysis
Private-key-Kryptosystem
Nichtlinearer Operator
Digitales Zertifikat
Protokoll <Datenverarbeitungssystem>
Abstraktionsebene
Wurm <Informatik>
Domänenspezifische Programmiersprache
Kontextbezogenes System
Elektronische Unterschrift
Datenfluss
Quick-Sort
Arithmetisches Mittel
Chiffrierung
Framework <Informatik>
Konditionszahl
Mereologie
Server
Authentifikation
Wort <Informatik>
Schlüsselverwaltung
Message-Passing
Web Site
Gruppenkeim
Gefrieren
Zellularer Automat
Wärmeübergang
Information
Komplex <Algebra>
Raum-Zeit
Homepage
Multiplikation
Informationsmodellierung
Plenoptische Funktion
Komplexitätsklasse
Nichtunterscheidbarkeit
Maßerweiterung
Phasenumwandlung
Funktion <Mathematik>
Konfigurationsdatenbank
Softwaretest
Protokoll <Datenverarbeitungssystem>
Kategorie <Mathematik>
Computersicherheit
Physikalisches System
Kontextbezogenes System
Binder <Informatik>
Quick-Sort
Flächeninhalt
Evolute
Heegaard-Zerlegung
Schlüsselverwaltung
Message-Passing
Hypermedia
Medianwert
Systemprogrammierung

Metadaten

Formale Metadaten

Titel The Noise Protocol Framework
Serientitel 34th Chaos Communication Congress
Autor Perrin, Trevor
Lizenz CC-Namensnennung 4.0 International:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
DOI 10.5446/34896
Herausgeber Chaos Computer Club e.V.
Erscheinungsjahr 2017
Sprache Englisch

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract The Noise Protocol Framework is a toolkit for 2-party secure-channel protocols. Noise is used by WhatsApp for client-server communication, by the WireGuard VPN protocol, and by the Lightning Network. In this talk I'll describe the rationale behind such a framework, and how you can use it to build simple, efficient, and customized secure-channel protocols.
Schlagwörter Security

Zugehöriges Material

Folgende Ressource ist Begleitmaterial zum Video
Video wird in der folgenden Ressource zitiert

Ähnliche Filme

Loading...
Feedback