Live from Las Vegas, it's theCUBE, covering Knowledge 16, brought to you by ServiceNow. Here are your hosts, Dave Vellante and Jeff Frick. Welcome back to Knowledge 16 everybody. This is theCUBE. theCUBE is SiliconANGLE's flagship product. We go out to the events. Last year we did almost 80 events, probably do a hundred this year, Jeff, I don't know. Michael Hubbard is here. He's the Vice President of ServiceNow, Inspire. Michael, welcome to theCUBE, Inspire us. Thank you. That's what I get to do every day to some of our amazing, amazing customers and prospects. What is Inspire? I hear a lot about it, but I'm not really sure. So for the last year or two, we've been receiving invitations to truly step into some of our customers and prospects business transformations and we're getting inspired by what they're trying to do and changing the way they operate fundamentally as a company. And when we see an opportunity for our role to inspire the rest of the market, to inspire the rest of the customers we haven't touched yet and actually change the understanding of why we exist as a company, I get the honor of leading a team that just focuses on those invitations and goes and does what it takes to make those customers successful, mostly through strategy, insights, advice, as well as giving them tangible sort of Super Bowl commercials that let them explain to their organization what they're trying to do because we're a cloud company. We can simply spin that up, build it, give it to them, let them go shop it around so that they get momentum to achieve that outcome in their business. So it's essentially a consultative service that is not a four-pay service. Correct. It's something that you offer for your top customers, is that right? Correct, correct. It's an investment, right? And it is about finding the roughly 1% of customers that are really trying to do something inspiring and helping them be as successful as possible. Really, so how does one qualify to be an inspire recipient? Inviting me on theCUBE is a good start. So, but that's the right question, right? Because we're burdened with too many, the blessing of too many opportunities, too many adjacencies as a platform that could do so many things in the world. So how do we prioritize? The first thing is about finding leaders that truly have a passion and a commitment and the authority to drive a big change because no change is easy. You will have to change career paths for some of the employees, processes for some of the employees, maybe governance and compliance and attestation expectations of how business gets done, that's hard. So we're looking for a person who has both the power and the vision to change the way they go to market. And then secondly, we want to make sure that if that change happened, it would be considered meaningful if we were a part of it. That's all we need. So strong stomach, right? And obviously a substantial investment in service now so they could leverage some of the changes that you want to bring forward. It would be unwise for someone to gain our advice if they didn't think our platform was the right way to achieve at least a meaningful portion of it, right? Because our expertise is rooted obviously in where we come from and where we spend a lot of our time and the insights of where our company's going. So if you think our vision as a company is relevant, then we might be a good person to help you with your vision. You're biased and you're not shy about saying that. I would say we definitely aren't atheists. We have religion, right? We have a religion and we're going to apply that religion to what you're trying to achieve. So if you think there's synergy there, then maybe we're a good fit to help you with that. And the big difference between worrying about whether we're biased or not is think about how accountable we are because when we give you this advice, we're the ones who have to deliver on it, right? And that's always been the big challenge between the folks whose feet don't touch the ground in terms of telling you what you should do, then the folks who pick up that vision and try to execute it but they weren't there for the inception of it. We want to break that cycle and bring it together. So how much of the advice that you're providing your customers is specific to leveraging the platform versus sort of business process changes and other types of initiatives that are transformational? So we start with an outcome and we tend to start with an experience. So an outcome might be faster time to acquire knowledge, reducing rate of churning the employee base by improving net promoter score of employee satisfaction. It might be margin expansion, it might be revenue growth, who knows? Once we know what that outcome is, then let's try to think about the moments where it's most tangible that the outcome of this transformation is going to deliver a better version of that moment. And that's what I talked about with those Super Bowl commercials, the two-minute sort of experience that lives on your mobile device that makes you want to drink that beer or be that guy or buy that product, be in that environment. So we create that environment with our labs team, we confirm that that's aligned to the future state they want, and then we back into all the things that's going to take people process technology, architecture, governance to achieve that. So a lot of business strategy stuff that you're doing as well. I wouldn't say we're helping customers define their business strategy, but if they have a compelling before and after statement, we want to be an enabler of that. Yes, that's a hard job because almost everyone we've had on, at some level, qualifies for what you're describing. And I would also imagine you definitely want to be a client, push every religion, but there's always that problem if people don't have skin in the game, when it comes time to get hard work done, usually it may be a little more motivated if they have skin in the game. So where that skin comes through, they already made a big investment in service now, how do I get more out of that investment? How do I leverage that investment across broader ecosystem or get those benefits that I realized here, you know, there, there and there? I'd imagine those are pretty important things to consider. Absolutely, so commitment is a crucial word, right? And I'd say we spend half our time with customers that they're not customers, they're prospects, that are considering going on a journey with us, a journey to everything as a service, enterprise service management, the service revolution, all the catchphrases I'm sure you've seen throughout this week. The other half are customers that have started on the journey. They're CIO, they're CFO, they already have this asset in their software estate and we're helping them sweat that asset more. In both cases, it comes back to finding the person that I shake hands with and look in the eye and we have that social contract that frankly means more than a commercial contract that if I help you and I make you successful and I show you that I truly understand what you're trying to achieve, why wouldn't you want me to help you with it? So we really don't have challenges around conversion and follow through on the advice that we give. And the role is the CIO, is you dealing with CIO, CXOs? So yes, primarily today we're dealing with CIOs and CTOs in mega organizations with six to $10 billion IT spends. We may be in a division, right, a divisional CIO. But we're also starting to get the CROs, right? Because what if we could take the IT practices that help an employee engage in services and apply them to the way a customer consumes services. So I sat with a CRO shortly after the recent Salesforce outage, talking about how he can better quantify the work of his 2000 application engineers. It's a software company. Because when he goes to the CFO and wants to talk about needing 50 more engineers to help capture more revenue, the CFO says, well, what are all the 2000 doing? He says, I have no idea, right? So can we be the system of record that answers what those people are doing for their customers? What does an engagement look like? Take us through the anatomy, start to finish. Yeah, so obviously there's a lot of work up front to make sure we're in the right place with the right person, solving a well understood problem. So qualifying is huge for us because there's only 40 or 50 of us and we've got a blessed amount of opportunity in the market of people we could work with. So qualifying is important. Once we get to the point that we have that social contract, that handshake agreement that says, I understand your outcome, I'm going to give you a plan to achieve it. And then together we're going to go get that outcome. The next step is really bringing the rest of the team that that leader depends upon, right? The inclusive doing it with his organization, bring that team together through workshops, strategy, tactics, operating model. Make sure that they understand it. Have a rough draft of a plan, socialize that plan. Once it's understood among the leadership team, let's help with the organizational change management by pushing that out to the larger audience. In parallel, let's prove it, right? We're a cloud platform. I should not deliver you a PowerPoint presentation of your future. I should give you a glimpse of it, right? And it should be on your mobile device. And that experience is that, is one of those deliverables. Now let's give you a business case that says we believe it's going to make money, save money, reduce risk in this quantity and these time frames as follows. So one of the deliverables actually code some capability. Correct, correct. We tend to be a low-code company, right? Being a Paz platform as well as a SaaS company. But absolutely, we're delivering experiences that allow that visionaries, CIO, to show his or her stakeholders why all this change is worth it. Because on the other end, something good's going to come out of it.  I'd say on the average, they're about six to eight weeks. It just takes that much time to manage all of the mutual understanding of us learning than us advising, than them accepting. And at the end, it really is their plan. It's not ours. I don't think that's much time. I wrote down six to eight weeks and I said that, that's maybe too aggressive, but you're saying on average, you can complete that. So that presumes that the client is putting forth the resources necessary to get it done, the meetings, et cetera. And you're picking a time when everybody can put it together. And so these are not free. They actually consume the most valuable resources these organizations have, which is probably their strongest leaders and the people who understand their current state and their customers and their problems the best. So it's by no means free to these CIOs and they understand that. Yeah, they're not writing a check, but they're spending their time, which is more valuable. You can always make more money. You can't make more time from these precious resources and they get that. And when did Inspire, when did it start? So it actually started in January of this year. So I've been with ServiceNow about eight months. Recently we, ServiceNow and our leadership team got really serious about being able to do this for customers. And I was fortunate enough to join the company to help build out that program. And so we're in our freshman year, right? We're learning a lot and we're taking those learnings and we're putting them into what we call the customer journey. So if I've got these insights about what some of our most ambitious customers are doing, how can I translate those insights into a scalable knowledge base by which every customer could learn these lessons the easy way versus the hard way. And that's what the customer journey is, which we shared a lot of here at Knowledge This Week. How many of these have you done? So we've done about 30 so far. We'll do about another 20 this year. I don't think we'll ever get to more than that a year. That's a lot, 30 and five months, just getting started. We are a very surgical consulting team, meaning that we want to get in, do the job right and then transition to the team that's ultimately going to do the actual implementation. Then we stay on just in a governance and oversight sort of capacity, doing QBRs quarterly, helping out if something does go awry and learning what was wrong about the assumptions we made up front so that we correct that the next 20 customers. Really go back and look at the business case and say, okay, is we got it wrong? Is we got it right? Absolutely, value realization. Nobody ever does that. I know, I know. Like the weatherman checking the paper from last week. Exactly, value realization is so important as an industry, we're not good at it. And the beauty of our platform is if you turn on all the functionality, we could actually have that done for you real time just because the work you're doing is captured. The value hypothesis is going to be proven out for you or refuted for you right in the platform. So then we come in, make sure that that's set up, pull that data out and then we educate the market about that. Roughly what percentage, Michael of those 30 said, okay, the business case looks good. We're going to move forward? All of them. It's a matter of how quickly they move forward and with how much urgency. Because if we take a three year plan that has six or seven components in terms of work streams and outcomes, they might say, I'm going to do all seven eventually, but I'm going to start with this one. And this one is the burning bridge that I have to fix. But every single one of them has moved forward with taking a subset of our recommendations and implementing them on our platform. So obviously part of the qualification process is some kind of back in napkin business case where you have a high probability of success, right? Absolutely, because our most precious resource is the same as our customers, it's our time. You got it, you got to rig it. I say that, I don't mean it as a pejorative, but you better make sure that you're going to have a high business impact. Absolutely, qualification is super important, but we're blessed with an incredible number of customers that are coming and giving us these invitations and we've gotten pretty good already at getting right to the heart of, is this team able to solve the problem they have or are we the wrong team inside of service now to help that? Do they really need the product team, the business units? Do they really need our professional services to get in there and turn some of the wrenches? Do they just need education, right? Do they need third-party help from a partner to scale their staff? So you're coming to theCUBE, obviously you're not trying to stay stealth, but have you been presenting this week? Is demand now going through the roof? Are you sorry that you're doing that? So I get the pleasure of spending my time in two areas, one, this high touch, high cost of delivery motion that we've been talking about today, but the other half of my time is taking those learnings that are harvested and putting that into sort of a canonical framework that we call the customer journey, which is programmatically how do most people consume our platform, attain value from our platform? What are the major inhibitors to progress? What are the accelerants that help them go faster? And that's what we've been talking about this week at Knowledge, is helping people understand the journey. We've got some self-service tools that are available through our field organization for any of our customers to sit down and rather than having to come to me and my team, working with your local ServiceNow partner or representative, use some of these tools and say, this is where I am, these are the things I'm trying to achieve, this is what I should do next, how's that compared to other people?  So we've got that tool and that's really what we've been talking about this week at Knowledge. Ah, sounds like a fantastic program, really. Congratulations on getting it off the ground and really appreciate you coming on theCUBE and sharing that with us. A long time watch, your first time participant, so I'm very happy to be here. You're now a CUBE alone. Awesome, fantastic. Thank you, Michael. Thank you. All right, keep it right there, everybody. Jeff and I will be back with our next guest, we're live, from Knowledge 16. This is theCUBE. Right back. This is a tale of...


Hey guys, I just wanted to check back in with you I just finished up challenge number 12 in the Python challenge, you know like video series I've been doing and it had us go through like different evils evil 1.jpeg evil 2.jpeg and the GFX version of that Which is what we like parse through the data and all and there were other ones like evil 2.jpeg evil evil 3.jpeg and Evil 4.jpeg and like I saved a copy of them and I was kind of playing with them You know, there's evil 3.jpeg that said like no more evils the evil 2.jpeg That said that had like not jpeg.gfx and that's how we got to the gfx file But there was this weird one evil 4.jpeg that was corrupt And when I was playing with it a little bit more it's so I I I Was playing with it after the video because I want to look through more of the jpeg files to see if there were any other hints That I missed out on like during the video and well like while I was trying to go through the the challenge So evil 2 and like evil 3 are still pretty much nothing But it was weird when I got to evil 4 because the image like image module on Python couldn't open it Of course because it's corrupt so I tried to open up with Python and When I did I opened it up like a regular like Python file and when I read from it I got this weird thing I'm playing text Burt is evil go back I Don't know what that means, but I thought it might be interesting for one thing to you guys and I don't know what if it would come in handy like later in the Python challenge or anything So yeah, it's it's weird because I had it in my my desktop here And I never opened it up when I should have it was evil 4.jpeg because it's legit plain text Burt is evil go back there. There is no jpeg. There is no image to it. It's just Burt is evil And I'm speechless at that.  Oh, maybe you can piece this together more than I can but this is it Burt is evil go back


with DAV and I'm joined by Chief Communications and Outreach Officer Dan Clare. Today we're here to give an update on Patriot Boot Camp, DAV's new program for entrepreneurs in the military and veteran community. Dan, welcome. Thank you for joining us today. Thanks for having me. So before we get into what's new and what you're really here to announce, let's kind of talk about the basics. For those who haven't heard, what is Patriot Boot Camp? Patriot Boot Camp is a charity, actually it was an independent charity that DAV acquired January 1st and what we really acquired was an entire community of people, civilians, and military folks. But the program is designed to help people in the military and veteran connected community become business owners, business start new ventures. So it's a really exciting new thing for DAV. The program's actually been around for 10 years. It's a community of 4500 people and they're all there to help veterans, spouses, military members succeed in business. And so DAV hosted its first Patriot Boot Camp last month at our headquarters here in Erlinger. How did that go and what did you take away from it? It was a great event. I mean, we had an alumni, it was an alumni event, so we had people who were familiar with Patriot Boot Camp, but you could see kind of the success that they'd had since they'd attended their first Patriot Boot Camp event. And then it was kind of an accelerator for them to take them to a higher level. What I loved about the event, whenever we have an event, we have as many mentors as we have participants. So the mentorship that went on there was fantastic. And then we have a pitch ask give portion that I thought was really great because you're asking people to go ahead and pitch your company, pitch your venture to this group of people, ask them where you need help and tell them where you can help them. So all the people there in a cohort kind of become a network community themselves. So it's a really exciting event. And it really has, I mean, the people who participate love it and it really seems to help veterans and power veterans to become benefits creators, as opposed to where DAVs help them get their benefits. Now they're helping other people. And you mentioned that the first event was an alumni event. And I think it says a lot about the program that people keep returning once, twice, even three times. And they're still just as enthusiastic and still getting so much out of it. I know you also surveyed participants from this first event. What were the results of that? It was over 90% satisfaction rate. We're going to improve the food a little bit. Some of our stuff got a little bit of a knock. So people who participate in the future will have a little bit better grew up for you. But seriously, people were very happy with it. And what's great about Patriot Boot Camp is that community within DAV now, they're constantly trying to help one another. And I've followed up with some of the veterans who participated. And we plan to just keep going, keep helping each other out and seeing how far it takes us. So we have the next event scheduled. Tell us when that is and what people need to know. It's October 20 through 22. It's going to be here at DAV National Headquarters near Cincinnati on the Kentucky side. It's going to be a full event for new founders. So it's going to be a two and a half day event. Pretty intensive stuff going on there. A lot of mentorship. More mentorship probably than even in the alumni program. But we're going to connect people with legal resources, marketing. We're going to help people with scaling talk about venture capital, talk about traditional forms of seeking funding for your business, bootstrapping. We're going to try and give people all the resources they need to succeed through the event. And not just giving them the resources. It's hard to say in two and a half days what you can do. We're going to take them to another level I think in two and a half days. And after that we're going to still be there with our caffeine connects with alumni events and other things to kind of help people keep going along their path. Well, I think like you alluded to before, this is really about community. And so there's a lot you can can do in two days, but it really is a lifelong kind of support system. Can you tell us where and how people can apply for the next Patriot Bootcamp? Sure. And whether you're applying or you just want to learn more about the program, you can go to patriotbootcamp.org. We're working on the website a little bit, but you can register right away through the site. Again, it's October 20th through 22nd. It's here at National Headquarters. We're going to have a lot of fun along the way. But I want people to get involved. We do virtual training in the form of caffeine connects. We do at least one of those a month. So people can tune into those two and find more resources on the website. And who can apply for Patriot Bootcamp? That's a good question. It is open to the veteran and military connected community, and that includes spouses. So whether you're a spouse who is moving from town to town, you find out that's the best way for you to maintain your professional success while you're spouses in the military. It's for you. Disabled veterans, of course. Other veterans, you're all welcome to apply. We're really looking for this class for people who have done some of their homework already, who have an EIN already, and who have a website set up. So we're hoping for that, but it's not an absolute requirement. We're looking to help 50 people through the program, and we'll have 50 fantastic mentors there to help them. And it's kind of welcoming them into a community at that point. And the application deadline is August 29th, is that correct? I think it's August 29th, yep. Okay. And I also think it's important to know that there is no cost in applying and participating. That's correct. No cost to apply, no cost to participate.  But beyond that, we're going to take care of your meals, and we're going to try and get you a discounted rate for hotels and stuff like that while you're out here. Make it as affordable as possible. So it takes a lot of people to pull off a Patriot Boot Camp event. You've mentioned mentorship a few times. For those who are interested in supporting this in other ways, maybe in mentoring, how can they learn more and who should they contact? Same thing. I mean, you can go through the website and sign up for information. If you're specifically interested in being a mentor, I'd ask that you email us at infoatpatriotbootcamp.org, and we'll follow up with you specifically. We're looking for people who have specific skills helping entrepreneurs. So if you're in marketing, business leadership, funding, whatever, those are the kinds of skills that we're looking for. Great. Dan, is there anything else you'd like to add? No, just I want people to get involved and sign up. If it's something that you can do, if it's not something you're interested in personally, please let your fellow people in our community know because we want to get as close as we can to getting 50 people out here and the people who participate in the program to see the value. So I'm hoping lots of people sign up. Great. Thank you so much, Dan. Again, visit patriotbootcamp.org for more information, including how to apply for the next Patriot Bootcamp event, and follow DAV on Instagram, Twitter, Facebook, and LinkedIn for updates.


We're going to show a couple of nice examples of inter-nuclear ophthalmoplesias. This patient had subacute bacterial endocarditis with a bacterial abscess in the brainstem. Ductions and gays are fairly full looking to the right, but look at this. When looking to the left, his right eye does not AD duct well, and you can see these jerk AB ducting the stagmus of the left eye. So he has a right inter-nuclear ophthalmoplesia. Again, the components are medial-duction abnormalities of the ipsilateral eye and AB ducting the stagmus of the contralateral eye. Now these are really brought out with saccades. This is a nice technique to bring out an INO. Ask the patient to saccade quickly to the right as he's done here, normal to the left. Now look at the lag of the medial-duction of that right eye here. See how it just sort of slowly drifts across? That's a nice way to bring out a subtle INO. I think it shows up fairly nicely. Look at the left eye. You can see the AB ducting the stagmus, and that medial-duction of the right eye just slowly drifts across. You can also do this with an optokinetic drum or strip by moving the target opposite in the direction of the suspected gaze. Now here's another example. Fairly normal when looking to the left. Now look at that left eye, medial-duct slowly compared to the right eye. And again, I think you can see the prominent AB ducting the stagmus of the right eye. This patient has multiple sclerosis. See here, if you were to just look at ductions, you'd think everything was fairly good. You need to bring saccades into action to bring out those subtle INO pleases. It's a very nice technique.


Hey y'all this is Chris and Toronto and you're watching Trucker Josh V-Lugs on YouTube. Port Saskatchewan, right where we went to bed, an allergy fit, right now and then. Usually it's the spring when I have this, but I feel another sneeze coming. Let's just open the windows and get some fresh air, right here. It is turned right on. Carriage drive and then, turn left into underpass. Made at this truck stop here at Cairnport. It's right next to BriarCrafts Bible College, a little gravel parking lot and a store that closes at night. So it's not a place I would stop at regularly in the winter, because in the winter time I like to have a 24 hour truck stop where I can go into if my truck suddenly decides to stop running at night when it's minus 30. This is probably why I haven't really noticed it here before, but Cairn filled me in that it was here. Thanks, Cairn. This GPS does everything. Cleaners, turn left on. Trials come into highway. Highway 1. Absolutely. Absolutely. Absolutely. Absolutely. Good call, Cairn. I want to go home too. Let's turn on to TransCanada. This will take us home. We're just under 700 kilometers from home, more of a 400 and some miles, more than 50 miles or so. It's good to be home. And we now get to test out our new roof. Okay, and somewhat of a good rainfall, the camera's not really picking it up, but the rain's coming down on, decent, decent amount here. And we got our downspots laid out. You can fold these up, you can see there, water's flowing out real good. So we've got four downspots on the front, they all seem to be working pretty good. This is the first test that I've seen, and this is so much better than the rain just falling off the house right in front, like wherever it goes. At least we can control it a little bit, because here you can see like where it used to fall down, because there used to never be any gutters, right? So there's like this almost trench in front of the house. On this side here, they got this coming down here, working really good. Let's go check the back. So excited to test this out. This one doesn't come down as hard, like you can see it in here. Not too much, but that it wasn't quite level. On the back here, there's only one downspot here and one on the other side, and the other side seems to carry a lot more water. So I guess it's not quite evenly balanced, but it's OK. This side here, this side you can see is just given, right? Comes up to there, and then this one here that sticks way into the middle of the yard. That comes up from our screen room there. Kind of inconvenient, yeah, but it's the only way they could really do it because of our gas pipes right there. Comes down and into the backyard there. But this is detachable right here. You can take that off of there and then put it away for when it's not raining or when we don't need it, when we need to mow the lawn. At least it gets the water away from the house. Oh, we need to take the barbecue back inside here. Oh, we better do that right now. And the downspot on the front on this side is giving it a two. So we're really happy with it, really happy. Let's get this barbecue inside of here. There we go. Only got a little bit wet. But how's this for a fashion statement, eh? Camo jacket, jeans, reindeer slippers. You only wish you were as cool as me right now. So this trip was good. I know we sort of cut from the fuel islands there in Balgoni to home here. You know me, when I'm on a road home, I have a one track mind, just a beeline straight here. Starting to get cold out, though.  August has been very rainy and cold, which is different because usually August is very hot and dry. Now it's September already. And now September sort of feels like October. It's getting colder faster. I was pretty sure I was told that the climate is supposed to be warming up. Something about some kind of global warming thing. Still waiting, still waiting. They say one day my property is going to be the tropics. I think that'll raise my property value quite a bit. If you think about it, if everything's south of here, it turns into this desert that they say it's going to. A lot of people are going to want to be living around here. Property values are going to skyrocket for me. Just got to wait for the right time and just pounce on it, right? I mean, that's if it was true. You know, if the oceans were really rising by 100 meters or 100 feet, is that what they're saying? They're going to rise by something like 100 feet or something in the next century. If that was really true, there would be no way that you could get property insurance for oceanfront property. There would be no way that these big shots would be buying oceanfront property because it's all going to be underwater in a few decades. So who would buy a house that's going to flood right away? No, it's not.  That's okay. It's a little more rainy than usual too, which is kind of nice because we actually get a nice green lawn. Last year at this time, I didn't have to mow the lawn after mid-August. Mid-August, that was it. It just didn't grow because there was no water. This year's just, look at this. Rain, rain, rain, rain. Well, that's fine. So while I'm at home now, we're having a little family get-together tomorrow or on Saturday. I probably won't be filming that or what. I'm just going to enjoy the weekend. It's nice to just enjoy everyone's company. I think there's like 30 to 40 people coming. Then Sunday, we're sort of relaxing, recovering. And Monday, I go to buy new drive tires on my truck, which should cost a couple of thousand dollars. So I'm not looking forward to that part of it, but I am looking forward to getting new rubber on the truck. Now, I am going to be going with Retreads. I'm not a fan of Retreads. I can, I hear you guys, I hear you in the comment section. I agree with you. You know, I was joking around with my buddy Moses online saying, yeah, living life on the edge, buying Retreads. Retreads, the Retread technology has come a long way in the last few decades. I'll just say that in my defense, come a long way, but it's a lot cheaper. So, you know, for under $3,000, I can get all my drives replaced for now. It's just because I just spent $20,000 into this roof. Got other expenses. Just trying to save a few pennies right now. And we'll see if I end up shooting myself in the foot with that attempt at saving some pennies. I might regret it. We'll see, but hey, you can watch me and see what my luck is with Retreads. And if I have terrible luck with them, then you know to stay far away from them. And if they work well for me, hey. Maybe it's true that they've improved them. Does that remember back? Like, even when I was a kid, back when my dad was younger driving truck, you'd always see these Retreads. They'd fly off the tire and be laying all over the road. You don't see that anymore. Not as much, right? Am I right? And maybe it's just me. I don't know, I don't notice it, but. We'll see what happens. I'm gonna give it a shot. I'll be your guinea pig, okay? You wanna know what Retreads do and how long they last. You just keep watching my videos. You subscribe to my YouTube channel and you can watch and see how long they last. I'm gonna keep track of it. And just for the record, my truck has 1,030,000 kilometers on it right now. That's about 625,000 miles somewhere in there. We'll see how long they last. What I would like them to last, I'd like them to last over 1.3 million. If I could get it to 1.4 million, that's 400,000 kilometers. That's 250,000 miles. Between 200 and 300,000 miles, if I can get them to last that long, I'll be very impressed with these Retreads then. That's how long I would expect a good virgin tire. A tire that's like brand new to last. But you know, if you're keen on the environment, one good thing about Retreads is it is sort of like recycling, uses less materials, less resources, and it sort of reuses the tire. So it's better for the environment in that way. That's not why I did it. But if you like the environment, hey, a little extra perk for you there. So have I shown you guys Britt's new hanging swing yet? Her dad bought her this for her birthday this year. I don't think I've shown you yet. Let's go sit on it. Let's go make her jealous. She's inside watching her show right now. I'm working on my vlogs. I gotta finish today's yet. It's all the way at the end over here. She's in there, right there. You see her? Oh, her show's over.   She can't hear me.  She'll probably be out here right away. Yeah, so this is what her dad bought her this year. It's like a hanging swing. Pretty neat, eh? He's getting a little chilly to sit out here in the mornings now, but in summertime in the mornings, oh, we come and sit out here. First thing in the morning and have our coffee. I really like it. I probably like it just as much as she does. I thought for sure she'd come. Nope. I guess I'm sitting out here by myself all alone. All by my own, so I'm too cold for her out here right now. But anyways, if you're still watching, thanks for listening to me ramble. It's time to enjoy the weekend now. So if you haven't already hit that subscribe button, we make a new video every day, mostly every day. I skip some days and I don't always make videos. I usually don't film on or do a lot of work on Sundays, but we make a lot of videos. We make a lot and we'd love to have you as a part of the crew here. We're trying to get the channel up to 100,000, but it's up to you. I'll leave that in your capable hands. The subscribe button is on my page, on the YouTube page. If you found me on Bitshoot, you can subscribe to me there if you want. They're just mirrored off YouTube. My YouTube channel is where I post primarily. It's called Trucker Josh Vlogs. Go to Google, just type in Trucker Josh and all my stuff will pop up there. Sort of my corner of the internet. Just type in Trucker and I'll pop up. We're trucking. Thanks for watching. I'll see you tomorrow. I told you she was gonna come.  My wifey senses we're tangling. I was just telling them. I wonder how long it'll take. Who do you got there? Nothing, I'm just holding this close because the zipper's broken. Oh, I thought you had one of the pups. No, none of our dogs are this small, not even Frank.


What's up everybody Jason here from jazby's case breaks dot com We just filled up 2020 tops tier one baseball 12 box case break picker teams number 18 And again, you get some really nice stuff delivers two autograph cards and one relic per box and each case guarantees a one Guarantees one rare tier one autograph All teams bought straight up. There's no fillers here and Last bomb ultra actually no, I don't have last one module David a little real star right there Reds were last team right there Photographer at the top forget that these ones are just right Shown right away. I've got Bernie Williams to 80 to start us off for the Yankees Last teams advisor opponent R&B. Yep. That's what I figured would happen, right? You got a relic here Chris sale. I want to be able to top load everything Fernando Tatis Jr. A little chip here in the corner, but other than that, it's pretty strong Padres, it's what a Nick Patrick Corbett The Washington Nationals Chris Walker with that one All right first box AJ puck and Sean Anderson for the Giants 299 AJ puck again this time autographs six out of 60 Next box two autographs Bernie Williams Patrick Corbett, but yeah, if you missed the first one with Bernie nice little Patrick Joey Vada 25 Cincinnati Reds going to David Chan, which was last spot mojo Chris Paddock for the Padres It's going to Nick and Reese Hoskins 32 out of 100 Philadelphia Philly is going to Kyle Next box got Nick Sensel for the Reds You Chang rookie For the Cleveland Indians Chris Walker. Oh Look at that I'm a little Ronald Acuna Jr. Didn't really have himself the best and I'll see a series batting average, but Grace did make it there and I'm sure they'll be back soon in contention in the future years There you go Matt With the braves and actually let me flip this is not a rookie card, but it's all we have for 75s right now Very nice Dustin May to once 395 For the same those Cardinals Jack the Balan Jack Flattery Aaron Hicks to 299 for the Yankees and a Mark McGuire 17 out of 25 Or sorry seven out of 25 Same those Cardinals, it's going to Jack all right Halfway through guys after this box Carl Yostramski The Boston Red Sox It's been a Matt L Nola a couple of white chips on the corners there Phillies it's going to Kyle Taylor Ward Aaron Pettit the Angels and Brandon McKay rookie to 299 for the Rays Tom Jones All right halfway through guys. Oh, we got Aaron judge John means to 299 and Victor Robles to 299 Washington Christian Yelich, that's right Rex. Maybe something big right now Raleigh fingers Joe's arch nemesis. They don't want to sign for him at the National the first year we went Joe's like I can't get an autograph. He's like no That's so funny Joe was devastated that day ever since then Hater all the fingers Zach Wheeler Mets Richard that one four left Chris Paddock Louisa rise that is for the Minnesota Twins Conrad of that one and we got a little Gavin Lux very nice 13 out of 299 Can't believe it Rex That that they were just gonna choke again. All right, so Matt library with the Dodgers NCRT for the brace Mike yes Trump ski Paul de Jean and a third autograph Cecil fielder For Detroit a little bonus auto for you guys.  The one thing I will give it to the winner though whoever wins The fact is that both teams went to game seven and played in seven straight days right Every game was like all straight, which that wouldn't usually happen So it kind of made you really rely on your bullpen And even though maybe people don't think that baseball can be tiring Mentally to Seven straight. You don't even get a day off I think they made it pretty pretty fair Pretty fair. And yeah, I know why you said that remember he said that it was kind of an exhibition season, but I'm sure he was just saying that because he didn't know if the Dodgers were gonna win or not I don't know. I would still count it regardless You know because I mean like I said everybody agreed to it. It's not like nobody said no we don't want to do this and There was to at least what 50 plus games Michael brosal Like I said the playoffs. I think we're pretty designed pretty fairly Three game series by game series seven game series and then we'll serious Shane Bieber. All right, last box guys Well if like the Houston Astros somehow would have went and they would have won Rex I mean that would have been a summary of 2020 right there and probably Probably like rioting honestly But the fact is that didn't happen, which was pretty good I would have a redemption little Jeff McNeill and you leave Jury L Houston and a Matthew. All right, and the last one is a redemption guys Good luck. Oh, it's a dual autograph of Carter Keeboom Which is Washington Nationals and Juan Soto who is also a national Wow, there you go Redemption dual autograph Carter Keeboom and Juan Soto that it's going to Chris Walker and the Washington There you go. Very nice And just like that guys that was a 12 box case break of tier one baseball All the hits being top-loaded here for you guys Very nice Ronald Okuny in the beginning that we got which was pretty nice That's how T's relic in there, too There you go that one right there 25 was pretty awesome So I appreciate it guys five stars really close and I think it's an R&B and it might be filled up now That's Jaspys case breaks.com


So, we've talked about two different types of cryptography, we've looked at symmetric key cryptography, where we have a shared secret key, both entities, A and B must have the same key, one encrypts with a key, the other one can only successfully decrypt if they have the same key, and of course this key must be secret, and then we looked at public key cryptography where we have two different but related keys, and we encrypt with one and encrypt with the other in the key pair, and we've seen public key cryptography used in two different ways, one for confidentiality, I encrypt with your public key such that only you can decrypt with your private key, and the other approach is for authentication where I encrypt with my private key as a form of signature, I sign the message with my private key such that you can verify it came from me because you can use my public key to decrypt. We want to go back and address the issue of how do we get the keys to other people, and not just how to get the keys to other people, but what's the best way to use keys to keep track of keys for both symmetric and public key cryptography, so this is about key management, we'll go through some general issues with key management and then we'll look at how we can distribute secret keys for symmetric key encryption, and we'll see that one way to distribute a key, and when I say distribute I usually mean distribute across a network, communications network, one way to distribute the key is to encrypt it, but that leads to this recursive problem of if I need to encrypt the key with another key how do I distribute that original key and so on, so we'll see the solution for that, and the other way to distribute keys is to make use of public key cryptography, because one of those two keys can be public, we can use that to encrypt, so we'll see how to distribute secret keys using symmetric key encryption, and then how to distribute secret symmetric keys using asymmetric encryption or public key encryption, and then look at a related issue of okay if you how to get someone else's public key, and that will lead us to something that's relevant for websites is certificates on websites and how they distribute keys. Some challenges with key management of course is how to share a secret key, so secret is used for symmetric key encryption, both sides must know the same value and no one else should know that value, so how to distribute or how to share a secret, that's one challenge we have. With respect to public key cryptography, another challenge is how do I get someone's public key, it sounds easy just publish it, okay I have a public key I put on my website, but then we have a problem if you want to obtain my public key how can you be sure that it is my public key and not someone pretending to say it's Steve's public key, because if they can do that then they can defeat some of the security mechanisms, so distributing public keys is a challenge. The other thing is when to change keys, and we'll see that many schemes will take advantage if we don't just use one key forever, especially for symmetric secret keys, you may use one key and use that to generate another key, and then use that other key maybe for five minutes and then change the key, choose another random key, so how to change keys and how often should we change keys. Now just be aware when I say secret key I refer to a shared secret key used for symmetric key encryption, not a private key which is using public key encryption, so really three names for keys, a secret key, a public key and a private key, the public and private keys go together in a pair, the secret key is that shared by two entities in symmetric key encryption. Some of the things that we'll assume or the principles that we'll work on when we look at some of the solutions for key management are that we will assume that there are many users that want to communicate in most of the scenarios we consider, and they want to communicate securely across the network, so by securely here they want to have confidentiality, they want to have authentication, so they need to use cryptography, so they need keys, and many users mean it's not just two users wanting to communicate, if it's just two people wanting to communicate usually it's not so hard to distribute keys, but it's when it's hundreds of users, thousands or millions of users wanting to communicate across the internet for example, then the challenges that will go across become relevant. So let's assume that there are lots of people, lots of users, and they all want to be able to communicate across the network, and let's assume that an attacker can intercept anywhere in the network, so we'll show some pictures shortly, but some communications network assume the attacker can intercept from where I send the message, I send it from my computer, and it goes across the network to your computer and you receive it anywhere between our two computers, somehow the attacker can intercept and get a copy of what was sent. Somehow, well there are different techniques and I think most of you know one way to intercept messages, if you're using Wi-Fi, when I'm sending wirelessly from my laptop to the access point, because it's broadcast nature of communications my signal propagates in all directions, so when I transmit up to the access point, someone sitting in the backer room can intercept that message, so it's quite easy to intercept in a Wi-Fi network. If it's a wired network, how do you intercept someone else's data? Let's say I'm using the wired ethernet cable that plugs into the wall there and goes out to the gateway or router for SIT and out to the internet, how would you try to intercept my data communications? What would you need to do? Change the switch so if you could maybe before I arrive for the lecture, maybe the socket here that the cable plugs into, maybe you put a special device inside that socket, a small say embedded computer that reads everything that comes into that socket and then sends it on across the rest of the network. So you need some way to tap into the link or the network and there are different ways to do that with wired links. You could maybe find the LAN cable and again insert some small device which I would not notice that receives the signal, uses TCP dump or similar to record the packets, save them or send them somewhere else and let the data pass through so that I don't notice that it's not getting through, that it's being intercepted. So with a wired network you need some physical access to the network. Maybe if you could get access to the computer center, the switching room down on the third floor, this cable goes to a switch down there, if you could sneak into that room then again you could intercept the traffic. So again it's under a number of conditions, it's possible for an attacker to intercept either on a wired or a wireless network and we'll assume that they can. The other thing that we don't want is we don't want to have to force our users to manually interact to exchange keys. So we have say 40 people in the room, let's say we need to exchange keys with each other. By manual interaction I mean go up to someone and say okay let's write down a key, some 128 bit value, write it on a piece of paper and give it to the other person and they keep that secret. This manual exchange of keys is very inconvenient. What we want is some automatic exchange of keys such that the human isn't involved but the piece of software running on their computer does it for them. That's what we would like, otherwise with large networks it's just not going to be manageable. But we will see that in many cases we require some manual interactions but we want to limit the number of them. So the physical exchange of keys is possible but we don't want to do it so often. And finally a principle that's used and we'll see it used in different schemes is that the more times we use a key to encrypt our data, the more chance the attacker for discovering that key will make that assumption. That is let's say I have a key and I encrypt every message I send using Wi-Fi from my laptop to the access point. So every packet that sent is encrypted with that key. And the point here is that I would like to change the key on a regular basis because this principle is saying that we'll assume the more times I encrypt using the same key, even though the data is encrypted it gives a higher chance that the attacker may be through to some weakness in the algorithm, higher chance for them to find the key. So that suggests change your keys on a regular basis. Don't use the same key forever just to be safe. So before we look at how to distribute keys let's look at the problem of especially manually distributing keys. Let's consider a example network. This picture shows 10 hosts, 10 computers, A through to J. And connected via some switches, these SW rectangles, switch one, switch two, so some LAN switches and some routers, R1 and R4, just a simple small network. So the users, the end users, the humans would be using computers A through to J and the switches and routers are just part of the network to support the connections. So one of the things that we need to consider is if we're going to encrypt our communications in the network where should we perform the encryption? There are basically two different approaches. Let's say we want to allow A to communicate to B, then the two approaches for where to perform encryption are A could encrypt the data, send the data, the cipher text to the switch, the switch could decrypt that and then encrypt again, using a different key possibly, and then send the new cipher text to B and B decrypts that. Or if we wanted to send from A to F, A encrypts the data, sends to the switch, the switch has the correct key to decrypt, decrypts the data, encrypts again to send on to the router R1, which decrypts, which encrypts again to send a switch 3, decrypt encrypt and so on until it is received at F, which finally decrypts. That's one approach and maybe not the obvious one that people think about, but that's one approach called link level encryption. Every link in the network we apply encryption separately. The other approach is what we call end-to-end encryption or host-level encryption, where if A wants to send to B, A encrypts the data, sends the cipher text to the switch, the switch does not decrypt, it simply forwards on the cipher text to B. B receives and does the decryption. Or if A wants to send to F, A encrypts, sends to the switch, which forwards it on to the router across the path to switch 5 and then F receives and only F is the one that can decrypt. That's end-to-end encryption. Which one's better? End-to-end or maybe a better question is what are the trade-offs? What are the advantages of the first one, link-level encryption and what are the advantages of the second one, end-to-end encryption? Which one would you want to use in this network? Link level, let's consider link level where we encrypt separately on every link. What's the problem with that? Many encrypt and decrypts, that is encryption and decryption takes some time. There's some performance hit of doing it. For example, to send from A through to F, we must decrypt at the switch, switch 1, and then encrypt. Every packet that goes through switch 1, switch must decrypt and encrypt. That decreases the performance of the data delivery because it takes time to do that. That's a problem. The intermediate devices must perform the decryption and encryption. They must support the algorithms and they must do it fast, otherwise our performance slows down. There's a disadvantage. What is an advantage of doing link-level encryption? Hard to see. We'll come to that in a moment, the advantage. What's another disadvantage? You could tap into the switch. What happens inside switch 1 is A encrypts inside the computer. Let's say I am A, someone at the back is F. I encrypt inside my computer, so some software does it for me, sends across the link to switch 1. Switch 1 inside the computer, it's got a CPU, decrypts, gets the plain text, it's stored in memory, and then also inside the computer, encrypts again, and then sends the new cipher text on to router R1. There's a problem there that for a short period of time, the plain text was available in memory inside the switch. If someone had physical access to that switch or it compromised that switch, again, they can potentially get the plain text. This process of inside this device, decrypt, get the plain text, encrypt again, has this limitation if someone gets physical access to the device, they can get access to the plain text. Of course, there are the advantages of doing the end-to-end encryption. We don't have to trust the device. That is, even if someone compromises the device, they still can't see our plain text because A encrypts, only F can decrypt, even if someone accesses the switch. What else is a problem with link-level encryption? So yes, we need to trust the devices. If they're compromised, our communications from between A and F can be compromised. What else is a problem? We need to also trust the links, actually. That is, we need to make sure that the encryption is used across every link in the path that I use. In this small network, not so hard. If we control the network, that is, this is the network inside SIT, we can set up all our devices to use encryption across every link. But now think of the internet. This is internal for SIT and this is our ISP going from router 1 to router 2 and this is someone else's network. From the perspective of the end-hosts, A and F, they must trust that the network operators, like the internet service provider, performs the encryption. You must trust the people who run the links. Of course, in large networks, that's not possible to trust everyone who runs the links. We've seen three disadvantages of link-level encryption and we haven't been able to answer the advantage. We'll see in a moment, but maybe the hint is it's not used very often apart from in small networks. We'll see that when we come to the advantage. Two different approaches. Encrypt at the end points for those communicating or encrypt across each link in the path between those end points. Link-level encryption versus end-to-end encryption. And here we'll see the advantage of link-level encryption. Same network. For link-level encryption first, calculate the number of keys that are needed in the network. How many keys are needed in the network? Here's our network again. Link-level encryption, where we're going to encrypt across each link separately. So for each link, A encrypts with one key, the switch decrypts with the same key. If we're using symmetric key encryption, so for the link between A and switch one, we would need one key, shared between the two end points of that link. And then the switch encrypts again with a different key to send to the router R1, which decrypts and encrypts again to switch three and so on. If we use a different key for every link, how many keys do we need in the network? Someone can count. How many links? Look at the number of lines between devices. Anyone get a number? 20? There are 20 links in this network. So for example, A to the switch one, B to switch one, there's two, switch one to router one is three and so on. Just add up the links. There are 20 links. And what we can do with link-level encryption is we could use a different key for each link. We could have a special case where we use the same key across all links even. But remember this principle, we don't want to use the same key over and over again. So typically we'd use different keys on each link. Let's consider that. So how many keys we'd need is 20 in that case. How would we distribute the keys? Well, what's the way to distribute the keys in this small network? There may be some automatic ways, but let's try manual distribution. What we could do is that the person who runs the network, so say it's the network inside our campus, the computer center, they set up the switch and they set up the computers and the routers. What they do when they set them up is that they go to the interface and enter in the key that is used at both end points of each link. So that would be what I call manual distribution of the keys. The human is involved in setting maybe programming into each device, they're a correct key. It could be possible because we have 20 links, we have really 20 keys that need to be programmed into what is it, 40 devices. So with link level encryption, encrypt across each link using a separate key, we need a total of 20 keys and we could distribute them in a manual manner in that the administrator who runs all the devices programs it in. If you grow this network to not just 20 links, but maybe across whole the Thomas Rungsick campus, maybe 1,000 links, 1,000s of links perhaps, then for sure more than 1,000s, then the number of keys needed is the same as the number of links in the network, but manual programming in them in becomes a hard task. That is the administrator needs to go to every device and log in to that device via the web interface or via some interface and type in the key and then go to the other end point of that link and type in the same key. So manual distribution even in such small networks becomes a pain for a human user to do. So we need some automatic way. The fewer keys that we have to distribute, the easier it is to distribute them and the easier it is to do manual distribution to have the human involved. Let's say that we want to do host to host encryption or end to end encryption and between the hosts first, that is the hosts are A through to J, they are our 10 computers. So if A wants to send to B, A will encrypt, the switch doesn't do an encryption or decryption, it simply forwards on on to B and B decrypts. So if we want to allow any host to communicate with any other host, how many keys do we need? Try to count the number of keys needed in this case. Start simple. How many keys does computer A need to communicate with any other computer in the network? Nine. A needs a key shared with B so that when AMB communicate, they can encrypt. A needs a key shared with C, D, E, all the way through to J, so A needs to share with nine others. Let's say that when we send from A to B, we use one key and when we send from B back to A, we use the same key because it's the same pair of entities. We can use the, in both directions, use the same key. So B already has a key shared with A in that first nine that we counted. B needs to share also with C, D, E through to J, another, what, eight keys needed and C needs to share with seven others and D with six others and so on and the total number of keys. How many pairs are there? This is what we finished on in the lecture last week, those statistics and probability. There's one equation that's very useful to remember here. So it's really nine plus eight plus seven plus six to the end, which it's not factorial, they're just adding. It's N times N minus one divided by two. N is the number of entities involved. So here, there are 10 times nine divided by two, 45 keys. You can check that. So just check if you want to list all the possible keys. A to nine others, B to eight others, C to seven others and so on. If you add them up, you'll get 45. More keys are needed if we want to do end to end encryption here. And that's starting to lead to the disadvantage of end to end versus link level. This is one reason why link level encryption can be used because we could manually distribute those keys by having the administrator program them into the devices. With a small network, that would be manageable. If we want to allow all the computers to communicate, end to end, we need 45 keys. Not so many more double, but still may be manageable. Sometimes, though, we would like to not just encrypt for every computer, we'd like our applications to encrypt data. So on computer E, for example, there may be several applications running at the same time, several networked applications. And they may want to encrypt separately amongst those applications. So when E sends to D, with encryption for each host, they just need one key for all data sent between E and D. But sometimes we'll encrypt per application. So let's say there were five applications on E and five applications on computer D, then in some cases the applications will maintain separate keys. So there would need to be a key shared between application one on D and application one on E, application two on D and application two on E, and application five on D and application five on E. For example, the application may be your web browser on your computer, wants to talk to the web server on another computer. That uses one pair of keys, a one key. Your email client on your computer to the email server on the same other computer uses a different key. Often applications will have their own encryption approaches and therefore would need a separate key. Let's consider that as another case and calculate the number of keys. Let's say there were, for example, five applications on each computer. How many keys would we need in total in the network? And there are two different approaches to this, or there's two different ways to think about it. First let's keep it easy. Let's say the application on each computer will only communicate with its corresponding application. So if I draw that, let's say if this is D and E, there are five applications on each running pieces of software. So this pair of applications would need a key to be shared. This pair of applications would need a separate key. So let's say web browsing, email, instant messaging, voice, and some database application. All between the same pair of computers but different applications. So we'd have five keys for between D and E. Now we need to consider D to A, D to B, and all the other combinations of pairs of computers. So how many keys in total in this case? There are 45 pairs of hosts. We would need five keys per pair. So five times 45 in this case. Often networked applications will use their own form of encryption. They'll design and select on their own and therefore may have separate keys amongst the applications even on the same pairs of computers. So we're trying to count how many keys would be needed and then we'll make some conclusions about, well, can we manually distribute those keys by using humans or do we need to automatically distribute them using some communications protocol? And let's consider one last case. Similar five applications but any application can communicate with any other on the same computer. If I draw that for example the two computers E to D, they each run five applications. The application one on D would share a key with application one on E. Application one on D would share a key with app two and so on. That is we're not limited to be between the same types of applications. Maybe there were five instances of a transport based application using TCP and the key was for each TCP connection. And similar application two on D would share with the other five on E. I will not try and draw that. If that was the case, how many keys are needed in total? Any of the five applications must share with any other of the five applications on any of the other computers. Anyone tell me the answer? So just a different scenario in this case any application can talk to any other application. Any questions? Do you have the answer then? How are you going to find the answer? It turns out it's really the same as host to host but instead of having 10 hosts, we really have what, 50 applications. And any pair needs to be able to communicate with a separate key. So application one on D to application one on E, application one on D to application one on C and so on. If you look in total, there are 50 applications on all of those computers. They all need to have a pair. They all create a pair and each pair needs its own secret key. So there are 50 applications. So the total number of keys would be 50 times 49 divided by 2. 1,225 keys. Which one is used? Well it depends upon the network and how the computers are set up but commonly it would be between applications, one of the last two in many systems. What do these numbers mean? They give us an idea that depending on how we use encryption, it indicates whether it's possible to manually distribute keys or not. And again by manually distributing keys humans go to the device and go to another person and tell each other the correct key and enter it in. If there were 20 keys, that would be possible to manually distribute those 20 keys amongst the different devices. If there are 1,225 keys to be distributed, then that's probably not possible. It's just not convenient for someone to go around to everyone else and exchange all the keys for each application. And of course expand this network into not just 10 hosts, but up to let's say inside our campus, we have something like 400 hosts, 400 computers. If we wanted link level encryption it would need one key for every link, I don't know, hundreds of keys. If we wanted host to host end to end encryption, just between the hosts, with 400 hosts it becomes what 400 times 399 divided by 2, which is 80,000 or something or even more. The point is with end to end encryption, there are too many keys to distribute to allow for manual distribution. We must have a way to automatically distribute the keys without the human being involved. So how do we do that? How do we distribute keys automatically? Distribute secrets. You know of one approach, you've done it already. What's the name? Starts with D. Diffie Hellman. Diffie Hellman is a protocol for automatically exchanging a secret between a pair of entities. So Diffie Hellman key exchange, we've seen. That is a public key cryptographic algorithm for key exchange. If you remember in the lecture we did a man in the middle attack against Diffie Hellman. It's possible to do a man in the middle attack. So we'll see later we'll return to a man in the middle attack and see that there are some limitations there. We need to use it in a different manner. Can we use symmetric key cryptography to support our automatic exchange of keys? That is, we have a central computer that creates the keys for us and encrypts the keys and sends it to each computer using some protocol. That would be desirable. Something creates all the keys or, so either a central computer creates all the keys and sends it to A, B, C, D up to J, sends all those 1,225 keys and then they use them in the network. That's the type of approach that we'd like to have where that's all automatic. Let's see how that works. So we calculated the numbers just returning here. Link level encryption. We encrypt data across the individual links. It has some problems in that it adds extra requirements on the devices and we must trust the links. So it's only really suitable in networks, inside networks where there's one operator, one owner and they can be sure that everything internal is encrypted. But if you want to apply link level encryption it doesn't make sense in a network which has multiple owners or multiple operators because you need to trust the other one is not viewing your traffic. So in larger networks end-to-end encryption is used like the internet for example. The problem with end-to-end encryption is that with many end points there are many keys needed and we need an automatic way to distribute those keys. And let's look at the approaches we have. First, let's go through all of them. Manual exchange of keys. So this uses the human to distribute the keys. It's possible but when there's maybe more than hundred keys it becomes too inconvenient. And with end-to-end encryption there's highly like to be thousands of keys necessary. So manual exchange of keys is only really possible when there's a small number of keys to be exchanged. Tens of keys maybe. So option two, what we do is we have two different types of keys. We have what we call a master key and we'll allow the users to exchange a master key using a manual approach but then we'll generate or calculate session keys which are then used for encryption of our data. So we'll see a scheme that uses a combination of manual distribution as well as automatic distribution. The idea is that the master key between say a certain set of users is manually exchanged. Then there's some protocol that a session key is generated and then encrypted using the master key and sent to the recipient that needs it. So the session keys will be sent across the network and as we know if we're going to send anything across the network it must be encrypted. So to send a session key across the network we'll encrypt it using the master key under the assumption that the master key has already been manually distributed. So we'll see in some of the upcoming schemes we'll distinguish between a master key and a session key. We'll compare the approaches after we see one of the schemes. In particular we'll see the key distribution center. The third approach which we already know about as an example is to use public key cryptography. Diffie Hellman is an example or simply using RSA. User A encrypts some secret, some symmetric key with B's public key and only B can decrypt. So option one, manual exchange of keys not possible when there's a large number of keys needed. Option two, manual exchange of master keys and then using symmetric key encryption encrypt session keys using the master key and automatically exchange the session keys. So this uses symmetric key encryption. Option three, use public key cryptography such as Diffie Hellman and other schemes. And with public key cryptography one of the major challenges becomes how do I know that the public key of Steve is in fact Steve's public key, not someone pretending to be him. So we'll cover that issue. And that's what this, the remainder of the, this topic covers, those three or the last two options. Starting with option two we'll look at how do we use symmetric key encryption to distribute symmetric keys. And I think we'll get straight to an example. We'll go to an example, we'll come back to those few slides that we'll skip over after the example. For the example which is on the next slide, the next picture, just some notation we'll talk about here. In this simple example we've got two entities that want to communicate, A and B and they've got some ID. And I'll denote that as IDA and IDB. So something that identifies that entity in the network. For example, an IP address and port number to identify an application or maybe some unique string to identify a human or whatever entity is trying to communicate. We'll have a master key denoted as KM where that master key in the picture that's coming up is shared between A and B. We'll also have master key specific to, I think in later slides, not the next one, specific to each user, KA and KB. And we'll introduce a session key, KS, and then we'll see some nonce values, N1 and N2. And I'll explain them once we use them in the system. Here's a way to automatically exchange session keys between pairs of users using symmetric key encryption. This approach assumes A and B both have a master key. They both know in advance a key KM. So the steps are, A wants to communicate with B. And to communicate with B, the aim is to get a key that they both know. But they already know the master key KM. What we'll do coming back to one of our earlier principles, let's not use the master key to encrypt the data. Let's use another key to encrypt the data to meet this idea that don't use the same key too often. We'll use a master key to encrypt the session key and then use a session key to encrypt the data so that later we can change the session key quite easily by just generating a new one and encrypting it using the master key. So we'll do some analysis of that in a moment. So let's write down what we know as we go through this protocol. As known in advance, we assume in this case that A knows KM and so does B. So that's before any of these steps. And this diagram shows the protocol as an exchange of three messages. A sends the first message to B, we'll see the contents. B responds and then A sends the third and final message to B. So this is an automatic way for exchanging a session key but it assumes that they both have a master key up front. A sends the first message which contains its identity and some nonce value. A nonce value, in this case N1, a nonce value is a number that we'll use only once. Nonce means number used only once. And it's usually either a random number, so what value? It's a random number, maybe a date or time stamp, maybe a counter. So when I say we only use it once, if it's a random number, I choose a random number and that's the nonce. The next time I need to send such a message, I'll choose another random number and therefore I haven't used the previous one again. Similarly if it's a time stamp, I send this first message and I include a time stamp in there. That's the nonce value. Tomorrow I send the same message again from A to B but it will have a different time stamp, a different date and time. Or if it's a counter, N1 is zero in the first case. The second time I need to send this message I set it to one and then two and so on. Now eventually it will repeat but if we have it large enough then it will be unlikely for a long time. So we'll see the use of it shortly. It's commonly used to identify that this is not a repeat and there's no, may thought, replay attacks. So first message, A sends to B. I am A and I want to communicate with you and a nonce value. B will reply and the reply of B, what B does is it generates a session key. So it calculates a session key KS, which can simply be a random number. If we're using say AES 256 it generates a random 256 value and it's going to send the session key to A here, combined with A's identity to confirm this first message was A, I'm sending it to A, I am B and this F of N1 means some function on the nonce that we receive from A. For example the function could be plus one. The way that we could use the nonce value is that let's say N1 here was a random number. Can someone choose a random number for me? Thank you. There's a random number. A chose that and sent it in the message as well as its ID, something that identifies computer A. When B responds this F of N1 is some operation on the one that it received and it may be for example add one, so this value may be 46322. In addition B chooses its own nonce value N2, another random number that's N2 and we'll see it comes back in a moment. So when we say here a function of N1 it means some operation which is known by both sides as part of the algorithm what the operation is, for example increment. It's useful for both A and B in identifying that these messages belong to this specific transaction that they're not replays from old ones, they're not fake messages. We'll see in a moment how they can be used. So this response message contains the session key, the identities of A and B, some function on the received nonce value and a new nonce value chosen by B, but since we're sending that across the network we can't send it in the clear, we must encrypt it and that's why here we encrypt with the master key KM. The idea was to get the session key between A and B. We encrypt that session key with the master key. When A receives message 2, A can find the session key, it decrypts and gets KS. Importantly when it receives message 2 it checks the values it received in the nonce. A sent nonce 46321. When it received the response it was 46322, since A knows that that function is the increment, A knows that the person who received it received the one that I sent. It's some confirmation that this response is for the message I just sent. It's not for some other one I sent 10 days ago or yesterday, it's for this one I just previously sent. So it serves as some identifier or some sequence number so that A can keep track of this message 2 is a response to message 1. Because what could be happening in a network is that A is sending many of these message 1s to B or to other entities. So it may be doing it in parallel for different applications to repeat this process. If A wants three session keys with B it can send three of those first messages but that all have a different nonce value. And A would be able to confirm and correspond the response value with the original one based upon the 46322 or the equivalent number. Now we've achieved our aim. A knows the session key. The final step is again some form of authentication of saying here's the nonce value 18467 and A applies some function on it let's say increments it and encrypts that with the session key and when B gets it B confirms that A got the session key. So this can act as confirmation and we'll see if someone tries to do an attack because B expects to get this confirmation it can if it doesn't get the confirmation of the encrypted value 18468 then it knows something's gone wrong. B must receive 18468 encrypted with the session key. If it doesn't then something's gone wrong. So that's the protocol. The goal was to distribute a session key. Why did we need it? Why not just use KM? Not KS. That's the first question you should have. What's the answer? KM is a master key shared between A and B only. KS is a session key shared between A and B now after. Why did we need these three steps? Why didn't we just use KM? The idea is that again this idea don't use the same key too often. So one way to get around that is you have a master key. With a master key you use that to encrypt session keys. Let's say every five minutes you want to repeat this because you want to change your key.  So the way we could do this is that let's say A and B manual exchange a master key today. Then every day they go through this process using the same master key of generating a new session key. And the data that they use, the data that's encrypted between A and B is encrypted with a session key. So not shown in this diagram but the next step once we have a session key any data is encrypted with KS. So the data between A and B is encrypted with the session key. The session key was encrypted with the master key. The master key was manual exchange that took a lot of effort that's inconvenient but we only do it once maybe today and not for the next year. But the session key now we can automatically update or change the session key by applying these three steps say every day. Tomorrow I do these three steps and get a new session key, the next day a new session key. And this gives us this feature of regularly changing the session keys for this principle of don't use the same key too long. So we actually have a hierarchy of keys, a master and a session key. The nonce function, so the nonce value, the way for choosing it and the function we apply on it usually would be part of the algorithm. So this is a general, this is the general algorithm or protocol but a specific implementation may choose the way of encoding the identity, the messages and the nonce value. So it would be known by A and B as well as by the attacker. So it's part of the algorithm. Not the nonce value but how to create it. So yes you know it's encrypted, you know for example that someone chose a random value, so if the nonce, let's say A and B decided to use a random value for the nonce like I did in the example. The attacker knows they chose a random value but they may, because it's a random value they cannot predict the next one and in the scheme that we saw what can the attacker do. If the attacker pretends to be A and sends message 1 to B, what will happen? Can the attacker send a message to B and get B to respond to A. If the attacker sends message 1 to B they can say okay here's the ID of A. The sender is not A but they're pretending to be A. They can choose a nonce value and when B sends back a reply to A it contains the nonce value that A chose and it's encrypted with KM. What happens next? The attacker could intercept and try and decrypt but they can't decrypt because they don't know KM so that doesn't work. Remember all of this is encrypted with KM and we're assuming the attacker doesn't know the master key so the attacker cannot decrypt this and see the session key. If this message made it way back to A, A could decrypt and they would see that here's a nonce value or F of the nonce value of a message that I didn't send. So A would recognize that this response message 2 is not correct in that it's a response to a message that I never sent therefore I detected something's gone wrong and maybe I can inform B in some other way saying you received a message from someone but it wasn't me because I never sent message 1. So the nonce value can be used in that case because for example that A will recognize the nonce in this case. That is in this case, the normal case, A is expecting a response containing 4, 6, 3, 2. If it's not something's gone wrong, if the attacker created this first message they would choose a random number and B would send it in the response or an increment of that and A would detect it because it wasn't expecting such a response so it's used to identify what's expected and what's not. It's useful also in the final confirmation in the third message as well. A replay attack could be attempted by the attacker. Let's try, maybe we'll try and draw it again to finish today. Let's try a replay attack on that one. Let's just assume that the first message is sent from A so K, M is known by A and B and let's say A sends the first message, identity of A and the nonce value, let's choose a random number, let the nonce value set just a value that we chose, B sends back the response. I will not write it all but we'll summarise it's encrypted using K, M. It contains K, S, the identities, the nonce value incremented and another nonce value. I haven't drawn the identities there. And then the third message, so this is the normal approach. What do we do? Encrypt using K, S in this case, some operation on the second nonce value. So this is the normal exchange between A and B. A sends a message saying I am A and the nonce value N1 is random number 44896. When B sends back the response, A will check. Does it contain 449897? Because we sent one with 44896, yes it does. So this message 2 is a response to the message 1 which I sent, which is all good. And also of course contains the session key and then we do a final confirmation. We encrypt using the session key, the modification of the second nonce chosen by B. Let's see if what we do is at a later point, maybe that was today, let's say we change session keys every day, tomorrow or at a later time. What if the attacker replays the second message? What will happen? We'll try some different cases. What if the attacker replays the second message? That is the attacker, our malicious user sends to A the contents of this message. They don't know the contents or they may not but they can replay the message because let's say it's a packet sent across the network. The attacker has intercepted that packet in the previous day. Now they just re-send that exact same packet. Even though it's encrypted they cannot see the contents. What happens at A in this case? Can it decrypt? A can decrypt the message and then what do they do? They check the nonce and what do they discover? This is yesterday's nonce. This is one that I'm not expecting. So this is the use of when they decrypt this message they receive it, they find here's a message containing nonce 44897. I didn't send in the last few minutes. I didn't send 44896 so it keeps track of what it last sent and realizes this is a replay. So that's the first use of the nonce or another use of the nonce where a replay of a message can be identified. It's like a sequence number. We can identify duplicates or replays. So that doesn't work from the malicious user's point of view because A would detect that. What else can the malicious user try to do then? Try to get A or B to accept a message which comes from the malicious user. What would you need to do? Some of you may be asking why do that? Why would the malicious user send this message? What's the benefit? Maybe the malicious user has found out what KS was and they want to get A to keep using KS because maybe through some other means they did find the session key and they want to make sure A keeps using it so that they can further decrypt what's being sent by A. So there's a possible reason for trying this from a malicious user's point of view. Try and think full A into think use this session key. It's a good one but in fact it's one that's been compromised in the past. Anything else the malicious user can try to do? What can you try? What's the purpose of the third message? Again, to confirm. Okay, can the malicious user take advantage of this or what does this prevent if the malicious user does something? So what we'd like to do and a good way to understand why these steps are needed is to look at what if something goes wrong? What if the malicious user changes it? Will it be detected? And if it is, then it indicates that the scheme is good. If it's not detected it indicates that's a potential flaw in the scheme. If the malicious user, we haven't drawn it but if they tried to send this first message pretending to be A, it would be detected in that the response that comes to A, A would realize, ah, I didn't send that first message. Similar with a replay here. I'll leave you to be malicious. Yes, give me a malicious approach. Right, so another case. What if the malicious user, or not try and draw it, the malicious user sends this first message pretending to be A and then B sends the response back to the malicious user. What can the malicious user do then? They can't decrypt it because they don't have KM. Okay, so they could try to do that. The malicious user sends the first message to B, B responds, the malicious user gets the response but the malicious user cannot do anything with it because they cannot decrypt it because they don't have KM. Remember KM is only shared between A and B. Alright, let's try and finish up. Why use this scheme again? What we'd like to do is use a master key on a, ah, we don't want to use the master key very often. Okay, but we'd like to change keys very often. So what we do is we use the master key to encrypt a session key and we change the session key very often and we encrypt our data with a session key and this is towards the principle of don't use the same key for too long and that's what this scheme allows. How many, let's consider to finish, how many, let's say a network of 100 users using that scheme, how many master keys are necessary? A network of 100 users, so there's not just A, B, C and so on, there are 100 in total. In total how many master keys are necessary? A had a master key with B, A would have a master key with C and so on and the total you'd calculate is what? 100 times 99 divided by 2. Remember that formula, it's very useful, which is what? About almost 5,000, 10,000 divided by 2. These are manually exchanged. So the master keys are not sent across the network because we've got nothing to encrypt them with, so there must be manually exchanged and that's the problem there. How many session keys? Well, the same number of session keys but they exchange automatically, that is we use that protocol to exchange the session keys and they can be therefore easy to change. So in this case the same number of session keys as master keys but the master keys, we think we do it once when we start our network and we keep the same master key for a long time, we just don't use it very often. We only use it to encrypt a session key, let's say we change the session key every day. So for every piece of data we send for that 24 hour period we use one session key and then we change the session key for the next day and change it again and then again and every day we just use our master key once or twice to exchange the new session key. So the automatic exchange of session keys means that we can easily do it again and again and again but the manual distribution of the master keys is the problem in that a lot of keys need to be distributed via some manual approach. So this scheme is okay but the number of keys that need to be distributed using a manual approach is maybe too many in this example. It only works when there are few nodes, maybe tens of nodes, 100 nodes it's getting a little bit too large. So what we'll see on Friday is a centralized scheme which cuts down on the number of master keys needed. We can still use session keys but will reduce significantly the number of master keys and that's important.