 All right folks. Happy Tuesday. Shall we get started? Alright, so who can refresh our memory when we're left off on Thursday? What is the Bella Padme model? What is it for? We'll talk kind of about it instead of the detail of what it does. Yeah, so different ways of determining a subject's access to objects. Yes, right up, breathe down. Right, so in terms of levels. So why do we start talking about Bella Padme? What was the context? Security. Security level, security categories, right? And specifically under the guys of mandatory access control. So what makes a mandatory access control system like this different from a discretionary access control? Like strict rules and... Yeah, so then what happened different than from a discretionary access control? Kind of. Close. Yeah, and you have the spirit of what we're looking for. The key difference between the two, yeah? Is it the owner of the object and the object? Yeah, so the specific differences in discretionary access control. The owner of the object gets to choose what the access rights are on that object. Whereas in a mandatory access control, that's certainly not the case, right? And this makes sense when we think about it in terms of a military security classification level context. Just think if you have, you created an item or you own an item, that doesn't mean that you get to choose the security level of that item, right? You can't just say, well, I'm going to give Bob read access to this file because that could compromise the entire security, right? You're trying to make sure that things that are top secret are only read by people in top secret and then that information can never flow out. Cool. Non-discretionary is the military law? Mandatory access control. So the discretionary access control, the owner gets to control. Mandatory access control, essentially the system controls the access rules which is why we're defining the rules here. And then what was the third one we talked about? Originated. Originator-based access control. So what's the difference there? Yeah, whoever creates the data or creates the object can control who has access, right? So three, and these are the kind of three, I guess, discretionary and mandatory access control are the most common ones. So it's very important to understand the differences there. Originator-based access control has other ties that we'll see. Great. Okay. So we, on Thursday, yeah. Mandatory access control is, I believe on Android, it's called SE Android, Security Enhanced Android. It comes from Security Enhanced Linux, which is a mandatory access control that the NSA created for Linux. So this allows the administrator, or you're not going to add it in your phone, this allows the device manufacturer, Google, Samsung, whoever to add additional rules to lock down your device that people can't, like this is used to control, I believe, on devices like access to microphones and something like on the phyto system in addition to the information-based model. So it's a way of scoping and restricting access. So modern systems tend to use combination of both where they're most appropriate. All right. So Bellapagela, on Thursday, we derived ourselves the rules for Bellapagela. So somebody remind us what those rules were, and we know at the kind of at a high level we've talked about them as read up, write down. But you don't want people lower than the entire feature of being able to read up, right? There you go. So it should be which way? It should be... Read up and write up. Read down, write up. Read down, write up. So you can, if you have a high security clearance, you can read anything below you. You can't read anything above you. Above your security clearance level. And similar for writing, we can write up, but we can't create and write up to objects that are lower than our security level. Cool. So then how do categories then affect that? Because that seems like a very simple model. And why do we want categories? Give us more fine-grained control so that somebody with top-secret clearance doesn't have access to everything that's top-secret. They only have access to those categories that they need to do their job. Cool. So what we did is we defined some notion of... We defined this notion of dominates, right? So we had L and C, right? So let's say this is for the subjects and we have the objects, security level and categories. So we'll just make this L-S-C-S-L-O-L-C. So what was the relationship here like for, let's say, reading? So how do we know if a subject can read an object? So the levels, how do we write read down? Yeah. Well, the L-S has to be greater than or equal to L-O. And then there's an M and the same for the CSN. What's the relationship here between these? Can I just use less then? For greater than? CSN. Because they're sets. Right. Because they're sets, right? So you can't really make sense to think about less than. So what was the relationship we want here? The subset operator. Yeah, subset operator, right? So to be able to read an object, the subject must have... The categories of the object must be a subset of the categories of the subject. Does that make sense? And then write was reversed. So we can call this relationship dominates. This is... And I don't know... Let me erase all of this so we can look at this nice. Okay. So we can call this dominates. So we just define this relation rather than having to define the inverse. We can say that a security level dominates the other one if... And only if the L is... We're using L and L prime instead of L-S and L-O. But basically it's essentially the same. L-S can read a subject or an object if and only if S in terms of levels and categories dominates O. The star property is the reverse of this of right. So this guarantees us essentially right down but also with categories. And then we have the star property of righting. So we can write up. And as we saw, we get actually a nice little lattice here. This is where the dominates term comes in. We get a nice little lattice here or different categories. This lattice could be very big but you can still always do the subset operation. Cool. Okay. So now we can run through some examples very quickly to test to make sure we got this covered. So A has top secret level and the categories Ace. And B has secret and the categories NATO and Ace. So can A read something that is top secret and the empty set in categories? Yes. Yes, why? First condition, top secret, less secret, top secret. The empty set and the subset is that containing Ace. So we can read that. Yeah, cool. Okay, what about writing? Can we write to something that is secret that has the category of Ace? If this would be us, we can write which direction? Up. And this is writing in which direction? This is a top secret writing to a secret document so that's writing down. What about reading top secret NATO Ace? Yeah, so NATO and Ace is not a subset of Ace, right? And think about the intuition here. By reading this document they got access to NATO information which is something that they're not clear for. The category that they're not clear for. Cool. Writing top secret Ace NATO? Ace NATO is not a subset of Ace. That's correct. So top secret, so writing in top secret created top secret document? Yeah. And what about the categories? Right, so for writing it's the other way around. So for reading, the object needs to be a subset of the subject. Right, for writing the subject has to be a subset of the object. Right, so the way to think about this document, again this is kind of the writing up philosophy. Right? A is creating a document that has both Ace and NATO which they will not be able to read. But they can still create it just fine, nothing. Writing this object doesn't violate any of our overwriting security properties. Does that make sense? Just like we talked about having secret clearance, writing a top secret document does not violate the security properties. Right, it's part of writing up. Cool. Okay, I will leave you to do this later on your own. We don't need to walk through all these examples, but this is a good way to check yourself. Alright. This is not the only type of access control, so we've talked about different kinds of models. And actually a lot of what we've been talking about has been going to thinking about access control in terms of abstraction. Right? So we keep, when we show the matrix and we show all the users and subjects, we say hey, maybe it doesn't really make sense to think about individual users. Maybe it makes sense to group users into what their job does or what their role requires of them. Right? So there's a whole bunch of research on role-based access control, which is an entire area and field. This is probably one of the most standard types of access control models. So basically the user's permissions are determined by their role, who they are or their subject. So rather than the discretionary access control, which is the identity of the user or the clearance level in mandatory access control. And this definitely has much more, so why does this have, is this statement true that it's a more natural expression of business logic? You know, in some sense, the businesses already abstract on this level, right? So you have different roles, software engineer, developer, tester, all these other kinds of roles. Rather than giving each person unique, let's say, job responsibilities per person, you think about people in terms of roles, right? What does the role do? Those types of things. So it makes sense to model things in access control that way, right? Similarly, thinking about, let's say, something like Piazza, right? Piazza has well-defined roles, like professor, TA, and students, and then TA and professors are kind of grouped into an instructor. So there's hierarchy of levels, but different people have different access control on there. Cool. So another interesting topic, so this kind of came from role-based. And again, it's kind of, I think of it as an abstraction of role-based access control. So in role-based access control, everything is derived from what the user's role is, right? But the role may just be one aspect of a user. So for instance, so every user, so we all have some attributes, right, that are associated with us, maybe age, ID number, group membership. So you may be, and then you could make a complex Boolean expression on attributes. So for instance, and this is actually used in, even in things like, let's say, the law, right? So the law doesn't say that, I don't know, if you think about, well, it looks like a popular age-based restriction. Drinking, right? So the drinking age is 21 and over in most states, right? That's an access control policy that's based on what you, is it based on who you are? Does the law say that these people can buy alcohol or purchase alcohol? Based on age, based on an attribute of yourself. So if you're at the store and there's part of you, what are they trying to verify? They're trying to verify this attribute, right? Trying to see, do you have the attribute that you are over 21? Interesting thing to think about is what other information are you giving them? What other attributes are you giving them when you give them your ID cards? Your height, weight, eye color, what else? Your driver license number, is that useful information? Right? So you could maybe think of an interesting thing would be, how could you prove that you're over 21 without also divulging all this other information? Right? So it's kind of an interesting attribute-based access control challenge. How can you prove that you're over 21 without revealing all this other information? Anyways, something to think about. So this is another kind of... And so one of your attributes could be role, right? So in that sense, attribute-based access control is a little bit more... Can encompass role-based access control, but you can get away with pretty complex things here. Any questions on these? Cool. And this is to show that it's not really just the three we're talking about. There's all types of mix here. And I will say that there's a lot of... I like to kind of end every section on what the kind of current state of research is in these areas. Access control is a very active area of research. And I'd say some of the interesting things are on usability. So we talked about... So why is usability of an access control system important? Get in the way of the user getting their job done by a long process or restricted. Yeah, so you have two problems, right? So you have one, building the problem of if you get a user's way, you may restrict them from doing their job. You have the other one, and if the access control is too onerous, they will find ways around it. Right? So what else? Why else is usability important? So that's on the user side. Yeah. So you have maybe two... Maybe your access control rules are too strict for teacher coming in or don't do what they're supposed to do. What about... Like for the administrator of the system, it's too complex to set up the rules, they're not going to introduce it. Yeah, so think about it. So you think... We talked about Android a little bit, right? So the companies that are writing those mandatory access control rules for your phones are small companies or big companies? Big? Google? Samsung? LG? Right? Or some other Android manufacturers? Huawei? Huawei? Yeah. Are those... I don't know, maybe I'm their Android phone from a tiny manufacturer? They're very interested to know. So anyway, so you think... Those people are writing these access control rules that go into your phone, and there's research and papers that have studied those rules and said, actually, these rules... You know, there's a lot of different rules or clauses in these rules where a malicious application could do something that they're not supposed to do because these rules aren't correctly created, right? So you have this problem of usability from both sides. It's important, especially in access control, to think about these things complementary, right? So usability of the end user, but also usability of the administrator to write these rules to verify that they're correct. All those kind of things that we talked about can be things. Flexibility. So why is flexibility important? Yeah. The flexibility in terms of adding new users, changing roles, these kind of things, changing adding rules, right? So how flexible and kind of related to that is a little bit of robustness or reliability. If we add a rule, is that going to break things? Are we going to allow something that we don't want to have happen? What about expressiveness? What does that mean? Yeah. So what type of rules do you want and what type of rules does the access control language allow you to express? Right? So we're just thinking about roles when we talk about this a little bit. We're talking about this in the Unix access control model, right? It's a real pain to just share one file with one person in the Unix model. Because the only three things you have to give access to a file is the owner, the group, and everyone else, right? So it's difficult to express these kinds of rules. It doesn't mean that it's possible. Federation is actually the other interesting thing. So when you think different organizations collaborating together, right? So think about, let's say, maybe use the Gmail for their ASU email. Yeah, do you sign on? Like, how do you sign on to those systems? Okay, you start with Gmail and then it goes to ASUs login and then ASU tells Gmail that, yes, you are this user in the ASU system. Right? So clearly there's interesting collaboration there. If you go into this, I think, technically, like, ASU could be going to kill that Gmail account. So they can restrict your access to it, not Google. So Google is following and buying by essentially access control rules that ASU is creating, right? So this is kind of the idea of Federation. If you have different entities that are in charge of different things, how do you link up and be able to talk and communicate between each other? Any other questions or thoughts on access control? Usually, yeah, right when I say that, somebody raises their hand. Yeah, so that would be one thing about flexibility, right? So let's say, so you have a system that, in all role-based, right? So you say somebody gets promoted, you change their role, and then now they have whatever permission that they're supposed to have. Great. What about somebody that's part-time or that is splitting time between two different roles? Right? If your system only allows one user to have one role, then it's flexible in some sense, right? Because you can easily add rules, change rules, but you can't express a policy that you want to express that says this user has two different roles, right? So you can work around that by having that, like, creating two fake user accounts with that user that they need to go between to do different stuff, so then that's more negative usability problems. So it's kind of all linked in various ways, yeah? Yeah, I would say flexibility is very much how easy is it to, I would say, make changes or modify the system in general, and then expressiveness is can you express your desired policy in the access control system, right? So similar when you take, you can think of it in terms of, when you take 340 different languages, have different levels of expressiveness, things that you can express in a language, but you can think of it just as, can I actually create an access, like, does this system allow me to create an access control policy that does what I want it to do? Anything else? Just stare at you for two minutes. Okay. Cool. Then we will go on to cryptography. Okay, so, but before we get into this, so what is cryptography? Usually there might be a key involved, puzzles, I like that. Cypher's, yeah. I guess it would just be like the study of making sure that people who need to see something can see it. Okay, this is that, so maybe, so there's maybe an underlying thing of, and how does that tie into the three security properties we're talking about? Okay, so maybe some way, and how, heads up, so, yeah, hey, so these are all good, where is all this coming from? Yeah. I don't know, where do you learn all this stuff? Yeah. No? Sure. He's saying like, where do you learn the CIA? No, no, no, cryptography, like, where are all these things coming from? Just like common concepts that are used to be a thing. Yeah, so cryptography is not like a super esoteric thing, right? It's something that we've all, we've seen kind of in our daily lives. So you can break it down a little bit into, and I'm not an linguist or etymologist or I don't know whatever the person who studies word meanings are. I also don't know Greek, but apparently it's derived from the Greek words of hidden or secret and writing. Right, so this actually gets to the core of all these concepts that we've talked about. Keeping things confidential, how do you write something, how do you convey information from maybe one person or one entity to another without revealing that information to somebody else? And kind of I like to think of it as how to keep information secret or hidden, right? So what, there's kind of, there will be some, let's say easy ways of keeping information secret. Yeah. Okay, just jumping it into a lock box and waiting for somebody to, what if somebody breaks your lock and bring a hammer to your lock? Good, bad luck, yeah? Well, like you can keep information secret using like math or math. So maybe you can keep, well, we'll talk about that for a second, we'll come back to that in a second, but you can keep it maybe secret using math. Yeah. Yeah, you can keep it secret by not telling anyone, right? That's actually a very good way of keeping information secret. If you're the only one who knows the secret. If you're the only one who knows the secret, in this case we assume one party has some information, right? So, yeah. Because I would agree about random number generators, I don't feel like they're random for whatever. But they were talking about profit, actually, and we're saying like if you think generally pure random numbers, it is a way for actors to not need to deal with random numbers to get to the information. Yeah, so we'll get into this, and this actually has a big impact into cryptography. Yeah, so, yeah. Yeah, okay, so this kind of, so has anybody developed a cryptosystem before? Never like the messages to your friends in like a love your school or something? Yeah, yeah. Are you asking where it was? Yeah, I mean, I don't know how much you know. Yeah, yeah, I mean, it was just, we had symbols for letters but I don't know if you see them. Yeah, so basically like making up a language that only you and the other side understand. We had one, when I was in elementary school, I think it was something like, you take the first letter of every word and that would be the actual message, so you could write big gibberish or whatever a better is a sentence that looks right and then you take the first letter of each word and that would be your actual message you were trying to send. Anybody else develop? Yeah, a couple of years ago, a friend of mine developed, I mean, it was just like over channel essentially and we were just saying like every offset between the time delay of the first packet and the second packet would be like this, the transfer message. Yeah, so yeah, you can hide, so this is kind of maybe hiding information rather than necessarily keeping it secret, yeah. Is it pig latin? Pig latin, kind of counts, I don't understand pig latin, but I never learned, but yeah, you could say pig latin kind of counts, can you give us an example? Yeah. For people that don't know, you could look at that, I don't know if we can be yet, so like minor transformations to English word guesses, you don't know what I mean, right? Exactly, yeah, so you could use it, my neighbors growing up did this, they would talk to each other in pig latin and I wouldn't know what they're saying. I should probably learn that at some point. Yeah, cool. Okay, so nobody, well, we touched on it briefly, but nobody mentioned cryptocurrencies. Isn't that cryptography? Maybe instead of concealing information, it's more about that they were verifying or integrity, maybe? And like the reason, like would you say cryptocurrency itself is secure and blockchain technology like underlying it is secure? That is a, I don't know if I would say any of those things. I would say that, I mean the interesting thing is how crypto and the word crypto has been subverted by the cryptocurrency and the blockchain, all these types of things. I think there are interesting things there in solving interesting distributed systems problems that they're using cryptography based techniques which is kind of why they get this name, but the key problem they're solving is one of kind of a distributed systems problem. How do you derive consensus from the untrusted nodes in your network? Right, so that's kind of the key thing that they're solving. So yeah, we won't be talking a ton about cryptocurrencies in here. Keeping messages secret, although maybe you'll learn enough here to be able to break some cryptocurrencies implementation of cryptography, which definitely happens. Cool, so before we get started, we need to actually define some terminology. So we actually already hit on some of these things. And we can go kind of start with our general knowledge of these words kind of being kicked around in English and then maybe try to refine them a little bit more. So what do we mean by encryption? Just applying a reversible algorithm to something you want to keep hidden. Okay, so let's see. So applying a reversible algorithm. Yeah, so applying a reversible algorithm to same as last part? To something you want to keep hidden. To something you want to keep hidden or secret. So what about doing nothing? Is that an algorithm that's reversible? Yeah. Yeah, doing nothing? A good encryption algorithm? No. Why not? I didn't do anything. Because I didn't. Why do we care that I didn't do anything? It's literally what you want to keep secret. So it's not actually concealing the meaning, right? So we have this other requirement and we'll get to the reversible in a second but we can think of it in some way of just transforming a message, right? Such that the meaning is concealed or hidden, right? So this is all the things we've been talking about, right? Pig Latin could be considered this. Maybe, I think it's a middle school high school teacher that recommended that we learn Greek. We're learning Greek letters to do whatever formulas and stuff. And this person said that we should use that, like, learn the letters to write in Greek to each other and that would be a way to pass notes. So we have this interesting thing of like, how do we tell if the meaning is concealed, right? And to what extent? So doing nothing is obviously not a good encryption mechanism, right? These other ones are also maybe not very great because also what it has to do is look up Greek letters and match maybe, like, go backwards pretty easily. Cool. So what about decryption? Right, so taking the, so that would be the opposite of encryption and this is, well, kind of important because if, so let's say, okay, so the process of transforming an encrypted message back into original form. So this gets back to the reversible thing. So let's say I have an encryption algorithm that just outputs random numbers. Do I have something that I've transformed the message so that the meaning is concealed? Yes. Yeah, but then how do you decrypt that? You can't. You can't? Well, yeah. Have you transformed the message? I would say you destroy the message. Sure, I have a message that takes in a, I have a message that takes in your plain text that you want to send, the message you want to send. Yeah, output. Let's see, this distinction, because if it's randomized, then it needs no longer a message. What if I output all zeros? I output all zeros. Huh? What if I output all zeros? Well, then you're still destroying it because there's no longer a message. To transform a message, you have to start a message and end a message. You otherwise want to transform it and you're destroying it. Yeah, we'll put that. Yeah, so the key problem is this lack of a decryption mechanism, right? Because it's kind of a little bit tricky because then we'll see a really good encryption algorithm that will look random, right? I mean, we'll have all the properties of a random message and that's what you want because it will reveal nothing on the message itself. But if you don't have a decryption mechanism that is basically useless, it's not really a encryption mechanism. Yeah. Yeah, so we'll get back in a second because it's not quite, we'll definitely get there. It's not quite in the information passing game of what we're trying to do here, right? So we have one entity who wants to communicate with another entity something secret. So we'll build that back on. Crypto system. So this is something that is, I mean, it's just a word, basically a system that describes how you encrypt or decrypt messages, right? So we can think of, you can think of Pig Latin as a crypto system. There's a way to translate English into Pig Latin and there's a way to translate Pig Latin back to English. Plain text. These are just, and now we're just kind of using more kind of cryptographer friendly terms. So these are all terms that we're going to use here. So plain text is the message in the original form. It's plain, hasn't been altered. Cypher text would then be the message in its encrypted form. So after we run the encryption function on the plain text, we get Cypher text. Good questions. Cryptographer is somebody who invents encryption algorithms and cryptanalyst is somebody who breaks encryption algorithms or implementations. So I will, this is going to be a repeating theme. I'm going to say over and over again. It's totally fine to, for now, you should never be a cryptographer. What do I mean by that? Yes, use well-studied, well-established standard cryptography libraries. And this is something that's very difficult for computer scientists to do because we like to build things. We like to say, I can implement this cryptosystem. We'll see over and over again that this is fraught with peril and basically it's calling don't roll your own crypto, don't build your own crypto because you will, there are many, many ways that cryptanalysts have broken crypto systems where even if the math is beautiful and the math works, the implementation is flawed in really subtle ways. So maybe I'll make you promise at the end of here once we've seen everything. Yeah. But it's totally fine to build it to learn. Yeah. For sure. So that's part of keeping up to date of what the current latest attacks are and what they kind of mean. There's some aspect to that, but you'll know, like, if you're using... What's the name of Google's encryption algorithm? Google has a really good algorithm, sorry, not algorithm, a library that's available in a bunch of different programming languages. If you use that, if you use it with, like, AES, 256-bit, like, you're good. You will know when that's broken because that would be, like, a huge national story. Yeah. So what's a cryptographer? That's a good point. Is a cryptographer invent the algorithm or the system? No. I think that's splitting too many hairs at this point. I'd say in some sense, like, a cryptographer is most... I mean, I would definitely not put myself in this category, too. So I'm not trying to tell you that don't be like me. I'm not a cryptographer. I don't invent encryption algorithms. I know how to use encryption algorithms to do various things, sometimes with research, but we're never rolling and building our own cryptosystem from scratch. Yeah. Say it again. Publicly broken. Yeah. So there's a lot of people studying these types of things, right? So you would... If it's ever become public knowledge that AES is broken, there will be massive, massive panic. And as we'll see, I mean, cryptosystems being broken are that it takes, instead of whatever, two to the 256 brute-forcing attempts, it takes two to the 250 brute-forcing attempts. So that's when they consider it broken, and then it becomes big news and everybody moves on to the next thing. Cool. Okay. So we get some really interesting and nice security benefits from cryptography. The actual main one that we'll talk about is confidentiality. So this kind of drives a lot of these... Basically what drove the study of cryptography is confidentiality, right? So we want to keep the secret thing secret. As we'll see, there's actually integrity aspects. So we'll look at various types of things, but what was integrity again? Yeah. So you can think message or data, a data write. You can verify that the data wasn't altered. So you can think of, if we have a cryptographic system where I can encrypt something, and then I send that to you, you decrypt it. With integrity, you can verify that nobody changed that information along the way. So in addition to confidentiality, which would be knowing that nobody else was able to read the contents of that message, you could verify that nobody was able to change anything about that message. Which one's more important? I think if you argue in different cases, certain ones are better than others, but in general, right, this is kind of used a lot in authentication. We'll get to this in a bit. Non-repudiation. I think we touched on this in the overview. What was that? Repudiation would be saying that if I didn't do this, I didn't send this message, right? So non-repudiation would be, you can't do that. So you can't claim that you didn't use your credit card or that you didn't send an email, these types of things, right? So this was another interesting property. Okay. We're going to break it down and we're going to study cryptosystems because we have a lot of formalism around them. We'll see. This is more of a preview. So you should be, as we talk about these various aspects of cryptosystems, we can use cryptography for, you should be asking yourself which of these properties does this help. Cool. Okay. So we can represent and think about cryptosystems formally, a little bit more formally as a quintuple, so a five-tuple, where M is a set of plain text. So basically, what is the language of plain text? Key is some set of keys. So how many possible keys are there in your cryptosystem? C is a set of ciphertexts. And then, so this is just saying, you can think of it as like, what does the input look like? What does the output look like? And what do keys look like? So why is a key important? What do you mean by key here? Yeah, so as we'll see, and what we'll define here, so you can think of encryption functions are essentially mathematical functions that take in a plain text and a key, and output what? Ciphertexts. There's all this is saying mathematically, right? E is a set, and you can think of a cryptosystem, could have one encryption function, it could have multiple, we'll kind of go into that. But basically, you think of input, right? So it's just a mathematical function that takes in a plain text and a key, and outputs a ciphertext. And so decryption function does what? Ciphertext and key and outputs what? plain text. Yeah, so the opposite, right? It needs to be able to do this. This makes sense. Tip for reading math functions, I always think about them in terms of types. So this is defining a function that has the type, takes in ciphertext, and a key, and outputs plain text. Similarly, encryption is a function that takes in a type of plain text, and a type of key, and outputs ciphertext. Okay. So, where does the big need to keep secret things secret come from? I said cryptography is like this old well-studied topic. Why? You can't trust people? That is definitely true. Yeah. We wanted to keep things secret. Okay, we wanted to keep things secret for about as long as we've existed. In what context though? Or, yeah. I don't know. Is Morse code like that? Or can anyone do that? Yeah, so war. So Morse code is, would be a very poor cryptosystem because it's, whatever, it's easily like the key. There's only one key, right? Like translating back and forth. But you could think about a cryptosystem on top of Morse code, right? And we'll actually get to that. So you could think of Morse code as just a transmission mechanism. But you could take your original message and encrypt it, and then send it over Morse code to somebody else. Good, cool. Yeah, so war, right? So why are secrets useful in war? Yeah. You don't want your enemies to know what you want to do? Yeah, you don't want your enemies to know what you want to do? Why? We'll use it again too. Yeah, they'll give you the game to you, they can ambush you. What else, yeah? You won't be able to, like, translate over radios, but anyone can take us to radios. Yeah, so you may want to be able to translate, well go older, before radios. Yeah. Repeat the wrong information pool. Yeah, so you don't want, let's say, so like olden times, right? You have a messenger you have to dispatch that has like, right up Morse, or run or do something to go to your other general that's somewhere else. And so you have to worry about what happening when you send this messenger off. You think it's intercepted? Intercepted, so that now the enemy knows your plans? What else do you have to worry about? The person defecting? Yeah. If your other general got the message. If the other general even got the message, right? So maybe the person got lost and just never arrived, it's like, am I anything? Yeah. The message got changed, maybe somebody intercepted it along the way, and maybe even unbeknownst to the messenger, so they think it's exactly the same. Yeah. The messenger is still in fire. But yeah, the messenger, well, doesn't forget the message, I'm sure they will not show up with that. Right? So all these things are real world things, and this has been around since literally, I mean, forever, right? As long as, so the first cypher we'll look at is really inspired from an old cypher. So this is called the Caesar cypher. And this is literally, so this is from a text called the life of Julius Caesar, and I think it's 56 AD. No, that doesn't make sense. I don't know what that 56 is for. It's 56 volume. Alright, so you can look it up, this quote. If he had anything confidential to say, he wrote it in a cypher. That is, by so changing the order of the letters of the alphabet, that not a word could be made out. If anyone wishes to decipher these and get at their meaning, he must substitute the fourth letter of the alphabet, namely D, for A, and so on with the others. So what does that mean? I wrote this a lot, so we should make sure we all know. So it's 56. So then by shifting the entire, so you have the alphabet from A to Z, right? So shifting it by a four, you have the first letter B, B, and the last one B, C. I don't really know, but I think that's right. So what's, okay, so let's actually think about this a little bit in the context here. So what's some of the benefits? So there could be, if you look at it, it just looks like what? Like gibberish, right? It doesn't look like, I mean obviously they're not in English, but we'll think about it in English, right? It doesn't look like valid words. Right, so then, yeah. Right, so is that a useful thing to be able to use it through my name? Yeah, because what's the alternative? Do they have computers? No, they have people, but I mean, being able to read and write looks like a luxury at this time, right? So you can easily, so what do you need to know? So if we're going to exchange a message in this crypto system, what do we each of us need to know? Yeah, just how much you shift it by in which direction? So we need to know somehow the key, right? And the key in this case is what? Yeah, the number to shift, right? So it could be, so what numbers are bad? Zero. Zero? Zero is bad? 26 is also bad? Yeah, so right, all of these things are bad, so we can think that there's, you know, there's clear guidelines or rules to using these, and we can represent this and kind of look at this using our, the formalisms that we've created. So in this case, what's M? So what is our plaintext in? English. Yeah, but what in English? So letters, so what letters? A through Z. A through Z? What about uppercase? How do you shift, like if you're doing this by hand, how would you shift like uppercase A versus lowercase A? Right, would you also shift those uppercase in which then what are you getting uppercase versus lowercase? Right, so we'll just do one case. What about spaces? Ignore spaces? Why? Yeah, because what do we shift spaces to then? Right, it becomes, and then what does, so like in our A through Z alphabet where do you put spaces? Right, there's not actually a natural placement for space. And so the shift, how do you know where that is? So one way we can get around this is just say ignore it and then what do we do when we send it, when somebody's decrypting a message? Put the spaces back in to be able to breathe the message, right? It should be fairly easy once we see the plain text. Cool. Alright, so we can represent this pretty easy. So M is a set containing sequences of letters, right? So just A through Zs. What's the key? Number of shifts, yeah. So we'll use, and we'll say that does it really make sense to have shifts 26 or higher? No, at a certain point we're just looping back over the same letters. So we can just say, you know, key zero is the same as key 26, which is the same as whatever that times two is, which I wasn't able to do in time while I was talking, yeah. Yeah, well, we can think of it as a crypto system. The key could be anything from zero to 25. And then we can talk about later the properties of different keys, right? We could say key zero is back. Alright, cool. And then we can do the encryption. So we can go over. So the encryption function, the encryption function would be, basically, if we number, right, so this is we can represent this a little mathematically, we remember the letter M, so zero would be one, or sorry, A would be zero, B would be one, right? Plus K, so I shipped it, and then what's the mod 26 doing? Yeah, if we do Z plus one, it needs to loop back around to A, right? So that would be 25 plus one minus 26, mod 26 is zero. I hope that works. So as we're defining the encryption function, decryption function, what does that look like? Yeah, we can kind of do it in many different ways, right? We could say, so here, and this is actually an interesting point. Why are we using M in the encryption function and C in the decryption function? C is part of the cyber tax, and N is part of the plain tax, right? The plain tax is capital M, cyber tax is C. We also don't have one here, although maybe we'll get to it, but what is the set C? Oh, that's the next one. It's the same as M, right? So our cyber tax is exactly the same language as our plain tax, right, which makes sense. We don't put an encryption out of our A through Z, and we don't get out numbers, right? We're only going to get out A through Z, they're all going to be shipped in the exact amount. That's a good question. I think it doesn't do anything. Is the question why we're adding by 26? Yeah. And so we don't get a negative number? Yeah, it just makes it easier for representation, like for display purposes, but you can very easily get rid of that. The model can't hold negative numbers, but yeah. Cool. So this is our formal crypto system. So you are a, I don't know, a well-edged, I don't know how to say this, you've been transported back into Roman times. You've somehow met up with some barbarians who are attacking the Romans. You have some messages that you've stolen from Caesar. How do you attack this? What do you have? So when I say attack this, yeah, so first, we need to define some things. So you're now the adversary, you're the person who wants to break the crypto system. What do we assume that you have, or what do we think that you have? Yeah, you'd say, well, I was really lucky I went to 365 today because I magically got transported back and have to solve a Caesar cipher. Well, a message, I have to solve a cipher and the message is written by Caesar. So, let's assume you know Old Roman, I guess. We have to kind of define for the rest of this. So, let's say some assumptions. So can we assume that we know the key? Right, if we stole the key, we have, and now we have, let's say, cyber text, and we have the key, what can we do? Yeah, combine them with the decryption algorithm to get the plain text. Right, we're not actually breaking the crypto system in there because the, this assumes that the two sides have the same key. Right, and we don't, that's how we know what the key is. Yeah, so let's, let's pause a little bit. We want to talk about kind of, so this is, so we'll, one of the things we should always assume is that the adversary knows the algorithm, but not the key. Right, we, we talked about, okay, it makes sense not to know the key, but is this a realistic assumption? Should we assume that they don't know the algorithm? So it could be that somebody from Caesar's army defected to our side, and so now we know the algorithm that's being used. What about in general so you're attacking some crypto system, yeah. Yeah, so there's standards of what algorithms to use but the details of the encryption system are public. So, yeah. Yeah, so even a closed-source system, right? If it's a binary that you're distributing and you're versing into the binary and understanding the algorithm. So the way to think about it in another way is if the security of your system, if you say this, my system is secure if nobody knows the algorithm that I'm using, then in that sense, your algorithm is part of your key. Right? And so you say, well, if you keep your key secret, then you can keep the key. In that sense, if the algorithm is released, it's just as bad as releasing the key, so you have a really crappy algorithm. Right? Because the whole thing's going to fall apart whenever anyone knows what you're doing. Much better to assume the adversary already knows exactly how your system works and then say, okay, what can they do? Can they break this crypto system? This is a general security property called, well, or I guess, insecurity principle of security through obscurity where people like to convince themselves that, aha, I've made something really awesome but nobody would be able to find it or nobody would be able to know what it is. Therefore, it's secure. All right. So we assume we know the algorithm. Now, there are various different ways that an adversary could have. Right? So, and we're talking about breaking crypto systems, right? We want to either maybe steal, like we want to infer the key from a message. Right? So there are going to be different types of things that we want to do. So let's say we've captured, our barbarians have captured a messenger. What do they have access to? Cypher text. Do they know what the plain text is? No. No. Right? Do they know what the key is? No. It could be anything in that set. In our set, what's the size of the keys? 26. 26. That's not very large, right? But let's say it's in the millions. Right? Yeah. Yeah. So we, let's say, Caesar's generals, before they went out on this thing, they all were in a room together and they were in the Roman camp and there's nobody around like, and so they said the key is going to be 21. And then they all dispersed and then now they can send messages to each other with this key. Right? So we could assume that we have the Cypher text. Right? So we can assume, okay, we have the Cypher text, we've stolen maybe one message. Maybe we've stolen N messages, we've stolen a bunch of different messages, but we only have access to the Cypher text. Right? In that case, what are our goals? What are we trying to do? One thing to do would be find the key. Right? Find the key that was used to encrypt this message. What else though? Do we need to find the key? Isn't that just brute force? That's what I meant. Yeah, but at a higher level, right? So we can try to find the key, but what else are we trying? What else can we find? Yeah. So I suppose the things we're looking for are the key, you're looking for the algorithm, and then you're looking for, and once you have the algorithm, can you brute force by just trying a bunch of different things on the algorithm? And then... Yeah, go ahead. So the last thing that you can look for in this example, is a pattern between the Cypher text and real speed. So a very common... This is more... Sorry. No, no, no. It's okay. We're talking more high level about what capabilities an adversary could have. It doesn't have to apply necessarily to this cryptosystem. It could apply to any cryptosystem. So if we have the Cypher text, we may want to steal the key, right? Are we going to derive the key from the Cypher text? Yeah. Could it also manipulate the Cypher text so that the function would be virtual? Yeah, so maybe we can manipulate the Cypher text so that's why I'm saying attack. But maybe... So can we maybe derive... What if we were able to derive the plain text without knowing the key? Feel useful? Yeah, if we can read this one message, that's great. I mean, it's not as good as stealing the key, but it's still pretty good, right? Okay, so then... A more stronger adversary, yeah. We'll give you a 10 of our variants. I'll work on that. We'll see. We'll see how that impacts things. But on a high level, do you mean 10 of our variants are going to read and write? I think you've got it. High standard is 3 of our variants. But maybe... I don't know. It wasn't there. So okay, one thing that an attacker could have is just access the Cypher text. Right? What else could maybe they get access to? Yeah, so they could get access to Cypher text and plain text. Right? So they could get what's called a known plain text. So you have Cypher text, and you know what the plain text of that is. Right? You don't know in this case what. The key. You don't know the key. Right? The third one's a little bit different. That doesn't really apply in this case. But let's say that Caesar had a encryption as a service mechanism or something. And so he had somebody that you could put in messages in one end and you would get encrypted messages out of the other end. Right? So he had a team of people just doing encryption all day. Because he didn't want to do it himself, right? So he had a tent that does this. And so if you're able to then write your own messages, put it into the tent and have a Cypher text come out. That would be... You'd have more capabilities than either one of these. Does that... Do you agree with that? Right? Because in the second case, you don't choose so... You may just have access to only the Cypher text. You may have access to Cypher text and plain text. And you may... So, you know, think about war concepts, right? So maybe you can steal a message for Cypher text only. You can steal many messages. Known plain text, maybe you have been able to convince the messenger to tell you what the plain text of that document is. Or in other types of war scenarios, you have spies that on the inside that are able to steal the plain text of the message. So now you didn't choose the contents of that plain text, but you know exactly what the Cypher text is. And then, so let's say we have this magical hut that would encrypt plain text with Caesar's key. What plain text would you encrypt to get the key? The whole alphabet, A through Z. Can you do it easier? A? Yeah, so just have a message A. You pop it in, what comes out? Yeah, one offset of the key, right? If it's D, then that means the key is 4. Right, but so this way... So if you just put... So if you had something that would give you Cypher text for plain text that you're choosing, you put in A and it will give you the key back. Right, in the Caesar Cypher example. Yeah. If you give it an idle service, Caesar's hut, great. You just encrypt all the vowels. You encrypt all the vowels and there you go, good. You can just give them the Cypher text and eventually you can just keep giving it to them until it shifts enough that the key pops out. So the key is constant here. So Caesar has decreed that the key now is 21 in this hut. So that's actually a good point. Every plain text that you come in, right, the Cypher text will be exactly the same. If it's the same plain text. And if you give it Cypher text... And after so many iterations... Ah, okay, it will shift it. I don't know how the number of lines works in that way. I don't know, maybe that will be true. It's a similar version of brute forcing it. Maybe you'll get there faster. I'm not really just certain. Cool, okay. So we've talked about a lot of these things. So we've talked about different ways we can attack this system. Right? So one of the kind of... And thinking, I like to think of it kind of like at the base and going up. So not necessarily so much in these examples because the math that we're doing here is just like shifting numbers, right, on the Caesar Cypher. But we could, if we're smart and clever enough, find underlying problems in the mathematics of the crypto system. Right? So I'd say it probably doesn't necessarily exist in the Caesar Cypher, but in other ones we should think about this. And we'll see examples where people, very clever, very smart people, have found ways to break crypto systems based on this. We can also look at statistics. And some people mention this a little bit. So they talked about analyzing words in the Cypher text. So if we just have the Cypher text. So what are we looking for there? Common words? Why common words? We're going to assign them at the end of every message and we know what it will occur to. Yeah, okay. So there I'd say we have actually known plaintext attacks. So we know that the message ends with like dash Caesar or something. Well not that, but Caesar. And so we could use that. Not necessarily a statistical type, but kind of somewhere, yeah. Yeah, so English, right? So if you know the language that this is written in, is every letter the same? Use the same? No. Why not? I don't know why not. But it's not, right? You know this is like plain Scrabble or any game like this. Or just thinking about sentences that I've used and letters, how many Z's have I used? Very little until that one. Right? So the frequency distribution. So you can make statistical attacks based on assumptions of the underlying language. And we'll see exactly how to do this in the Caesar Cypher and other Cypher's. Right? So we can look at the Cypher text and say well in English, E is the most common, but I can't remember exactly. We can say E is the most common. We can look at the frequency of every character in the Cypher text and we say Q is the most common. Now what is that game we should probably try as the key? Yeah, whatever shifts E to Q. I don't know what that number is, right? But we can try that. And then that may be our key. But let's say we have a perfect crypto system. So the map is great. It hides all of the traces of the language in the output. Is our system secure? I'll commit to an answer. Yeah. So one thing would be, and this is the thing we'll look at, right? So it's kind of a mathematical type of attack. But yeah, we could try every key, right? Then like 26 keys, so that takes that long. We need 26 barbarians, well we don't like that. Right? But if it's in the billions or trillions or I don't even know larger numbers, right? Try every key with the infeasible and we'll never try all the keys. So what else? What other things do we attack? Yeah. Yeah, yes. Kind of. I mean, it's tricky. I don't know. It's a difficult question. Can you ever take out the human element? Well in some sense the human element is there, right? Because this crypto system needed to be implemented in something. Right? And so maybe we can attack the crypto system. There's a fascinating paper where they were able to leak the encryption keys from a remote system based on a timing attack because depending what input you gave, the crypto system would take slightly different amounts of time on your input which depended on the key itself. So you can leak out the key from a crypto system actually completely remotely, like over the net only. So this is one of those things. So crypto systems have to have constant time operations which makes them very difficult in a pain to actually develop because you want the time, multiply, add, all these types of things to not depend on key information. It is very easy to mess these things up and the literature is littered with these failures. Cool, so okay. So we're first going to look at what we call like classical cryptography. So these are things that people used to do by hand because, well, because you can do that by hand because they're fairly easy to understand. The key idea is that the sender and receiver must share the same common key, right? This is something that we talked about. It has to be the case that they share the key. This is also called symmetric cryptography. So what's the symmetry here? Key. Wow. Wow, that's true. Maybe the algorithms are symmetric? Yeah, that's a good one. I don't have to say that you both sides need the key, right? So they must be having the same key. We're going to look at two basic types of algorithms, substitution ciphers, which just like the seizure cipher, you substitute A for one letter for another letter in your crypto system. Other ways are transposition ciphers where you just mess up the order of things. And you combine these using, that doesn't make sense. These product ciphers have products of these two. And all symmetric cryptosystems including DES, AES are all based on these two principles. So that's why we're going to study these from the bottom up.