 software developer. The work that I'm doing today, I do under a moniker of Noxen. I tend to be dingo sky on all the social networking, et cetera, types of stuff, but this is actually under a moniker of Noxen. And what I'm going to show today is an idea that, it's a scenario that I think we're going to see more of. We've already seen some and we've seen a few nightmares from it, but the idea is simple. I've got an iPad and I've got an RPI-3, Run Nerves, and I want this iPad to run this RPI-3 and the RPI-3 is actually running a stoplight. Fairly simple idea. You could imagine this is something I bought commercially off the shelf and I sold that to somebody and then I sold them an iOS app that they can run this thing. It's a thermostat, it's a refrigerator, it's whatever the IoT world is dreaming up, you can sort of envision that that's what's sitting here. And what I want to do is talk about how do I do this in a way that puts some security to it. So the first thing I'm going to do is just get it running, right? So we don't worry about security first, maybe. So I'm going to do this, the things I've got set up here are Raspberry Pi-3 with stoplight on it, a momentary switch, I'll explain what those are for, a little network sitting here so that I don't run into the problem I had that these guys can talk to each other on their own little closed network, this Hutu, and then the iPad. I'm really concentrating on connecting to this one at a time and I'll explain that as we go along. Here's a system overview, as I just mentioned there, stoplight, momentary switch. I'm using, running on this Raspberry Pi, this is not necessarily a nerves talk, I'm using nerves obviously, I'm dedicated to those people who've put so much work and fine work in it, it's great, it's actually an interesting little thing to do. I'm running an HTTP interface on that using a web server called elli, I've got a version of this running with plug which uses cowboy, but this particular one I've been using elli for a number of years and was already comfortable and familiar with it so I used elli. The iPad app is pretty simple, it's just going to show three lights and I can poke on them and make these lights change on my, on my RPi. The interaction is as follows, I bought this thing and I brought it home, I downloaded this iOS app and now I want to make these things be able to talk to each other securely so I'm going to place this RPi 3 into pairing mode, I'm going to pair it with this iPad, then I can log in using this iPad and I can use this iPad to control it and the idea again, the thing I'm really after here is saying that only this iPad can run that Raspberry Pi. So here's the app that's sitting on this RPi 3, a NERVs app, you see it's got the device pairing is, right now you see the lights flashing red, that means that nobody can connect to this at all, I have to put it into pairing mode so I've got a gen server running that's taking care of the device pairing. I've got a stop lights and that's actually listening to pen 17 so it's looking for voltage increase and decrease on pen 17 using Elixir Ailes for general purpose IO on the Raspberry Pi, then I've got another server running the light itself so it's listening to pens 9, 10 and 11 so that I can go and say, you know, turn pen 9 on, turn pen 10 on, etc. and lights will magically appear. The login manager is just the thing that allows these things to all connect to this Hulu and for this guy to then find them. Excuse me, that's actually the network. The login manager is going to be the thing where I actually log into this so that after I've paired then this guy's got to log into it and then finally we see Ellie and it's got three listeners more than I need here, right, I need one but it's fired up three. And there's the configuration for Ellie and for those of you who are not familiar with it, it's like any other web development stack type thing, it's got a stack and in this case, so these are just all the handlers for it. The status handler checks the device pairing, the login handler says if somebody logged in how do I handle that and then finally if both of those have passed then I can actually control the lights. So let's do that. First thing I do is if I try to log into this thing, it tells me you can't. The red light's flashing, it's telling me here that the device is blocked. So I'm going to put it in, I'll put it into pairing mode, hold that momentary switch for a couple of seconds, it fires off a timer so I've got 20 seconds to get this in, 20 or 30, I don't remember what I made it. And this now I'm pairing, I'm going to give this scene a name, they'll call it Http, this password will be secret and by that I mean the word secret, not that you don't get to know it. And then I didn't get there fast enough. And there now I see this flashing green, that means now I can control the light, I can turn it red, I can turn it green, turn it yellow, turn it red again. And the first time you do a nerves app, you go get a beer now, right? You might even go get two. It seems like we have a big deal. And mind you, also let me just put a quick aside, for those of you who have done talks and worry about the demo gods, I just, Andy doubled up here, I've got three of these damn things in an iPad and this and just crossing my fingers and we'll see. So let's look at, whoops, that all was well and good, I talked to this thing, but there's a significant problem and that is that anybody on the device, I mean on the network with me could see what I was doing. Here is my pairing where I said I used HTTP in secret, right? Then I logged in, then I changed the status, I looked at what's the status of the light, I turned the light on, I turned it yellow, green, red, et cetera. Clearly not secure. Clearly anybody that can get on to this, hack onto this Hulu2 could actually be able to see this traffic. But it's actually worse than that. This is just in case it didn't work, that's what we just saw. But it's a little worse than that in that, I'm going to do this again, let's go. I'm going to go here, you can see my light is currently red. I'm going to go over to this, and I'm going to say take the HTTP light and switch it to green. Look at my iPad, ouch, this turned green, the iPad doesn't know anything about it. It can even be a little worse than that in that the, I can tell the light to turn red now, and I've got red and green both on. I can't do that with the iPad, it's basically a bug. But I didn't catch it in my iPad because I can't allow myself to send that message. So not only can someone control the light, they can put it in an inconsistent state. Clearly not what I thought I was getting into when I said I wanted to control these things, but that's fine, we didn't use any security yet. So the problem here then is that Eve can snoop the traffic, see the plain text, username and password, capture application data. Now I'm going to differentiate here, this is a security talk, I'm going to differentiate between Eve, which I think of as an evil person but just listens, and Mallory who has malicious intent. They're really the same person, but Mallory's got malicious intent. She'll actually alter the traffic. It's very possible to sit in here between these two, and every time this sends red to change the traffic and say make it green instead. And so now the person trying to control the light here can't get it to even work. That just gives you the sense that Mallory now can manipulate this API for fun and profit. And then that's the thing that I really made an issue with here is that now someone other than this iPad's controlling that thing. The iPad can still manage it, but without the iPad's knowledge this thing can be changed and that's not what we wanted. So what do we want to do? We want to add security. I'm not covering these for secrecy, I'm just trying to make sure nobody's epileptic and decides to collapse and then I'll feel really bad. We're going to encrypt this by using symmetric key encryption. It's absolute way, well, we'll talk more about it. So that brings up the problem though is how do we get a symmetric key both on the iPad and on the Raspberry Pi. This is known as the key distribution problem. It's a thorny issue. It has not been solved. I don't care what you think, it's just been addressed. Certainly not solved. One of the first things you could try and think of is say well, just burn the key into both of these. That's basically what the ciphers were for thousands of years. That's what if you read Cypher book in history, the first ones you'll talk about are Caesar ciphers and say they rotate the three, well that's the pre-shared key is rotating three and you told all your generals. Well the problem with that is that it's got several significant issues. One is called forward secrecy. It's actually called perfect forward secrecy. I took perfect out and I thought Matt because it's perfect in the sense that it's complete, not in the sense that nothing could possibly be better. So I take it out, I just call forward secrecy. Key refresh and maintenance are also issues. How do I tell the generals that I've changed? How do I make sure that all the generals got all of my changes? So just forget pre-shared key. Just don't try it. So instead we'll use dynamic key establishment. And the scheme that we're going to look at is an asymmetric scheme to create our symmetric key and then we'll use that symmetric key for the actual secrecy. You've all done this. Whether you knew it or not, that's exactly what HTTBS is. HTTBS is an asymmetric cryptography to establish a key and then after fact everything after all the bulk is actually done using symmetric key encryption. So now we're going to do this again. This time we're going to connect to the HTTBS. I've already registered this guy. So I can just log in as. And I can't see that so I hope I'm getting there right. Please. Yep. So now I'm logged in and I control this guy, this light, and I'm doing that through HTTBS just to prove that everything is wonderful in the world. Whoops. We go back over to the, oh by the way I should have introduced this. This is just a man in the middle proxy. I'm using Charles here. They're free. This one costs $50 but it's so convenient for me. I've had it so long. I like it. Man in the middle proxy is free. Wire shark is free. Windows has other versions, etc. So but here's the key is that after I do that, there's what the traffic looks like. I go and I have another beer, right? Everything's great. I'm going to restart this and come back tomorrow and I, you know, I sobered up. I came back. I thought, okay, how's this working now? And pardon me while I don't watch the man behind the curtain as, oops, cancel you as I go and make a little switch here. And I'm going to do that same thing again. So now I'm logging into the HTTP interface. Comes up. So I say HTTBS secret. And again, I've sobered up. I've looked at this. I'm feeling pretty good about things. I'm running my light and then somebody notices and says, hey, I'm running a man in the middle on you. And this is what I see. This is what you logged in with. Here you are switching the light around. Likewise, I can, what color am I on? I'm on red, so I'll switch to green. It's a little slow, but it's got to do its right. I see that switch to green. This guy doesn't know about it. Basically, I'm right back where I started almost. I'm a little bit better off, but HTTBS didn't solve my problem. It did not finish it off for me. I thought I was done. I thought all I had to do was use HTTBS and I would be done here. And clearly I'm not. So what happened? That's the HTTBS scenario. This is the HTTBS scenario with man in the middle. And I can actually use curl to run this thing and note that curl, the magic there is that tack K there. That says disregard any key exchange and stuff. I'll see in a moment about that. But anyway, if you actually man curl, then you can find out that there's that tack K there and do this. So what are the issues? We sort of took care of Eve. She can't see anything. But we didn't take care of Mallory. Now Mallory can still snoop this IPad traffic through legitimate use. Mallory can manipulate the API for fund and profit. She can control the stoplight independently of the IPad. And we really now still have this whole man in the middle thing. And there are companies that do man in the middle on all traffic inside of there that goes out of there off their network. So it's not like man in the middle can't happen. With man in the middle I can see plain text user IDs passwords, capture application data, alter the traffic, etc. So at this point it's time to stop and say, how'd I get here? Why didn't that work? What was my susceptibility? And I'm going to do that by actually looking back at how we get the HTTPS. And we start in 1976 with Diffie and Hellman. And this is called a Diffie-Hellman Key Exchange. It's a way to say it actually revolutionized cryptography. We would not have the current web as we know it without this paper and then what followed up a couple of years later, which will be the next slide. Diffie-Hellman found out, and Merkle actually, this should actually be called DHM. Merkle was involved but he wasn't on the paper so history left him behind in this sense. Although we still have him, he still gets Merkle trees, right? So don't feel too sorry for the guy. I actually went to grad school and had a friend who he pined so hard to have a constant named after him, or some process, like a Rossby wave. He just couldn't stand the fact that he didn't know how he was going to achieve that in his life. Ma'am, I'm all right here. So how does Diffie-Hellman work? Chuck and Sarah, usually you see this as Alan and Bob. I'm doing, because I'm really concentrating on a client server, I chose another often used Chuck and Sarah, because Chuck's the client and Sarah's the server. What they do is they agree to use two parameters. I'm picking very small numbers on purpose, G2 and 13, and they do the following. Chuck says, I'm going to grab a random number out of sky five. It's got to be less than 13, but we'll try. I'm going to take that five, two to the fifth power, mod it by 13, I get six. I'll send that to Sarah. Sarah does the same thing. She picked eight. She takes two to the eighth, mod 13, gets nine, throws it back to Chuck. Why? Why do they do this? Great. You can do some math. Good deal. Because of the following. Now, Chuck takes that nine that he got from Sarah, and he raises it to his five that only he knows. Mods out 13 and gets three. Sarah does the same thing. She takes the six she got from Chuck, raises it to the eight that only she knows. Mods by 13, she gets three. And that was a huge deal. Because now we can actually agree on a key without having to talk, without having to have the generals all come home. Chuck and Sarah can do this from as far apart as they want. We call this key establishment. They've done this through what's called key agreement, and they've got this k equals three. Here's the really nice feature of this. Even if she knows g and n, because remember those were public values, even if she sees the six and the nine, because I didn't say anything about the fact those aren't hidden, they're fine, she still can't calculate k. Now, with my numbers, you could. But get these big enough, and it makes it pretty hard. So it's difficult to do that because of what in cryptography you lean on these things called one-way functions or hard problems. This one depends upon the fact that discrete logarithms, if you've got a finite field with a prime order, and that order is large enough, then finding the discrete logarithms in that finite field is extremely difficult. That's what's happening here, whether you know the math or not. And Diffie-Helman problem is actually slightly different than that, but it's linked to the discrete logarithm problem. So that's kind of what we'll just say. It's difficult to find k. The problem with this, though, is it's called an unauthenticated key agreement or also sometimes called an anonymous key agreement in the fact that, notice that Sarah got a six. All she can do is say, I guess Chuck sent this. Chuck gets a nine and goes, I guess Sarah sent this. There's no authentication. We'll talk a little more about that in a moment. Two years later, now these guys are three of them. They screwed up, right? Revest, Shamir and Alderman, they only get RSA. They don't get, nobody ever says their name. In fact, I have to keep reminding myself what the A actually is, but nonetheless, with this, the math's going to be a little harder. Just squint and let that go by unless you have a math background. But we're actually using real numbers here because I think it's instructive to see them to get a feel for what's happening when I'm doing something that we all talk about and I talked about in her talk, this public-private key exchange. So Sarah creates a key pair by choosing two prime numbers that are close to the same size. There's going to be a lot of this that, again, it's simplified and I'm brushing over things tough luck. We're making this as simple as I possibly can and still get something. So she chooses two random numbers, two prime numbers, multiplies them together and gets 55 and then she finds something called the older totient function of that which really tells you how many integers less than 55 are relatively prime to 55 itself. Why does that matter? Go read a book. It does. So anyway, we've got the totient function. It turns out that for prime numbers, it's very simple to calculate. It's just one minus each of the primes multiplied together so I get 40. So I can find the totient function for this 55 because I know pi and q. I can find it really easily. Now Sarah says, okay, I'm going to choose a value e, 17. It's got to be less than the totient function 40 and it's got to be relatively prime to 40. Again, go read a book. But she does it. She takes 17 and she solves this equation. e times d modded by the totient function equals 1. She goes and she's got some algorithms that help her solve that and the key fact of this is that problem is extremely hard unless you know p and q. If you know p and q, it's not hard. If you don't know p and q, good luck. It's basically the discrete logarithm problem. But she does know p and q. She picked the damn things. So she gets d is equal to 33. She stops with all of her, whoops. She stops and says, okay, I'm done here now. I've got a public key. I take my e and the n and I pair those together and call it 17, 55 and say, this I declare as my public key. The d which I calculated is 33, 55. It declares my private key and that is a key pair. Why would you do this? I mean, good God, there's a lot more math there than I'm even pretending to do it because of this very stunning fact. Any k less than 55, raised to the e and then raised that to the d and mod by 55 gives me k back. That's, again, we would not have the modern web without that statement right there because that is the reason why public key encryption works. Not to be confused with public key cryptography but encryption. So raising by the e is typically called encryption. Raising by the d is typically called decryption. The e and the d could have been switched above. There's a reason why you tend to keep the e one way and the d the others because you can make the math easier and so the public key tends to be easier to calculate. If you do it the other way, that's signature. You encrypt with the d, decrypt with the e, we typically call that we sign with the d and we verify with the e. But it's completely interchangeable. This scheme is great but it's computationally really slow. About a thousand times slower than symmetric key encryption. So we tend not to use it for bulk encryption but we do use it for key establishment and digital signatures. So let's see this in action. I mean Sarah, all we've done is talk about Sarah getting her number, she's got her number, she's feeling good. Chuck says, hey, give me your public key. She sends 1755. Chuck grabs a six, says I'm just going to use six and he raises six to her public key 17, mods it by 55, sends that 41 over to her. She takes the 41, raises it to the private key 33, mods that by 55 and gets the six back. Now they, I put the nonsense in there just because there's got to be some, that way they can guarantee that they have the same value. It's just some data that they're signing in effect. So this scheme, Chuck and Sarah establish, k equals six, this is called a key transport. We don't do this very often. What we tend to do instead of Chuck selecting six, they actually do a Diffie-Helman in the same time as this. That's why if you look in your TLS stack, you'll see ephemeral Diffie-Helman RSA. Because you're doing this but you're doing a Diffie-Helman. You're putting those two slides together. The reason you want to do that is because that puts both sides have some skin in the game. In this case Chuck chose the key completely independent of Sarah. So let's look at the structure of this because this isn't the heart of what we're trying to get to. This e17d33 and e55 has a binding relationship through that little equation that I wave my hands at a little bit. That e times d modded by the totient function of n is equal to one. That's the binding relationship. And here's the fact why we can do this. Because given that e and n, it's very difficult to determine d. Now if you remember that's exactly what Sarah did. But she had another piece of information. She knew p and q. If you don't know p and q, then basically you need to factor in into the p and q so that you can do the calculation and that's the part that's hard. It's called integer factorization. It's another one of the hard problems that we use in cryptography for one-way functions. Part of the more structure of this is that Chuck trusts that e and n belongs to Sarah. He either does that explicitly, just send it on. I'm ready. Bring it. Or he uses, he says, I don't know Sarah so I'm going to trust Trent. I know Trent. Trent knows Sarah. So I'll transfer that trust to Trent and you've all done it if you've ever used a CA. The certificate authorities are Trent and you're saying, I don't know. You tell me. Sarah also trusts that she wants to talk to Chuck. This is what I'm going to refer to as an open system. It's got multiple entity to trust model and there's no single person controlling this. And I want to get back to my theme here. There's nothing open about this system. This worked and is key to web development, the web world, because basically Sarah in the web world is an all-comer. She says, hey, bring it on. I want to talk to all kinds of Chuck's. Here I want this iPhone, I mean iPad, talking to there and that's the only two people I want to talk to each other. This is a closed system. Man in the middle, I'm just going to fly through this because I think I'm going to run out of time if I don't. Mallory, what Sarah did Mallory can do just as easily. She can come up with her own PQ, ED and N. Then when Chuck says, give me the key, Mallory intercepts it, gets Sarah's public key, sends her public key to Chuck, Chuck happily uses it, gets 76 this time. Mallory grabs the 76, decrypts it, encrypts it with her key and sends that to Sarah. She gets the 41 and she gets six. Notice that they got the same thing. They're still happy, but here's the real fundamental problem here. Chuck and Sarah can't know this happened. There's no fingerprint in anything that just happened there that Chuck and Sarah can see that Mallory was sitting in between them. In the scheme, again, this is a simplified scheme. Mallory knows the value of Chuck and Sarah's secret and that's effectively what I did here. I did it through a means that, two different means. On here, this is a jailbroken iPad and I installed something called an SSL kill switch. So when this contacted that guy and this guy sent back his public key, this guy will accept any public key whatsoever. It actually went through my computer where my man in the middle is. It gave it a different public key. This guy didn't care. Now, I wouldn't do this for me. It makes me insecure, but I would do it because what does this mean? I can see the API now. I can fuss with this thing. I just took this closed system and opened the box and I can look inside and then I went over to Curl, put a tack K on it and was able to control the light. Completely independent of this iPad because the tack K does basically the same thing as the SSL kill switch. It says I don't care. Surely this would never happen. So well, let's see. This is a quote from a document that was obtained by WikiLinks through the Shadow Brokers. I think most of us heard about this through what the NSA hacking tools. This was a document that was in that dump of the NSA hacking tools. It was a document on the Network Operations Division cryptographic requirements and I'm going to read it and then we'll go back and look at some of the points. Any transport layer encryption must be layered over the encryption discussed in this document because this outer layer may be decrypted by an attacker. Any transport encryption must therefore be used only for traffic blending and ouch, not for secrecy. What they said right there is HTTPS should not be used for secrecy in this fashion that I've just done. It's going to have to do more. You don't get to just slap an S on there. So a couple of things here. Transport layer encryption, that's TLS, that's the S in HTTPS. The cryptography discussed in this document was application level encryption and the traffic blending is the idea that if you look at HTTPS traffic, it all looks the same. You can't tell where the route is. You can't tell any headers. They're saying, hey, you can use it for that. You just can't use it for secrecy. So what do we do? Well, there are lots of options. None of them easy, but here's one. I built a framework that I call SRPC. I'm going to discuss it a little bit. I'm not going to show the framework in depth. I'm just going to show the idea of how it compares to RSA and why it gets to a better situation for this problem. So, whoops, same game. I connected this guy. He comes up, RPC. He's also got a secret password. And I can now play with this light. Everything's fine. Well, let's see what our man in the middle saw. That crap. I mean, it's all encrypted, right? There's nothing there to grab ahold of. In fact, it's even got traffic blending mixed in there as well. It's all the same thing. This is over HTTP, by the way. I could be doing this over HTTPS, but in this case, I didn't need to. I've got total encryption over HTTPS in a fashion that in this manner was better than my simple quick solution that was just slapping an S after the HTTP and thinking I was done. If I were to try to operate this light from curl, by the way, all I'm doing here is these are some packaged curl commands. But if I try to do that, it'll just, it'll go out and whoops, come on, and says bad request. That's all it'll ever do because I'm not authenticated. So let's look at a little bit of what's actually going on. Now I'm going to look at basically a structure that is very similar to the RSA and Diffie Hellman, but it's called SRP for the Secure Remote Password Protocol. It was invented by Thomas Wu in 1997. And, well, let's look at it real quick. It should feel the same. We're doing a lot of the same kind of things we did with both with Diffie Hellman and with RSA. Chuck and Sarah agree on some public parameters, two and 13. Chuck chooses, now notice Chuck this time, chooses is not Sarah, Chuck chooses five and he calculates this value called V which is known as a verifier by taking two raised to his five, modding by 13 and he gets six. Chuck keeps the five and he gives the six to Sarah. And then the protocol follows this way. Chuck picks a random value, 11. He takes that 11, he says G to the 11, mod 13, that gives me seven. I send the seven across. Now notice I also sent the ID because this is an authenticated key exchange, not an unauthenticated, whereas with Diffie Hellman, so I have to send the ID to say, hey Sarah, I'm Chuck, right? Send the seven over. Chuck takes the ID and goes and gets Chuck's verifier and she computes that her, pardon me, that she grabs a random number B, raises it to, takes two to that power mod 13 and she adds in Chuck's verifier and that's what she sends back. Again, why? Because of this nice little fact. This is an asymmetric calculation. Notice they're doing two different calculations but it turns out they're really doing the same thing. Chuck does this calculation of B minus G to the X, A plus X mod in, he gets three. Sarah does her calculation, A times, the A she got from Chuck, I noticed it here, the B over here was the value gotten from Sarah, now the A is from Chuck, takes that, raises it, blah blah, gets three and that's the magic. They both now have agreed upon key and so this is very similar to a combination of Diffie-Hellman and RSA in the sense that you have authentication and you have this key exchange. I'm going to skip over that. Chuck and Sarah established this key via key agreement. Look at the structure, got a very similar structure. I've got these values and they're bound together by some mathematical relationship. Given three of the values of that mathematical relationship it's very difficult to do the third, to get the fourth one. Similar to the same thing that we had with Diffie-Hellman and with RSA. This is actually called the SRP problem, it's linked to Diffie-Hellman which I already showed was linked to discrete logarithm. In this scheme Chuck and Sarah only trust each other because they each hold a part of the binding relationship. That's the biggest difference between this and then just cookie cutter RSA. In cookie cutter RSA Sarah owned all the binding. She owned every bit of it. She had to pass some of it over to Chuck in the process of the protocol. Here this is completely different and now that they, since they both share a piece of that binding relationship they actually get mutual authentication. This is a really nice type of scheme when I have a closed system. I can have on this now, I can say Chuck here's your password and Sarah here's the verify for that. That x equals five is called the password. Now I can actually do a mutually authenticated key exchange. Here's some of the advantages of using something like SRP and application level security. We got mutual client server authentication. In HTTPS you do not get mutual authentication. You either get one way or you get one way twice. Typically you only do one way because typically Chuck only needs to know who Sarah is because Sarah's the all-comer. She's the bank, she doesn't care who Chuck is. She wants people to come to her website. This is different. These guys, I only wanted them to talk to each other. So the mutual client server authentication ensures that both of these two are only talking to each other. Then I also have a mutual user authentication. That was the password that was passed back and forth between the two. This ensures that the application is actually acting on behalf of a specific user. Notice that I'm carefully distinguishing between those. HTTPS tends to do half of the top one and does nothing on the bottom one. That's purely applications. We all do that in different ways. But HTTPS has nothing to do with that. This authentication is using what's known as a zero-knowledge proof. Now this is pretty cool. I'm not going to do it justice. I'm not going to try to describe it too terribly in depth. But the basic idea is this. Chuck, if you remember, Chuck got five and he calculated V and that's what he gave to Sarah. He did not give her the five. The five is his personal private password secret. He didn't give it to her. And she never knows it. And look at almost all authentication schemes that you've done with HTTPS. What did you do with the password? You sent it right across the wire to the server. And hopes that the server treated it nicely. That's all I got to say there. There's two problems there. One is that anybody who can see the password and anybody on the other end gets the password. Hopefully they treat it nicely. But this zero-knowledge proof, the password never leaves the client. Authentication and encryption are in the same layer. This is an injection position to HTTPS which has something called the channel binding problem in that the encryptions happen at the transport layer and the authentication of the users happen at the application level. And those two things, there are schemes to try to bind those together. In this scheme, they were the same thing. They were automatically bound together. Single entity trust model. I wrote the library on here. I wrote the library on here. Who Kim Young L has, he doesn't get to see it. It's only me. I'm the only person who knows about it. Another thing that's kind of nice about this is that it'll change a little bit of the way you think is that I'm not going to... I didn't show any of this, but the security's completely orthogonal to the API. The API I used here was a very simple JSON-RPC type thing. It could just as easily been REST. It could have just as easily been GraphQL. I didn't care. But the key is that the security, I get all of this security, and I never had an authentication token in that package. I never had any type of security tokens in any of my API. Because if you think about it, they really shouldn't have to be there. We live with it because we think we have to. But wouldn't it be nice if when you built your API, you did not think in terms of what tokens do I need to be passing and taking care of and checking, et cetera. That's SRP in general. My solution that I've got here running, by the way, that means that this is a framework in iOS here, and it's an Elixir, or it's actually got some early libraries as well, running on here. I also, it's an ephemeral key with flexible session management. Make it very easy to flush the keys, re-key, auto-reconnect on stale. Another little minor one, but yet here it is. In this scheme, the client stretching happens on the client. Pardon me, the key stretching happens on the client. And if you think about it, that means you get to leverage that on the thousands of clients instead of having a server that has to do all the key stretching because as soon as you do that, there's everybody from there, let me just quickly say key stretching. The best way to think of key stretching is just a slow hash. It's simply there to make it to where somebody who tries to do a dictionary rainbow attack on a set of passwords that they might have gleaned has a hard time doing that because every time they do the hash, it takes them, say, 50 milliseconds or more. It takes them half a second. It slows them down. So here I can do all that calculation on here rather than offloading it to the server. Traffic blending, that's showed. Replay protection, I don't care, normalization. So here's the cost that I had on the elixir side. It's basically that one thing there. I put one middleware in there at the top. What it does is the request comes in, reporting this, yeah, this is, as the request comes in, it unpacks it, hands it to the next layer. The next three layers of this are exactly the same as they were in the other two. They do their thing, it percolates back up as it's going back out the door. This SRPC LA handler encrypts it. There's one other little thing there, but that was just some bookkeeping I needed. So great, this is SRPC. What else could I do? Well, there's lots of password, this basically is a password authenticated key exchange. There's lots of those out there. You could look at other ones, there's SRPs one, there's a slew of others. Another thing you could do is you could look back at that structure and you could say, if part of the problem was that Sarah had all the knowledge and Chuck had none, why don't I just put the public key on Chuck and go from there? You could certainly do that. You could do that with something called the needle and shoulder, station to station, and a slew of others. Again, if you go to cryptography and really start to get into security, you will not die of starvation, you will die of indigestion. There's lots of it out there. Lots of options. You can do that. The reason I prefer this is that I bind it, that it makes key management connected to a user's password, whereas if you did it this way reflecting here, your key management is that you're having to generate RSA keys. Okay? There's also a slew of other things that don't fall into either of these two categories. Again, it's indigestion, not starvation. This is the demo that I got here. I made it available so everybody wants to look at the code, that's fine. But I actually have another demo that's Elixir only. The problem with this demo is you've got to have a jailbroken iPad and you have to know Xcode and you have to know iOS and who in here wants to be doing that, right? Nobody. So the other one is Pure Elixir, the one on top. Thank you.