 Folks, we have now come to the actually closing tail end of our crypto talks, but we still have some other stuff to cover here. Before we start on that, I made an announcement on the mailing list. I'll remake this announcement. I send out a link. We still have about 20 spots available for the Symposium on Information Assurance Research and Education that we're hosting tomorrow. We have some really great presentations from all states early morning, which is a local company, and the person who does this is the manager of the penetration testing team, Joaquin Fuentes. We have Aaron Gibbs, who is a special agent at the FBI, and two people from State Farm to give talks on how they use security in their organization, what types of things they put before, what types of recent threats are they seeing. I talked to Aaron. She's going to have a really interesting talk about a recent case that she can actually talk about where they used some cybersecurity and some security elements. So it's a cool case of the one that I guys mess up, and this is what happens and how they get you. We'll also be having panels, poster sessions, food is provided, but there's only 20 spots left, so I can't have all of you come. I'd love to. So if you can attend most of the day, feel free to register while there's still tickets. There's still tickets available, so you can read more about it at the links that I sent. Any questions? It's not a recruiting event per se, but this could be a good way for you to see what local people and what industry folks are looking for in security, what kind of problems they face, and the lunchtime is going to give you a good opportunity to talk to them, which is how you get jobs. Questions? Maybe just don't register and you popped in. If I don't notice, it's fine. I mean, just as long as we're under the fire code, I guess that's the only thing I really care about. And it's an old name, so that's pretty sweet. It's a really nice term. Feels fancy. So is this more important, or is this a whole lot more important? Both of these are important. Good answer, all right. You're getting a ticket. I should have done that. Okay, so sign of two is going to be 100% crypto. Split into points wise into two halves, let's say, because I don't want to load up parts two weeks for this. I think it shouldn't be a problem, but the first parts are actually incredibly straightforward. There's cipher text. It's actually not here. You have to log in. You'll see your personal cipher text, so you can type different ones. You have code here, Python code, of how this cipher was done. So break it. It's actually not a lot I can say here. So the goal is to break, get the key, break that encryption, and recover the plain text. So what you need to submit is a readme file. You'll submit the key, and that's how we know you actually broke it. And I'd like you to submit all the code you used. If you wrote any code, helper functions, I mean, it doesn't have to be, sometimes when you're doing this, you're just writing kind of one-offs or something, but anything that you wrote that helps you do this, submit that as part of that because we like to see what kind of cool stuff you guys come up with. And then your readme should contain name, ID, the plain text to prove that you actually broke it, right? Just saying like, oh, the key is abcdfg. Maybe it's true, maybe it's not. Where the plain text came from, so doing a little digging to figure out where the stuff came from. Read description of the code you submitted about how to use it, what does the kind of parts do. So don't just throw like 20 Python files at us and expect us to figure out what all the different parts mean. So it's like common decency and documentation. And description of how you went and broke it. So this is, you know, found the key is probably not a good description, but, you know, talk about the different false starts that you did, how did you try approaching this, how did you try determining maybe key length or some of these other things. So there's two parts here, and then you'll submit a key. So you'll submit the key, and as you get into this, I don't want to spoil your fun too much, but it'll be a hexadecimal key. So that will be kind of the way we'll represent keys. I think it'll be a favorite start on campus. So there's two cyber texts, one for part one and one for part two. They read the same, and the third part I'm going to wait to talk about until we go forward. As I should say, as I rush to go to the slides, as soon as we're done with these slides, I will post them. But remind me if I know, which is a possibility. Yes, we only have like a few, I think we only have a few more slides to get through today. So that's a good question. Yeah. Not yet. I'm giving you guys a sneak peek. Also no key submission yet, so I figured you can start breaking stuff now. Is there anything else? Oh, yeah, yeah, the important thing. So obviously we've seen crypto, right? These are, I mean, a lot of what we're doing here is based on trust, right? The trust that you're doing these things. I trust that you're doing them correctly. And especially these type of things, because this is essentially a puzzle, right? You're trying to solve a puzzle. And I tried to, well, so, you know, don't, I mean, don't share, like try to do this on your own. This is like the entire point of doing this. This is kind of what I like to think of is like, it's easy to think you understand how to break and approach a cryptography problem from learning about the slides and learning about a class and going through a canned example that has the exact names you should look for. But now when you have something more real world, it actually becomes a lot more difficult. And so you should see this as kind of a personal challenge to make sure you actually understand these concepts of how to do crypt analysis. And as such, there are very much puzzles, right? So once you get it, you get it. And so you're sharing that information about this, how you approach this really robs your fellow students of the joy of learning and discovering. Yeah. Is there any incentive to finishing it first? No. Not on these parts. There's other incentives on the next half that I'll talk about after we get through the material. I think that'll be more fun, more fun incentives. Any other questions? Sweets. Talk about HRAX. So what is, so we talked about some of the problems with the cryptosystems that we've been studying. One main problem is that they all essentially are relaxed. So they don't offer any integrity protection, right? So we looked at hash functions. We looked at how hash functions actually add some integrity protection. So that way somebody receiving a message can know whether the message has been tampered with or moved out of order or we're doing anything like that. So hash functions are great for that. But so let's think back. So what was the problem that public key cryptosystems tried to solve from symmetric key cryptosystems? Right, the key. So what was this weakness? What was the problem there when we missed there? Right. So the idea is you need, in symmetric, you need a confidential channel in order to transmit keys, right? So in a public key cryptosystem, you don't need a confidential channel. But what do you actually need? Two keys. You definitely need two keys. So let's say two of you in this class kind of use that review. Say, any two people in this class want to securely transmit information using public key cryptos. How do they actually go about that and be sure that the other person is the one who that they're talking to? So let's think of one scheme. So let's think of one scheme. We'll use kind of the box analogy that we used before. I'm going to get rid of the box and all the box. So let's say there's just a, because we said the keys, anybody can inspect the keys, right? So we're not assuming that there's a confidential channel. So let's assume that there's a basket or something in this room. Two people here want to communicate. So I should have asked at the beginning if anybody was named Alice and anybody was named Bob. But let's say Alice is a student in the class. She wants to talk to Bob. So she puts her public key in the box, right? So I, as an adversary, Eve, I can inspect that public key and I can't, I can't derive her private key. And then Bob comes along, sees the box, takes her public key out, puts his public key back in, and then Alice comes to a later point. So again, I can read the key, but I still can't derive anything about the private key. And then Alice goes and sees that key. So then what could I do as an attacker in this scenario? So think about, think about a different point. When Bob goes to that box, what does, for the first time, what does he know at that point? Put a key in the box. Somebody put a key in the box. Does he know who put the key in the box? No. Is it guaranteed that it's Alice? Could the key say that it's from Alice? Yeah, it can say whatever it wants, right? We get very familiar with this. It can say whoever wants. It can, we, and so the problem there is Bob doesn't know that it's actually Alice's key, right? All he knows is there's some key in the box. So then what can our adversary do in that case? Put a different key in the box. I can put a different key in the box, right? I can generate a fake Alice public private key, a fake Bob public private key. When Alice puts her key in the box, I can look at it, and I take it out and put my Alice public key in the box. And then Bob goes, takes that and says, oh great, this is Alice's public key, puts his public key back in the box. And now Alice, before she gets that public key, I put the new fake key there. And now what do I have to do as an attacker every time they want to transmit a message? Intercept it, right? So we've got to think Alice is going to encrypt her message to the public key she thinks is for Bob, but is actually mine. And so she will send that message out. I need to get that message intercepted, decrypted with my secret key, and then use Bob's public key to encrypt it back and send it to Bob. So Bob sees this, sees that he gets a message from Alice and thinks everything is fine, right? Or, I mean, I intercept it so I can completely change the message, right? Once it's unencrypted, I can do whatever I want, or I can just read their communication. So what's the fundamental problem here? Yeah, there's no, so the really, we're not just two entities that want to talk. I mean we have, we have identities, right? But the problem is how do you bind some identities to some public key? So this is the entire point about a public key is you want the public key to be, you want everyone to know that this is your public key. And so it really boils down to how do you trust that public key, right? And so I think this is an incredibly important concept because, A, it informs a lot of real-world crypto systems that use public key crypto, but it's kind of important to realize that, hey, you don't just get, you know, public key crypto doesn't just solve all the problems, it actually brings a host of new problems of how do you verify that this is Alice's public key, right? So just like we talked about with our box example, Eve can replace all the public keys with their own public key. So when Alice wants to send a message one out to Bob, Alice will encrypt this with the public key of Eve, which Eve can then steal, use the secret key to decrypt, get some message, and then change that message to some message M2 and then encrypt that with Bob's public key to get Cyber Text 2, then Bob can take that Cyber Text 2, decrypt it, and say, aha, somebody sent me a secret message. And nobody else has ever read or tampered with this message in between, right? Which is, is that true or false? It's true. Yeah, the message came from Eve, right? Nobody tampered with this message from this point, right? Once Eve encrypt that message with Bob's public key, nobody else can mess with that message, right? That message is confidential, and nobody but Eve and Bob now know what that means, what that message is. Sorry, I can't see that part of the room. So how do we trust public keys? It seems like a much better solution than cementing encryption, so we'd like to use it, but how can we actually trust public keys? A signature form in one sense, but how do I know that that all relies on a public key, right? So one thing you can do in which they do is you can hack your public key, right? Sharing my public key with everyone, maybe a bit too burdensome, but I can share the hash of my public key with everyone, right? I can put it on my website, I can buy a billboard and put that, put my fingerprint up there, I can buy a space in the newspaper so that everyone knows this is the, the hash of my public key, that could be one way, but you still have to tell everyone, so it's a similar, similar problem to be telling everyone your private key. How about this way? How do I know that any of you are an ASU student right now? If I wanted to ask you, how could you try to prove to me that you are? You can show me what kind of ID, any? A school ID? A school ID, an ASU school ID, right? So who am I trusting in that case? Now I'm trusting ASU to have, like, properly identified you before they issued you this ID card. Yeah, so maybe you're referring to the Chipotle problem, although you guys probably haven't thought about this. I believe it's probably still the case you made a free small soda at Chipotle with the student ID? Yeah, some people are not, I think they definitely know this. Do you think Chipotle employees are checking what your expiration date of your student ID or anything? No, so all you do is show them some ID and then you get the student discount, right? They're not actually verifying that you're currently a student, right? So, so there's part of maybe some expiration issues there about when does this thing expire, is that kind of what I'm trying to pull that box. How else could we do it? So we get through, yeah. Will require further information from that person to verify that they're actually keeping you in or that they're actually the person they say they are? Right, so similar to how we trust ASU to only issue ID cards to active employees, and that's even trickier because employees also get ID cards, so I can't necessarily prove that you're a student, but I can take that number that's on your card, match it with the roster of people who are in this course, and then say, okay, you're likely an actual student in this course. I can take that further to passports, right? So you get a passport, you need to provide documentation, so I can ask for a passport that matches with the ID card. So you can also, oh, I have this really weird situation when I moved to Seattle. I lost my driver's license, so the only thing I had was an expired driver's license, a paper certificate from California that said I was a valid legal driver there, and I couldn't find my passport either at that time, so I was freaking out, trying to get a Washington state ID, and I needed to get a new California one, I had to go back to California and go get one, but I already moved to Washington at that point, so I had this, they had this crazy system there at the time where you can choose like from three different categories of information. One category was my expired license, the other one was, I think I had a credit card with my picture on it, and the third one, the only thing I had in there was a yearbook with my name and picture, literally my high school yearbook, so I went to the Washington DMV with this information, and somehow got a driver's license, like it was everything. So yeah, so they're still like, they're trusting that information that you're probably not going to go to the trouble of creating a fake yearbook, I mean obviously it's like thick, you know, and there's like people in the air, so yeah, that was a weird experience, but. So one type of way that we can talk about that we'll definitely talk about is some type of either, we can completely centralize this concept and say, okay, we're just going to trust a single entity to issue public keys correctly. So basically you can say, so, and that's the public key infrastructure which we'll talk about. The other way is we can do it completely decentralized, so how can we do that? And you know what movies are good to go see? Ask people that have seen it, or ask people who know people who've seen it, or trust reviews of people who write reviews about movies, who you trust that they actually like movies or whatever, you know, product, but the point is you can use kind of word of mouth or use your network, right? So you can trust people that you, so you basically can create this, what do we call, what they call a web of trust, so you can say, okay, I trust these people, so you can sign people's keys, and actually we'll look at that in a second. You can use this to essentially create a web where you have certain keys that you publicly said that you trust and that you have verified that the person who owns this key is this identity, right? And then they do that with other people, and so based on how you think about propagating this trust, that actually allows you to trust other people who you have no direct contact with, but people that you trust have verified each other, so you can kind of, you can think of it as essentially decentralizing this concept of trust. So the public key infrastructure is one of the largest kind of things that have dealt with this problem. The central idea is you have a certificate authority, so you have somebody who is responsible for verifying identity, so how does this actually work? So I have a public private key, what does the certificate authority have? List of keys that are, that one? So they could keep a list of keys, that would be if we're talking about we want everyone on earth to have a public private key, right? That would probably be an unwieldy two store. What do we really want? So let's say we have some certificate authority, you give me your public key, how do I know that this is actually your public key? What are some ways to do that? Even just going back, let's take it back without thinking about this, let's go back to our box scenario, right? Alice puts her public key in the box, there's some, we'll say the professor verifies identities of people, when Bob then goes into that box to inspect that public key, how can Bob verify that that public key actually belongs to Alice? What are some ways to do that? Bob could just directly ask the professor, hey, is this Alice's public key? I have this public key, does it belong to this person or are you defined person? You could think of email addresses, I think that's a good way to think about it. Does this email address own this key according to the professor? What's the problem there when we talk about professor goodbye? So we are fundamentally trusting this certificate authority, so we're delegating all authority to this certificate authority, but let's assume that even they're trustworthy at this point. No, it's not wrong, they're perfect for right now, stick with that model part. You still need all of that, you may have some database full of it. Yeah, think about every email you guys wanted to exchange with each other, you had to ask me if this other person was the correct key. Think about how many, that's a lot of combination because each of you needs to know about every other person's private public key if they wanted to, if it's the valid public key. Of course you can catch that information, so you could say, yes, okay, now I know Alice's public key is this and I trust this because the certificate authority told me that it's correct. But now I have to do this for everyone, Shane's insane. I would go crazy trying to keep up with this. So what do you actually want to know? So think about what Bob wants to know. What does he want to know? Going back to the example that Eve hasn't actually done anything to it because it's coming in as the original. Correct. Bob wants to prove that this public key that he's found is Alice's, right? The key itself says that it's Alice's, right? So Alice can then come to me and say, hey, I'm Alice. Here's my public key. Here's my ID card. Here's my passport. I can verify that, yes, this is Alice. She's in our system. Great. Then what do I do with her public, I mean, what can I do with her public key? I can store it. I don't want to store all your public keys. You have a limited number of people. I don't have a billion people. Yes. So one thing I could do is I could take that public key, encrypt it with my secret key, right? And then Alice can put that in the box and everyone else, Bob can then take that and know when he decrypts it with the certificate authority's public key that, wow, this definitely is legitimate. This is Alice's key. This has been verified by the certificate authority. Does Bob ever need to contact the certificate authority at that point? No. The problem is everyone needs to know what this public key is, right? And that literally, like, you, everyone needs to know exactly what the certificate authority's public key is because if I trick you to accept somebody else's certificate authority, right, another key is the certificate authority's public key. I can just issue these certificates for anything. And what we actually use rather than just encrypting the whole public key, we use that signature thing that we talked about. So we basically take the hash of the key and then we encrypt that hash with the secret key of the, of the certificate authority so that that way everything is attached with that and so we're all good. So that actually solves a lot of good scalability problems, right? This means even if the certificate authority goes down, you can still communicate and verify keys, right? If I'm sleeping, you can still actually talk to each other because you don't have to ask me to verify public keys. So still we have, okay, we have one entity responsible for everything, which is a lot. And we probably not want this if you think even just, for technical reasons, right, we may not want one single entity to have, to be the end all be all authority. You also run into political considerations in the real world where what is this company, who is it, who is the certificate authority, are they be molded into American interests or Chinese interests or Russian interests, right? And those countries may decide, hey, for us, we actually don't trust that certificate authority. We want our own certificate authority, maybe for good reasons because they don't trust how you're going to verify identities, maybe for bad reasons, whatever the case may be. And so essentially the system that we've come up with is there are a series, there are, you can have any number of essentially root certificate authorities. So this is somebody who says I will verify people's identities and those can actually delegate their authority to other certificate authorities. So if you want to set up shop as another certificate authority, so let's say the TA version. Let's say FISA wanted to become a certificate authority or I wanted to delegate some of that responsibility, I'd train her how to verify identities and make sure that she followed the same procedures. And then how would you know that she was a certificate authority that I trusted? You do the same process, but so the same process we did in the last step, you verify, you get the private key, you have the, you haven't signed with the private key, the hash of the intermediate certificate authority. Right, so I would take FISA's public key, I would hash that, and then I would sign that hash and give that to her. And then if she wants to sign any of your other keys, she could then sign that with her public key, but include in that message, hey, I'm trusted by the certificate authority, here's the message that I have that's actually encrypted by the ultimate certificate authority. So if you want to look that up, you would use her public key to decrypt it, and then you would use my public key to decrypt that. And so you actually verify this chain that I trusted FISA's public key, and that as long as you trust that chain, then you are, are, believe that this person has this public key that you're interested in. And you can do this kind of as arbitrarily deep as you want, you can have all types of certificate authorities here. So we need to issue certificates, I think that's the clear, the clear case here, but what is this fundamentally, so what are some real world problems that can come up here? Anybody lose their wallet or cell phone or keys or anything? No, they're all perfect people. Yeah, have a call of time, right? You like lose it, leave it somewhere, whatever. It gets stolen, that is another good analogy, right? So once a, let's say, if we just think about the individual level, let's say I verify that this public key is owned by Alice. If Alice loses her private key, now anyone can create messages and claim that they are from Alice, right? So we have this whole problem of, and this is a whole area of revocation, where how do we actually, so what are some ways we can think about maybe doing this? What's the simplest way? Yeah, let's say Alice loses her key, how do I deal with this situation? Right, what does the authority do? It's made the signature for that public key. That signature is out there that says that this public key belongs to Alice. So can we revert back essentially to our original model? What was our original model? What would Bob do when he looks at Alice's public key? Our original system, we have the box, Alice put her key in there, Bob sees the key. In our very first iteration of this, what did Bob, how did Bob verify that Alice owned this key? He used his secret key. He used his public key. Our very first iteration. So how did, how did Bob ask, I mean, how did Bob find out that the certificate authority trusts that this private key is Alice? Ask the certificate authority. So now, I mean, you could actually think of a revocation scheme where every time you see a public key, you ask the certificate authority and said, is this the public key? He said, is this key revoked? And you would say yes or no. So now the certificate authority has to be tracked with what? Revoked keys. Should that be smaller or larger than a set of keys? Should be smaller, although I don't know if that's actually true in practice. So this is one way you can do this. What's kind of the problem with, let's think about the homework one, the house. Let's say somebody loses one of those keys to the house, or any kind of house, but homework one I think has these concepts in it. You lose the key to your house. Should you be worried? Why? You can't get in. So what would you do? Change the locks. Right? So what if you change the locks every day? Would it be annoying? Yes, would you worry about a key from two weeks ago that maybe somebody cloned or that you lost? Would you worry about that? No, because if they didn't enter your house, you're fine. The idea is time limiting the keys. So you can actually, so a lot of the keys and you'll notice when you create your own public private key. So one way to deal with this is to time limit how long keys, either keys themselves are valid or you can limit how long the certificate authority's signature is valid. So I don't think anybody's had this problem. This problem on time when we came to which country we're in. We're in a different country and, oh that's right, somebody's, somebody couldn't access like Google and we thought like all the hotel Wi-Fi is blocking and trying to intercept our traffic or something and it turns out that the system clock was just messed up and was set to like three years prior or not three years ahead in the future so that that way it thought that Google's certificate was expired. And so the certificate authority can maybe put a time stamp and say I created the certificate at this time and it's only valid for 24 hours. And so now Alice can use this this public key and everyone will trust that the certificate authority has signed that until the, until after that timeline in which case that Alice needs to re-get a key from, re-get a new signature from the certificate authority. So this is, this also helps with this issue because then if somebody comes to me and says hey I'd like to revoke my key I can just say well it's already, it's already expired so we don't actually have to worry about that because nobody's ever going to trust that key. That's one aspect. Another aspect is, so if you think about the, we talked about our initial model as kind of a pull-based model or when you wanted to check a key you would pull it from me. I could push my replication list to everyone in the room, right? Let's say I'm the Windows operating system. I can keep a list of revoked keys and include that in an operating system update so that everyone gets the new list of revoked keys so they know not to use them. So modern systems have to deal with this issue and it really complicates things because it's a very practical consideration, right? Keys get stolen, keys get lost. How do you actually deal with that? So as we actually talked about the modern internet, so HTTPS, so for those that aren't aware HTTPS is basically HTTP over TLS, which TLS used to be called SSL. So that's what the, I guess the S and HTTPS comes from, Secure. And the, what do you actually want to trust on the web? What does HTTPS actually give you? You would want to trust that the site you're visiting is a site you're expecting to visit and not some kind of, potentially something that someone else put up there to kind of steal information. Yeah, so you'd want to have some way that you can say that yes, this is google.com. So I think we'll see it when we talk about web security, but most of the web security is based off of the domain name. So when you go to google.com, if you are accessing it over HTTPS and you get a green lock, you can be confident that A, that you're talking to google.com, what else could you be confident of? Communication is secure in the sense of confidential, right? So you know that nobody else has listened to that traffic and nobody else has modified the traffic from google server to you. Yes. Yeah, they know where it's going, and I know where it's coming from, but they don't know what you're sending specifically. Yes, this is actually a good point specifically that TLS provides. So it's just, so it's a layer on top of sockets, so you still are, you are an IP address on a certain program running on a port, you're communicating with a remote system on a remote port, so anybody who sees that connection knows that your IP address is making a connection to another IP address. So people can know that you're going to google.com, but they won't know specifically what page you won't, they won't know if Google sends you back. There's things that they won't know. And so the way this works is there are root certificate authorities, and these are essentially you can think of they are burned into operating systems and hardware and software. So into the operating systems each browser has different certificate authorities, root CAs that it trusts. I believe there have been cases of some root certificate authorities who were found were very lax and who they were issuing certificates to or who they were delegating to other certificate authorities, so the browsers actually revoked them and removed them from the trusted list of certificate authorities. And they actually went a little bit further here, and there's different levels of validation. So the very basic level domain validation, a DV, a domain validation certificate, all you have to prove is that you own this domain. So how would you prove that? Your IP is the same as the domain IP. How do you prove, yeah, how do you prove that it's your IP? But yeah, or you could, there's a couple of ways. You can basically, if you can prove that you own the domain name, so if you can alter the DNS entries for that domain, usually they'll say, hey, create a fake subdomain, that's this random value that has this IP address, you go and create that, they'll test that and say, okay, you can literally change the DNS records to this domain. So you either must actually control it in an ODAP or it really doesn't matter because you can do whatever you want with it anyway. So SSL certificate doesn't help you. The other level are organization validation certificates. So these are certificates. And you have to remember the unfortunate circumstances that these certificate authorities are for-profit companies. So this is maybe why a lot of you don't have SSL certificates, because even at the basic DV level, for most modern CAs, it's like $7 a year, it's actually, it costs money to do that. And then you can get bitten by there are some ones that will offer it for free, but then if you want to revoke it, it'll cost like $25, which I believe was the case when they had the Heartbleed Dug and a lot of SSL keys were leaked. That company got a very lot of fire because all the free customers just realized like, oh, if we want those keys to not be used again, we have to pay massive amounts of money, so comparatively, too free. So organization validation certificates are one level up that actually validate that you're the organization that you claim they are, that there's some tie between the organization and the domain name. And then one level above this is EV or extended validation certificates. This, you have to actually prove to the company that you are the legal entity that owns this domain name and that domain name has a tie to your legal entity. And why this is important and why I like talking about this is because there are visual indicators. I should add this here, but there actually is, if you're running a website, there's no excuse not to use HTTPS, which I just recently proved to myself last year by switching my website over to HTTPS, because you can get free domain validation certificates with free revocation and everything just from running like one or two commands on your server. So it's a, and it's not a company, which is the super cool thing, is I believe it's part of the EFF, the Electronic Freedom Frontier, that's what I was thinking, it's thinking foundation of a frontier. So the EFF has an organization called Let's Encrypt. And the goal of that organization is to encrypt all of the web traffic everywhere. So one of the best ways to do that is to make it super cheap and easy and literally free and easy to do this domain validated certificate. So all you do is install some software, you run the software and then it automatically figures out, I think it uses the fact that either you own the IP or that it can change something in the web server. So you prove to Let's Encrypt that you own this domain and then it automatically gives you a certificate, puts it on and configures your Apache or Nginx or whatever you're using to use that. So it's actually dead simple to do and it will automatically renew it. So you can have the certificate last for like a month or two and then have it automatically renew based on that. So super cool. I highly recommend it for any website to check that out. It's so easy, even I can do it. And what this gives you is nice. So part of this, and this is actually why I put this in here, is this is a whole line of research and study about how to surface to the average user that so they can understand that they're these security properties, that they can understand that their communication is not only encrypted, but also authenticated. So you know, you're actually talking to adamdupe.com. So this is Safari. My website, which just has a DV certificate. And this is apple.com, which has the EV, the extended validation certificate. So you can see they actually visually indicate that there's an additional level of validation that's done here. And it's kind of nice as they put the company name there, like Apple Inc. next to it. This is Firefox. So Firefox does something similar. So this is the original DV domain validation. And this is the extended validation. And then this then is Safari. So each of them be something special for that DV level. Just a little curiosity, is there something for the organizational level or not? No. I believe there used to be, but there's not anymore. Because I was actually very surprised I wanted to use my website in Google. Actually, Google just used an organizational validation certificate. Part of that, so, okay, I want to make sure we have time to go over everything else. But part of that is, because now you have this public key infrastructure, so you have this root certificate authority, which deligates authority to intermediate certificate authorities, which can delegate to other authorities, right? If you wanted to get a Google valid certificate so that you can manage the middle Google traffic, right, which actually would be a very valuable thing because you could spy on Gmail and all this very expensive stuff. If you want to get a valid public private key for Google, you have the very wide attack surface where you just need to break into any of those certificate authorities or convince anyone who has a valid certificate authority that you are google.com. So actually what Google does, what part of what the web created was, they call it certificate pinning, or the web term, HSTS, High Security Transport. I don't want to say security, but I feel like that's not right. The idea is the header, you send a header that says, basically the first time you access this website, always trust that public key. If the public key ever changes, or even if it's a valid certificate that's been validated by a certificate authority, raise an alarm because that, and don't let them actually access that page. So it would be similar to basically Bob writing down and storing the very first time he sees Eve's Alice's certificate and believes that it's her, but writing down that certificate, like Alice includes a message, a no-intermessage, hey, store this key and never trust any other key. So that way even if one of you broke into my, into the certificate authority and issued your own key for Alice, Bob would still not trust that key. So they've actually built this in the browsers. It's super cool. I mean this is a whole other area of how you do security on top of this. There's also SSL stripping attacks, which basically the idea is if you go to HTTPS first and somebody intercepts your traffic, usually what you do is if you go to HTTPS, it tells you to redirect you to HTTPS. But if you're a man in the middle, you don't have to actually do that redirection. You can just give them the default Google content. And then for every HTTPS link, you strip out the secure and only have them have HTTP links. So that way they go to www.google.com. It's unencrypted, it's HTTP. And then the man in the middle has intercepted that request to redirect you to a secure connection. And every link that you click in that session is always an unencrypted link, so they have a necessary command in the middle of you. So there's another header, maybe that's a GSTS that says, I'll only ever contact this domain under HTTPS. So anyways, so it's super complicated, but that is super interesting and I literally use it every day. So study how this works. So the Web of Trust is a completely different model of thinking about how to trust public keys and how to tie identities to public keys. And the idea is you now, rather than delegating to some other authority or some other corporation, you let the end users decide who to trust, how to verify identity, and to actually verify identity. And you can build this up into a nice graph that lets you propagate trust so that if I fully trust you, then whoever you have verified, I trust them just as much as you've trusted them. And different systems have different kind of levels and just trust degrade over time, right? You have all these kind of issues of how you propagate and think about trust. Let's do the second half of our homework assignment. Okay, I'm super excited about it. Okay, I just want to make sure this is recorded. Okay, so before we get into it, the goals of this assignment are you at a high level, you're going to create a public GPG, public private key pair. Do I need it? So I remember, I think one person used it for Git. Does anybody else have a GPG key? One, two, three, four. Cool. Okay. So the idea is we are going to be creating essentially our own Web of Trust. So you'll be creating a GPG public private key pair. You will then register that key with the website so that the website verifies that it's actually your key. Then you will get your key signed by 20 of your other classmates. So you actually have to talk to people and meet people in this class. I know it's terrible, but it'll be fun, I promise. Because so you have to get your key signed by 20 people in the class. You have to sign other people's keys, right? You have to sign 20 other, at least 20 other people's keys. But you will be given an adversarial key, which is not your name. And if you get other people to, if you get other people to sign that key, then you'll get extra credit and they'll get negative points. It's going to be fun. This is the fun part. So this is why you have to actually verify it. So this is basically trying to simulate an adversarial environment where people are trying to impersonate each other. So the kind of mechanics here, yeah. So basically you want to avoid signing any fake keys, right? So this, the idea is to force you to verify the identity that that key that you see is actually this person's key. So you'll generate a GBG key. The important thing here, so we'll look at GBG keys. They include both a name field and an email field. Your email can be whatever you want. It would probably be nice if that's something that actually directs to you. So you can actually use this later on. But your name has to exactly match the name that's an ASU system, right? Because then otherwise happy the other people actually verify that you're who you say you are. So I will actually check this. So I won't sign any keys that are not from you what your name is in the system. If your name is somehow completely different, you'll see on the website, it'll tell you who the things you are. If your name is somehow completely different, let me know and we can work something out. But if it's roughly the similar, just create a key like this because I don't want to deal with it. So your name on that key will be your name. So and we have to think like, okay, so how do I verify that you're actually signing the correct key, right? Because you could just make 10 fake keys that all have your name, right? Yeah, people sign those and be like, look, I tricked them to sign all these other keys. And it's like, well, it's not really tricking them because it's your name. Like, those are your keys. So the idea is, let's see, I think this has my, I think my name is Fubar. Oh, no, I still have my public key here. Okay. But you'll go to that link and it'll tell you what your name is. I don't actually think I've done that far yet. So you don't have a name yet. So it says none don't do anything. And the idea is, so you'll upload your public key to the submission server, so the submission server. So you upload your key. So the idea is you should only sign people's keys that have been signed by the public submission server because that locks in that you are owning this key, right? So rather than being able to create 10 keys, you're going to decide one key that has your name, you're going to give it to the server and the server is going to lock that in and say, great, this is your key, here's the signed version of it. You should use that to prove to everyone else that this is your correct key. That makes sense. So this separates branding keys that you generate from the key that you actually be created with, right? So any key that you want to sign should be signed by the course's key pair. And you, this is a public address. This is public. You should download this, import this into your key ring. This is the, I even put the, I believe I even put the, yeah. So this is the fingerprint. So you'll be learning and part of this assignment is you're learning what all these things mean and how to look these up, right? So this will be a lot of Googling and learning. The server will also generate you an adversarial key pair. So it's going to generate for you the public key and private key with the same email you gave it, but a random name, first name and last name. So I'm just going to use like a list of common U.S. baby names from like 97 and common last names in the U.S. Just so that we're clear that's where that name comes from. It's just completely random, but I want it to be something realistic-ish so you can try to convince other people to sign that key for you. So now at this point, you now have two keys that are signed by these, by the website. You have one that is actually yours, right? Which has your name that is verified in ASU system. And you have one that is not yours, not your name, but you have the public and private key at the back. So now the goal is you need to have that, your actual public key signed by at least 20 of your fellow students. So you'll see there's lots of, apparently this link didn't work, but there's a lot of links on how to do this. If you find good resources, feel free to share that out. If there's somehow slightly messed up to trick your fellow classmates, that's going to be funny. Five round rules in a second. So you should be trusting people, but also very much not trusting people. So that's why this is a fun site. And so these are guides on how to actually go through the process of signing keys and what you need to send back. And there's a lot of things that has to happen. What you should verify, so it's not just 20 random keys, right? You could just generate 20 keys and then sign your key with all of those, right? They actually have to be, so how will you actually know that the key was signed from a student in this class? It has the official class signature. Yes, you should demand their private, their, sorry, you can try to demand their private key. You should never send anyone your private key. You should demand that they send you their public key, which will include the signature from this fingerprint. If you don't see that, then it's not the correct key, right? So that's how you'll be able to verify that yes, 20 students in the class actually signed your valid public key. For people who sign your key, you don't really care if it's adversarial or not. That doesn't matter because you're not trying to determine that. Yeah, you don't need to determine that when they're signing your key. That doesn't really matter. So it doesn't really, I mean, I don't know, maybe you guys can think of better ways of how this would achieve your nefarious goals, but signing somebody else's key with your adversarial key doesn't do much, and you actually don't get credit for it, so it doesn't go under the fourth part. So you need to sign at least 20 of your fellow students' public keys with your actual key. So you'll sign, but this is where it gets fun. If you sign an invalid or adversarial key, you'll lose points. So maximum limit, I don't know exactly how much, it kind of depends on how this goes, but you'll only lose a max 20% of this. So it's like 10% of the overall homework score, but I think it's fair enough to make it like fun. It's like you won't be devastated if you end up signing just keys every day, but that's not a good thing, right? So you shouldn't like, you know, that's about a B level on this section, and the person who tricked you will earn extra credit. So how do I, how do, how does the submission server, how will I know that you actually did this? So you will, at the end of all of this, so before the submission deadline, you will submit your public key, you have to submit it again, because your public key, in GPG, every time you get a new signature, when you export your key, that key contains all of those signatures. So when you keep getting signatures, every time you export it, it will have all of the signatures in your public key. So at the end, you will be able to do GPG list key or show key to show your key. You'll see that you have all the signatures, you'll export it, and you will upload it to the server, which will prove that you got through that first part. You had your key signed by at least 20 fellow students. You will also, if you tricked anybody, you will export your public adversarial key, which contains signatures from students in the class, and then you will upload that to prove that you actually tricked them into signing your key. Right? Cool. So these are the only two things you need to submit. Well, you need to first even start to play, you need to submit your public key to get a signed public key and an adversarial key. You then need to will, by the deadline, submit your final public key and your adversarial public key. That should be good. And then your reading file, I want your name, ASUID, I want your thoughts, like how, like, especially on the usability of GPG, because that's a huge issue. So think about how awesome it was to use this. And if you tricked anybody, I want to see what cool techniques, like, how did you, like, this doesn't have to be not looking for an essay in this, but I want to know how you did this, right, like, for things. Ah, yes, yes, yes, yes. So once you upload your key, your public key, so this is the other thing is, well, for now, let's go with this. So the idea is you have one public private key frame that is yours and should never be lost or stolen or leaked. So there's no revocation in our scenario. So once you generate a public private key pair, and when you have that uploaded to the server, that server now will now, until two weeks from now, know that that is your key. So what should you do with your public and private key? You should guard them so you don't lose it. So somebody else can sign their adversarial keys a bit. What else? Sometimes if you lose your private key, yeah, bad news. So back up your private key and your public key, look that up. I'll put additional notes in here. Your public and private key. Do not lose it. It'd be like losing your code assignment right before deadline. Like, that sucks, but that's on you, right? So don't do that. You all have free ASU Dropbox, right? Yeah, boom. No excuses. Ah, we've not done too much. But you should not send out your public key on mailing lists. That's not a good backup solution. You could, if you were really daring, you could try to encrypt your private key with like a very super secret password and passphrase and send that out on a mailing list. Or you could tell people that you did that, but actually output random gibberish and see if anybody spends any time doing that. So thoughts on that? Questions? Yes? Do all 20 signatures need to be on your actual key, or what do you get from the signatures on your adversary? Yes, you also need them on your real key. So you get a good amount of extra credit points. I want to determine that later, exactly how much when I see how much that actually happens. Yes, so you need 20 signatures on your good key. Anything else you get on the adversarial key will be very good for you. There's 131 students still in this course, so it should be very easy to find 20 of you, and you have a mailing list to talk to each other. Cool. Okay, so ground rules. So what do you think are our valid ground rules we should have in here? If I don't want to get too busy, this is my priority, so you guys go overboard. Okay, I think ground rule number one, you have to follow the ASU acceptable computer use policy that you all read in the last homework assignment, right? That's a good ground rule, I think beyond that, it's kind of, I guess, no stealing anybody's physically stealing devices, I think that's pretty lame. I think beyond that, I think most of the things are applied, like you have an idea? I think beyond that, I think, you know, most things are fine. You want to try to create some personas or Twitter accounts or whatever you want to do with this new name that you have, that would be super cool. I mean, I guess I won't give you too many ideas, but yeah, whatever you want to do that's within those two things, so nothing, nothing physical, nothing that goes against the ASU acceptable computer use policy, so that would include no, like, don't buy like a $10,000 zero-day exploit to run against people or anything like that, so that would be not good. Okay, let's go back and finish up. Cryptography is a huge field. We barely stretch the surface of all the different areas, so most of the other areas, the idea is to give you kind of pointers to other things to go, to some of the other big problems, and I kind of think of crypto research as many different areas, so one is kind of as we saw breaking crypto, so how can you actually break real-world crypto systems? As we talk about this actually has two components, so one is the theoretical component, right? So if you were able to find an attack on AES that decreases the brute force drives from 2 to the 256 to 2 to the 254, that's actually a super impressive theoretical attack against that crypto system. Whether that actually makes it practical yet is usually an answer no, but over time attacks always get better and better. Implementation, so breaking the implementation of AES, there's all types of different, I mean this is a huge sub area between some of the things we talked about, side channel attacks of any types of way you can try to break or extract keys. Now that I realize this, I think this may be redundant, securing crypto, but the idea is okay, how can we make better crypto systems based on what we learned from breaking crypto, right? Can we create new theories? So one of the big worries with RSA is that well the problem is that there are quantum algorithms that can break, I believe can factor integers or do one of the things, I actually don't remember which one, I'm not a crypto person or a quantum computer scientist. So they've actually developed already new crypto systems that public and private key crypto systems that are immune to quantum algorithms. So they can prove that actually these will be secured even if we create a quantum computer, it still can't compute this faster. So this is electric curve, crypto falls under here. You create new implementation so you can think about how can we create easily create an implementation that doesn't have any side channels that has constant time operations. Super interesting things here about how to do this automatically, how to ensure that these things are done correctly. There are completely new areas of crypto that we haven't even talked about. So some of these things are homomorphic encryption. So the idea is you want to store your emails on Gmail but you don't trust Google, right? You don't trust Google to act with the plain text of your email but you still want let's say to search through your email. So they actually have schemes where you can encrypt your email messages, store them on the server and then the server can do different data processing over those entries. So one of the things you can do I think some is incredibly easy. So let's say I want to give you a bunch of numbers and I want to ask you what's the sum of all these numbers. You can actually do that without telling me what any of the numbers are, which is crazy. The other interesting thing that is really big now is secure multi-party computations. The idea here is let's say there are two or more of us, three of us in this room who let's say we are healthcare providers and we want to compute what's the average cancer rate in all three of our data sets. But for privacy reasons we can't actually share our data sets with each other to compute that. Secure multi-party computation is a way that we can actually do this and we each run some algorithm and the results of that combine together to give us the result of the average across all the data sets without revealing any other information. The problem is it's insanely slow. That's the key problem here. So there's been like I mean literally like so slow that they made 100x breakthroughs which like revolutionized things but still are super impractical but got computation down from like I don't know 10 years to like I don't know it's it's coming down a lot more so and other types of areas that I'm not familiar with that are still new and interesting so all kinds of cool ways of thinking about how to use secure information but also do interesting things with it. And there's another kind of area that makes worth mentioning is applied crypto. So knowing about all of these things is cool like building AES, building RSA is cool but how do you actually use that in things right? How does any use WhatsApp right? WhatsApp now has end-to-end encryption right? That's standard crypto stuff but actually doing this in practice is super impressive so being able to do and this means that assuming you trust their implementation I think I'm not sure how many ways you have to verify this but if you trust their implementation WhatsApp has no idea what messages you're sending so your messages are 100% encrypted when they go across their servers only the endpoints the other people with those phones actually can read your messages. So it's a really interesting area for research and how this is going so applied crypto is also another super interesting area so with that thanks