Okay, so let's get started with today's lecture. So today we're going to be talking about security and cryptography. And today's lecture is going to be a little bit different than our treatment of this topic in last year's class. So last year we focused a little bit more on security and privacy and from the perspective of a user of a computer. But today we're going to focus a little bit more on security and cryptography concepts that are relevant in understanding some of the tools that we talked about earlier in this class. So for example, we talked about hash functions or cryptographic hash functions like SHA-1 in the Git lecture. Or we talked about public keys when we talked about SSH in the command line environment lecture. And so today we'll talk about those different cryptographic primitives in more detail and get an understanding of how they work and how they're used in these different tools that we're teaching in this class. This lecture is not a substitute for a more rigorous class in security. So there are a bunch of really good classes at MIT like 6858, which is on computer system security, or 6857 and 6875, which are more focused on cryptography. So don't do security work without formal training in security from these classes or elsewhere. And unless you're an expert, don't roll your own crypto, don't build your own crypto implementations or protocols. And the same principle applies to computer system security. This lecture is not about building your own stuff. It's about understanding what's already out there. And so this lecture will have a very informal but we think practical treatment of these basic cryptography concepts. And yeah, hopefully it'll help you understand some of the tools we talked about earlier in this class. Any questions about the plan for today's lecture? Great. So the first topic for today is something called entropy. Entropy is a measure of randomness. And this is useful, for example, when trying to determine the strength of a password. So let's take a look at this comic from XKCD, we're a big fan of XKCD comics. So this comic, raise your hand if you've seen this before, no good number of you. So this comic is complaining about this common pattern that's been taught to users of computers that when you design passwords, they should be things like that TR0, UB4, DOR, Ampersand 3 string in the top left. We should design passwords that are full of funny characters and things like that to make it hard for attackers to guess. And yet, turns out that passwords like that are actually pretty weak and guessable by computers that can guess passwords really fast and brute force attacks. And on the other hand, passwords which maybe intuitively don't look as secure, like the one on the bottom left, correct horse battery staple, that one turns out to be way more secure. So how do you actually quantify the security of these different passwords? It's by measuring the amount of randomness in the password, how many bits of randomness are in there. And so entropy is measured in bits, this is like the same bits from information theory. And we're only going to talk about the simple case where you're trying to measure the amount of randomness when you're choosing from a set of things uniformly at random. So for example, when you're constructing a password that's in the format of four random words, you're kind of considering all possible sequences of four random words maybe from some dictionary you have, you might have a dictionary that would say 100,000 words and you're selecting each word uniformly at random. How many possibilities are there? Well, you can go and figure that out in that example. Once you know how many possibilities there are, the measure of entropy is log base two of the number of possibilities. And as that comic suggests, this is related to how long it'll take an attacker to try to brute force through your different passwords. Like if you have a thousand possibilities and you're guessing passwords at a thousand password a second, that's not a very good password. So just a couple of quick examples. A coin flip has two possibilities and let's assume we have a fair coin. And so a coin flip has log base two of two is one bit of entropy. And another thing we might look at is something like a dice roll. So there's six possibilities and log base two of six is something like 2.6 bits of entropy. So that's how we quantify the amount of randomness in something. So now going back to that example in the XKCD comic, when we want to figure out how much entropy is in a password, we have to consider the model for how the password was generated. For example, in the top left, you could consider, okay, we take one dictionary word, make some substitutions of some of the characters with numbers that look similar to that character, add one punctuation mark at the end, and add one numeral after that. And we can take that model and then use combinatorics to figure out how many possibilities there are, and from that we can derive how many bits of entropy are in that password. So in that particular example, I don't know exactly what model they were using for the password, but they calculated that there are 28 bits of entropy. Whereas in the bottom left example, that correct horse battery staple, they assume that you're working from a dictionary of about 2,000 words. And so when you combine four of those words together, you get about 44 bits of entropy from that. So it's much more secure than the example before it. So any questions about this definition of entropy or why it's useful? And so when you're generating your own passwords, keep this in mind. You want a high entropy password, and the exact number you need depends on exactly what you're trying to protect against. Like in general, a concept in security is you have to keep in mind what your threat model is, like what attackers you're concerned about, what kinds of techniques the attackers might be using. So for example, this comic refers to an attacker that can guess 1,000 passwords a second. This might be something that's possible for, say, a web service that allows people to try to log in with your email and the random passwords that the attacker is trying. But this 1,000 passwords a second model might not be accurate for other scenarios. For example, an offline password cracking scenario, or maybe the attacker has broken into a website and downloaded their database, and they have some obfuscated form of your password, and they're trying to figure out what the password is. Maybe they can paralyze this attack and make it go to a million guesses a second. And so exactly how much entropy you need depends on exactly what you're trying to protect against. But roughly 40 bits of entropy might be good enough for a password which is protected by a website, and you're concerned about online password guesses. And then maybe something like 80 bits of entropy might be good if you're concerned about offline attacks and you want to be really, really secure. So they're rough guidelines you can use. And then how do you actually generate strong passwords? Well, you have some model for password, for example, the four dictionary words thing. And you can actually get a dictionary, and then you can use methods like diceware. So this is something we linked to in the lecture notes, where you can actually get physical die and roll them and then map dice rolls to dictionary words in order to eventually turn that into a password. And doing something like this using some kind of physical token that you know is random like a balanced die, or a coin that you know is balanced, is a good thing to do because humans are actually not good at choosing random numbers, right? If I just asked you to name a random number for 1 to 100, chances are that you're probably not doing so uniformly at random very well. And so that's why it's actually good to use these physical tokens in order to produce randomness. So entropy, that's our first concept we're covering. Any questions about that? Or about this comic? Great, so getting into slightly more interesting and complicated topics, the next thing we're going to talk about is hash functions. So hopefully most of you were here during the Git lecture where we talked about the SHA-1 hash function used in Git. So now going into that topic in a little bit more detail. Hash functions at a high level are functions that map a variable amount of data into a fixed size output. So for example, the SHA-1 hash functions is one example of a hash function, takes in some input of some number of bytes and outputs exactly 160 bits of output. So that's kind of the type signature of this particular hash function. And then these functions have some number of properties that are useful. So at a high level, these can be thought about as hard to invert functions that have random looking outputs. We can actually try this out on some random piece of data. For example, if I enter into my terminal printf hello, this does exactly what you would expect it does. Print this out to standard out. And I can pipe this to the SHA-1 sum command. So this is a command line program that accepts input via standard in and computes this SHA-1 function which takes in some variable number of bytes from the input and produces a 160 bit output. Which in this particular case is represented and coded as a hexadecimal string. So it's a length 40 hexadecimal string and you see this output right here. This dash just means it took it took its input from standard in. So this output just looks like some random number. But one important thing is that this is a deterministic number. If you try the same command on your own computer, printf hello SHA-1 sum, you will get the same number out. So SHA-1 is some well-known function that people have agreed upon for all its parameters. We'll see that if we tweak the input a little bit, like say change hello to hello with a capital H. Now we get a completely different looking output. And this also looks like some other kind of randomish number even though it is deterministic. And you could reproduce this on your own computer. Hash functions have a number of properties that are pretty important. The first property that cryptographic hash functions have is that they're non-invertible. And what that means is that if you take the output from this function, for example, that AAF for blah, blah, blah, three, four D string shown there. From that output, it's hard to figure out what the input was that produced that output. So you can go one way, compute the SHA-1 hash easily. But you can't go backwards. Another property that these functions have is that they're collision resistant. And what this property means is that it's hard to find two different inputs that produce the same output. And so this basically describes what a cryptographic hash function is. So any questions about the kind of specification of a cryptographic hash function? Okay, so what are these hash functions actually useful for? Well, we've already seen one application in Git for content address storage. So we want some uniform way of naming different objects that are in the object store, and it turns out that Git addresses all of them by their SHA-1 hash.  And all of that is stored in the object store in that particular way. We see this when looking at many different parts of Git. For example, right here, I'm going to Git repository. If I do Git log, it shows me the commits. And for example, this number up here is the cryptographic hash function SHA-1 applied to the commit object that describes this particular commit. So does anybody know why Git uses a cryptographic hash function here?  And they have similar properties that they turn a variable sized input into some fixed size output. But they don't quite have these properties where it's hard to find an input that produces a particular output or things like that. It's a kind of weaker definition than this. So why is it that in Git we care about having a cryptographic hash function as opposed to just a regular old hash function? Does anybody have any ideas? Yeah, that's basically it. That we don't want to have kind of conflicts in the output from this hash function. Like every commit is identified by a hash function. Every file is identified by the hash of that file. If it were ever the case that two different pieces of content in practice produce the same output, that is, if the function were not collision resistant, that could be really problematic, right? Because then you and I, we could have two Git repos that we think are the same. We check out the same commit hash and we might end up with different files. And this is concerning because Git is used to track software, attract development of software. And it's also kind of involved in making sure that the right people are authoring the software and nothing funny has happened in the process. For example, there are all these open source projects like the Linux kernel where development is done using Git. It'd be really bad if some contributor to Git could say, edit some file and propose some change that looks pretty benign. Like, oh, let me go and improve this part of Linux, submit that change request to the Linux developers, and then in practice actually supply a Git repository that has the same commit hash and whatnot, but actually the file contents are different and there's something malicious. So Git actually relies on the SHA-1 function being a cryptographic hash function in order to achieve security. Any questions about that? And then some other interesting applications of hash functions. So as we saw, hash functions turn big inputs into small outputs. And in a way, because the hash function is collision resistant, the output can be used to kind of attest to or identify the input. And so you can think of a hash as a short summary of a file. For example, in this directory I have a bunch of files and I can compute the SHA-1 sum of some file in this directory. And this is the SHA-1 algorithm applied to this readme.md file. And what's interesting is that it is computationally hard or impossible. You can kind of think of it as impossible to find any other file, so a different file that has the same hash output. And one scenario in which this is useful is when you download files from the internet. For example, there are lots of Linux distributions that distribute large CD or DVD images from their website. Like I can go to Debian.org and download the latest version of Debian. The thing is that hosting those files can be expensive and so a lot of people are nice enough to host mirrors of these files. So instead of downloading Debian from Debian.org, I can go to one of many other sites and download what are supposed to be the same files that are hosted at Debian.org. But how do I know that I actually got the correct file?  Well, one thing you could do is download a copy from the original Debian website and then download my version and compare them. But that kind of defeats the purpose, right? Because we want to avoid downloading things from Debian.org because hosting these files is expensive and we want all these different people to be able to mirror copies of the files elsewhere. So does anybody see how cryptographic hash functions could be useful to solve this problem? That I want to download a file from an untrusted source but not from like the trusted source itself. But maybe I can get some small piece of information from this trusted source in order to know whether the file I downloaded from the untrusted source is the thing I was supposed to get. Cryptographic hash functions? Yes, like it's basically just a straightforward application of cryptographic hash functions. So what Debian.org can do is they can produce their kind of correct ISO file or whatever they want and instead of publishing the file itself on their website they can publish a hash of that file. So compared to the file itself which may be many gigabytes this is only like in this particular case 160 bits of data, right? So very cheap to host. And then what I can do as a user is I can download that file from any random website. It could be an untrusted website and after I download it I just double check the shall one hash. And if the hash matches then I know that I have the right file because it's computationally infeasible for somebody to give me some different file that happens to have the same hash because hash functions are collision resistant. So any questions about that application? Yeah? Yeah, so that's a good question. Like why do you need different people to host the information? Like wouldn't it be equally expensive for everybody? So the answer to that question is a little bit complicated but like here's a partial answer. One thing is that downloading files from a server is affected by how far away the server is from you. So for example, if the server is in Massachusetts and you're in say China like you have to kind of make a big round trip across the internet and that may be expensive for a number of reasons like the latency is high and the traffic needs to go through kind of lots of different wires to make its way all the way to where you are. And so one thing that these websites do is that they distribute their content to servers that are all over the world and then as a user you download from the server that's closest to you. Like for example, MIT maintains a Debian package repository and like kind of mirrors all the Debian stuff. So if you're a Debian user at MIT you can use the MIT copy of everything and then you can kind of access it over our fast local network and that traffic never needs to go to the outside internet at all. So it's very fast. That's a good question. Any other questions? Okay, and then one final kind of interesting application of hash functions is something called a commitment scheme. So I want to play a game and I need a volunteer for this. So you don't actually need to get up from your seat or anything. I always need you to talk with me. So any volunteers, raise your hand. Yeah, okay, what's your name? Abdul Aziz. Abdul Aziz, okay, great. So Abdul Aziz, we're going to play a game. We're going to play a game where I'm going to flip a coin and then you're going to call heads or tails and if you call it right you win and if you call it wrong you lose and there are no stakes for this game but just the pride of winning. So sadly, I checked my wallet and all I have is dollar bills. I don't have any coins with me. So instead I'm going to just flip the coin in my head. All right, so okay, I flip the coin, call heads or tails. Sorry, you lost, it was heads. Do you want to play again? Yeah, I can cheat, right? I can just see what you say and say the opposite thing. So let's try fixing this game. How about you call heads or tails after I say what the coin flip result was? Okay? That's also right. Yeah, so if I say, oh, the result is tails, what are you going to say? No, it's head. Wait. Or you call tails. Yeah. So is it possible to play this, guess what the coin flip result is, game in a fair way without having a physical coin that we share? Like, because I can't really manipulate your physical reality.  So it turns out that hash functions give us a kind of cool way to solve this problem too through an idea called a commitment scheme. So I can say, like here's the construction of the solution. I can pick heads or tails and I'm actually going to pick a big random number, say like this number here. And what I can do is compute the sha1 sum of this number. At this moment, you haven't seen this number yet. I'm just doing all this in my head. And then what I do is I tell you, okay, I flipped a coin and I'm not going to tell you what the result is just yet because you haven't called heads or tails. But I'll tell you what the sha1 sum of the result is. Here you go. And I tell you this value. Now after this, you can call heads or tails. So what do you say? Like, say heads. Afterwards, what I can do is I can reveal to you what my input to this function was. And then you can cross check this, right? You can compute the sha1 sum on the input to verify that the output is what I said it was earlier. And then we can have some way of mapping these numbers to heads or tails. So I might have agreed upon beforehand that even numbers are heads and odd numbers are tails. And so this is a way of fixing that game. So we can actually play this game in our heads, right? I can pick a value, but not reveal that value to you, but I can commit to the value. So this is a kind of binding commitment scheme that I can't change my mind after I've told you this, but it doesn't reveal the original value to you. And so this is one other neat application of cryptographic hash functions. Any questions about this particular construction? Okay, great. So moving on to the next topic, we're going to talk about key derivation functions, often abbreviated as KDFs. So this is a concept that's very similar to hash functions, except it has kind of one extra property that it is slow to compute. For example, there's a hash function, a key derivation function, known as PbKdf2, PbKdf2, password-based key derivation function too. That has a kind of similar form as these hash functions we were talking about here, that they take in some variable length input and produce a fixed length output, but they're meant to be used for one particular purpose. The purpose is generally to use the fixed length output as a key in another cryptographic algorithm. And we'll talk about those algorithms, like what you use the output of this thing for in a moment. One property of these things is that they're slow. Does anybody have any idea why you'd want an algorithm to be slow? Like normally we want algorithms to be fast, right? So why would we want an algorithm to be slow? Yes? Because if someone has a database full of hatches that and they're trying to brute force it, like then they'll have a hard time, whereas if someone types in the right password, you only need to be right once. Yeah, that's exactly it. So I'll repeat so it goes into the microphone. The reason you want these to be slow is when you're actually using it for something like password authentication, where you have the hash of a password saved and then somebody inputs the password you wanna know if that corresponds to the hash, it's okay if it's slow, because you're only doing this check kind of once. But the other scenario in which you're gonna be using this function is when somebody's trying to brute force a password. Say a website has their password database stolen and somebody's going through all the accounts and trying to break all the passwords.  And so it's fine if this takes you like one second upon logging in to compute this function, but when you're brute forcing it, we don't go at 1,000 guesses a second like in that XKCD comic, we can slow it down a little bit. So what is the output of key derivation functions actually used for? The next topic we're gonna talk about, probably like one of the most classic things when you think about cryptography is encryption and decryption. The next topic is symmetric key cryptography. And like the rest of this lecture, we're not gonna talk about how you implement these, we're going to talk about the API for symmetric key crypto, like how it's used. So symmetric key crypto systems have a couple different functions. They have a key generation function, which is a randomized function that produces a thing we call the key. And then they have a pair of functions, encrypt and decrypt. And encrypt takes as input something we refer to as the plain text. And this is just some sequence of bytes, some data. And it takes in a key. So something that came as an output of this key generation function and produces what we call the ciphertext. And then decrypt does the opposite of this. So it takes the ciphertext along with the key and produces the plain text. And this triple of functions has a couple properties. One is that, like one thing you might expect is that this thing doesn't really tell you all that much about this input to the encrypt function. So property number one is given the ciphertext, you can't figure out the plain text without the key. And the other property is kind of the obvious correctness property that if you take something and you encrypt it, some message M with a key K, and then you decrypt that ciphertext using the same key, that gives you back the same message. This is the kind of obvious correctness property. So does this description make sense? Does it fit your kind of intuitive understanding of taking some piece of data and obscuring it so you can't really tell anything about the original input, but then taking that obscured result and then passing it through some decryption function given that key to retrieve the original input. And this isn't really a rigorous definition of what it means for something to be secure, but it's a good enough intuitive definition that we can work with it. So any questions about that description there? So where can symmetric key cryptography be useful? We'll talk about a whole bunch of examples later in this lecture, but one example we'll talk about right now is encrypting files for storage in an untrusted cloud service. So consider, say, something like Dropbox or Google Drive or things like that. When you upload files there, you're trusting the service to not look at your files or do anything malicious with them. These services, at least the ones I named, are not intent encrypted or anything like that. In theory, any employee at those companies could look at your files. Now, of course, these companies have lots of policies and technical controls in place for making sure that that sort of thing doesn't happen, but that doesn't mean that it's not technically possible. And so one thing you might wanna do, if you don't want to trust these cloud services to not peek at your data, not do machine learning over them or do other sorts of things that you wouldn't really want, is you can just take your files and encrypt them before uploading them to these web services. So does that idea make sense that I can take my file like some of my pictures or whatever, pass it through an encryption function and produce a ciphertext and then place that ciphertext on the web service, say for backup purposes or whatever? And if I ever need that, I can retrieve the ciphertext, then use my key to decrypt it back into the plaintext and they can use the result for doing whatever I need to do. Does that make sense? Yeah? Yeah, so that's a good question. The question is, couldn't anybody else run it through the same encryption program? One detail maybe I should have explained in a little bit more detail is this key generation function is randomized and this key has high entropy. As I was going back to that topic we talked about earlier. So like an example is we might have AES 256. This is one particular symmetric cipher and this as the name might indicate has 256 bits of entropy in the key. And so that means that as long as the attacker like whoever downloads the ciphertext from the web service doesn't know your key unless they have some better attack in place, they'll have to try all the different possible keys. And if they're two to the 256 keys, that's too many keys to try in a reasonable amount of time. Does that answer the question? Great, any other questions? Yeah? Let's say I lost my key. If it randomized, how can I decrypt it again? That's an excellent question that leads into what I was going to talk about next. So thanks for that question. So as you point out, like if I lose my key I'm kind of stuck, right? I need my key to decrypt. That's kind of the point of this thing. Like if I didn't need my key to decrypt then this wouldn't be a very good crypto system. And so I can combine this idea of symmetric key cryptography with the topic we just talked about, key derivation functions. So instead of having some key that's randomly generated with my key generation function, say sampling entropy from somewhere on my machine I can have a passphrase and pass it through my key derivation function box and this gives me my key. And then I can take my plain text and combine it with my key in my encrypt function and this produces my ciphertext. And I store this ciphertext on the web service but now I don't need to save this key. Instead I can just remember my passphrase and whenever I need my key I can reconstruct it from the key derivation function. Question? Is the key derivation function slow passphrases? Because I'm assuming your passphrase is in the key term, it's explained as well. Yeah, so that's a good question. The question is, is the key derivation function slow enough to prevent brute force guessing? And the answer is it depends on how long your passphrase is. So for example, if your passphrase is like the string password is probably gonna get broken very quickly but as long as there's enough entropy in your passphrase this is good enough. So like if I was uploading something to Dropbox and I really wanted it to stay secret I think like a 64-bit passphrase or a passphrase with 64 bits of entropy would be more than enough in that scenario, for example. And just a quick demo of this. So there are tools to make this really easy to do. This is actually one of the exercises but we can take a tool, for example, called OpenSSL and use it to apply a symmetric cipher to some file. So I have my readme.text here, for example. Readme.md, it has a bunch of stuff in it. And I can do openSSL, AES 256 CBC. This is the name of a particular symmetric cipher. And I can say that I want to apply this to readme.md and produce readme.md, let's give it some name. And it's asking me for a password. So by default this works in this mode where I provide a passphrase, it's run through a KDF to produce a key and that's used for encryption. So I'll type in some password, type it in again and now I produce this readme.md file. And if I look at this, it kind of looks like garbage and that's at a high level the point of a symmetric cipher. It produces some cipher text that should be kind of indistinguishable from random data. And when I want to decrypt this I can run a similar command, openSSL, AES 256 CBC, dash D for decrypt, take the input from readme.md and I'll do like readme.decrypted.md as the output. And I can compare these two files and the correctness property of symmetric cryptography tells me that this should be identical and this indeed is identical. If I look at the return value, compare return zero so that means they're the same file. So any questions about symmetric key cryptography? Yeah. So this particular command did make a new file so it took as input readme.md and produces output this file so that is the encrypted version of the file. It left the original untouched but then of course I could delete it if I wanted to. Yeah. That's a good question. This is something I wasn't gonna talk about in too much detail. The question is I provided the salt argument here and where is that stored? So the answer is that that is stored in this output here. So this output format stores both the salt and the actual output ciphertext so it can be used in the reconstruction and decrypt. So it doesn't keep any database of salt used for input file? Yeah, that's correct. It doesn't keep any database or anything. This is fully self-contained. The salt is done. Yeah, and as John says, the salt is not the secret. Like the passphrase is what is the secret thing here. Okay, so let's go back to, so the question is what is salt? The idea of a cryptographic salt is probably best explained in the context of hash functions. So one common application of hash functions is to store passwords in a password database. If I have a website and I have logins for users like people log in with their username and password, I don't actually want to store people's passwords in plain text just like as is. Does anybody know why I wouldn't want to do that? Yes? Exactly, what if there was a breach and someone got all your data? So it's really bad if you leak all your user's passwords. It's especially bad because a lot of people reuse their passwords across different sites. So you'll see attackers break into one thing like there was this big Yahoo breach a while ago and they find all these user names and password pairs and then they go and try those same login credentials on Google and on Facebook and on YouTube and whatnot because people reuse passwords. So it's bad to store plain text passwords. So one thing you should do is you should store hashed passwords with a hash function or ideally a password hashing function that's intentionally designed to be slow. But one thing attackers started doing once they realized that people started storing hashed passwords is they built these things called rainbow tables. What people did was they took a way of generating big password lists like they kind of model what passwords might look like. Say take all the dictionary words, take all strings of length from zero to eight and whatnot. Take all of those and then hash them and produce a big database mapping hashes back to their pre-image. And so given the output of a hash function rather than have to brute force it on the fly you can just go look up in this database oh what is the input that corresponds to this output? And people have built these for reasonably large password databases. And so one thing that you can do in reaction to that as a defense is rather than storing in your database, let's see where to write it. Rather than storing just the hash of the password what you do is you compute what's called a salt value. And what this is is a large random string. And then what you do is you store in your password database the salt which is not really a secret like you can store this in your password database along with a hash of the password with the salt appended to it. Why is this useful? Well this salt is a random unique value for every user. And so if someone has the password say password 123 on one web service if you were just storing the hash of the password then the hash would be the same on both web services because this hash function is a deterministic function. But now since we're using this randomized salt value we store the hash of the password plus the salt. And so even if someone's using the same password on multiple sites this thing looks different in both cases. And it makes it so these big databases mapping these short passwords or hash outputs to the short passwords that they came from those are no longer useful when you have salted passwords. You kind of need to do the brute force attack for every user once you find their salt value rather than being able to use this big pre-computed database. Does that answer the question of what a salt is? And so that's what that salt argument is related to. So any questions about anything we talked about so far? Great. Okay so I'm gonna go ahead and erase this and then the last topic we'll talk about is one of the most exciting developments in cryptography happened quite a while ago but it's still a really cool concept something called asymmetric key cryptography. And so this is an idea that actually enables a lot of the security and privacy related features of basically anything you use today like when you go and type in like www.google.com asymmetric key cryptography is used as part of what goes on there. So this is going to look pretty similar to what we talked about in symmetric key cryptography except for the twist. There's a key generation function which similarly is randomized but instead of producing a single key it produces a pair of keys, two different things one of which is referred to as a public key and the other is referred to as a private key. And then these can be used for encryption and decryption in a manner kind of similar to symmetric key crypto except these different keys have different uses now. So we have an encryption function which takes in a plain text, I'll just write P here and it takes in the public key and produces the cipher text and then I have a decryption function which takes in my cipher text and the private key and gives me back my plain text. And then similarly to those two properties we had over there, given just the cipher text we can't figure out the plain text unless we have the private key. And then we have the obvious correctness property that if we encrypt something with the public key and then take that cipher text and try decrypting it with the corresponding private key that came from this key generation process that outputs these two different things at once then I get the same result back. So this is very similar to what's above but there's a twist that we have these two different keys that have different functions and it's really neat that this public key can actually be made as the name indicates public. Like I could be using a crypto system that works like this post a public key on the internet for anybody to see but keep my private key secret and then I have this interesting property that anybody on the internet can take any piece of content and encrypt it for me using my public key and send it over the internet to me and then I can decrypt it using my private key. And as long as my private key stays secret it doesn't matter if my public key is available to anybody on the internet. So here's where this asymmetry comes from.  Well we'd need some way of exchanging a key in advance so that you could encrypt some plain text with a key and give me that cipher text over the internet so that I could then decrypt it with that key. In symmetric key crypto if the key's public it's game over like anybody can decrypt your stuff. Whereas in asymmetric key cryptography I could take my public key and like post it on a bulletin board on the internet and you can go look at that take some contents and encrypt them for me and then send them over and that would be totally fine. You can only decrypt it with the private key. And so one analogy that may be helpful is comparing these mathematical ideas to physical locks. So you probably have a lock on your door to your house and you can put in a key and like turn the thing in order to lock the door or you can turn it the other way to unlock the door. So there's a single key and it can both lock and unlock the door. But now consider this alternative construction which you might use if say I want you to be able to send me a message and have it be sent over the internet and I don't really need a way to exchange a key with you beforehand. I could get a box which you could put a letter inside and you can close the box and I can get one of those padlock things which I can give you I could like take this padlock and open it and give it to you and you at your own leisure could put your message inside a box and take this padlock which is open and shut it around the box and then send it over to me and then I could put in my key and unlock it. So do you see how there's this asymmetry there as opposed to the key that I used to open the door to my house where the same key opens and closes the thing? Instead I give you this open padlock that you have the ability to close but not open and after you close it I can use my key which I've kept secret in order to open the thing and retrieve what's inside. Maybe this analogy is helpful, maybe it's not. The mathematical construction works just fine if that works for you. So any questions about asymmetric key and encryption and decryption and how it relates to symmetric key crypto and how it's a little bit different? So before we talk about applications of this idea I'm going to talk about one other set of concepts in asymmetric key cryptography. So these crypto systems give you another set of tools which are related to encryption and decryption something called signing and verifying. And this is kind of similar to the real world like I can get a document and sign it with my signature except real world signatures or I don't think that hard to forge these are pretty hard to forge and therefore more useful. What do signature schemes look like? There's a function sign that takes in some message and the private key. So notice this is the private key not the public key and it produces a signature and then there's another function verify which takes in the message, the signature and the public key this time and it tells me it returns a Boolean whether or not the signature checks out. And then this pair of functions has the property that again these are kind of properties that follow the intuition that come from physical signatures that without the private key it's hard to produce a signature for any message such that you can give the message and the signature and the public key to the verify function to get it to return true. Like at a high level it's hard to forge. It's hard to forge a signature of course without the private key and then there's the obvious correctness property that if you sign a thing with a public key and then try verifying it with the corresponding sorry if you sign a thing with the private key and try to verify it with the corresponding public key it returns okay that this verification checks out. So these are two different kinds of things you can do with asymmetric key crypto systems. An example of an asymmetric key crypto system that you might have heard of is something called RSA. So RSA is designed by a number of people one of whom is Ron Revest who's a professor here. So there are a couple of interesting applications of asymmetric key crypto actually like tons and tons and tons and you can spend like days talking about this but a couple examples are email encryption. So we talked a little bit about sending messages. What we can do with asymmetric key crypto is that you can have public keys posted online. I think some of the instructors have PGP public keys on their websites. So for example you go to my website or John's website you'll find a public key and then what you can do is you can send us an encrypted email and so even if that message goes through Gmail or whatever other mail service through MIT's mail service if there happens to be an attacker snooping on the messages they can't make any sense of their contents because they're all encrypted. And this is really cool because you can do this without kind of finding us in person and exchanging keys which you might have to do in a symmetric key crypto system you can just find our public key which can be posted online without causing any issues and then send us encrypted email. Another thing asymmetric key cryptos use for is private messaging. So raise your hand if you've used anything like Signal or Telegram or I think WhatsApp is in theory end to end encrypted. So good number of you. These private messaging applications also use asymmetric key crypto to establish private communication channels. Basically every person has associated with them a key pair and so your device has run this key generation function produced a public key and a private key and automatically posted your public key to the internet. So for example if you're using Signal your public key is on the Signal servers. And then when someone wants to contact you their phone can look up your public key and once it's retrieved your public key they can encrypt information for you. This is a kind of approximation of how their algorithm works but at a high level that's what's going on. Another neat application of asymmetric key crypto is we were talking about earlier like making sure you have the right software we downloaded from the internet. Asymmetric key crypto can be used to sign software releases. And this is something that people do for example like Debian packages or whatever things you download from the internet. The developer will try to sign their software so that you can make sure that whatever you've downloaded from the internet is actually like the right thing that came from the right person. We talked about in the Git lecture all the interesting things you can do with Git. One thing we didn't cover was signing related functionality in Git. So Git has commits and you can associate with commits something called tags. At a high level you can basically take a Git commit and attach a signature to it which binds your public key to this commit. And then anybody who has your public key can take the commit and your public key and make sure that there's a legitimate signature on the key or sorry on the commit. So let me go to like some random repository that I have.  If I do look at the raw data associated with this tag it has some metadata and then a blob of like ASCII encoded information that I can use the git tag dash v for verify command to make sure that oh, this is a good signature from this person who happens to be me. So I sign the software release so that anybody who downloads it from the internet can make sure that they actually got an authentic copy. Yes, question? So the question is what exactly is the verify function doing or what is it checking against? Like if you wanna know mathematically what's going on talk to me after this lecture but from kind of an API perspective what's going on here is that the signature and also the message here are just a blob of bytes and it happens to be the case that these things are designed such that basically if I take for some particular public key like if you take my public key it's impossible for you without knowledge of my private key for any message to find a second argument to this function that makes it return true. You can kind of compare it to signing a document like you don't know how to forge my signature. I can take any piece of paper and sign it and then anybody who knows what my signature looks like I can show my document to you. You can be like, yeah, that checks out but nobody without the private key can produce a signature that will make this function return true for any particular message. Any related questions started you want me to explain it any other way or does that make sense? So any questions about signing software or any of the other handful of applications talked about of asymmetric key crypto? Cool, so one final thing I wanna talk about for almost out of time is key distribution. So this is a kind of interesting side effect of asymmetric key cryptography. It enables a bunch of interesting functionality like I can post my public key on the internet you can go find it and send me encrypted email but how do you know that the public key you found is actually my public key? Seems like there's a bootstrapping problem here, right? So there are a couple, this is like a really interesting and really hard real world problem and there are a couple different approaches you might take to this problem. One is kind of a lame solution but this thing solves a lot of cryptography problems is exchange the information out of band. What that means is you wanna send me encrypted email well just talk to me after class I'll give you my public key on a piece of paper and since you were talking to me in person like you know that it's actually my public key not just somebody like hacked my website and stuck some random number on there. That solves the problem but it's not the most elegant. There are a couple other approaches that different applications use. So those of you who use Signal have you ever encountered the phrase like safety number like verify your safety number with so and so? So with Signal they have a way of exchanging public keys which is through the signal servers whoever runs the signal service just maintains on their servers basically a mapping from phone numbers to public keys and when I say I want to message this person with this number my phone just goes and retrieves their public key from the internet and then encrypts the message for that public key. Now does anybody see a problem with the setup? Yeah? Yeah exactly the signal servers are a point of failure there because if the signal servers give me the wrong public key like suppose Signal just produces a new key pair and give me their public key now they can read all my messages and they can even sit in between and transparently decrypt the messages I send them and then re-encrypt them and send them onto their final destination. Like basically I need some way of authenticating the public key I get. And so Signal has one solution to this which is also just kind of punting the issue to out of band key exchange. You can meet up with somebody and they have a slightly streamlined flow where they show QR codes on the screen you take one phone and take a picture of the other phone screen and vice versa and now you've exchanged public keys in person and from that point on you've bootstrapped your encrypted end-to-end communication. It also has this issue of or it also has the approach of pinning a public key so once you know that a particular phone number has a particular public key your phone remembers that and if that ever changes it'll complain to you. And then there are a couple other solutions to this problem. PGP one pop to let us be popular a while ago has this idea of web of trust so like I trust people who my friends trust so if like John has done an out of band exchange with say my professor then I can probably email my professor because like I know that John trusts my professor and I trust John so you get this chain of trust through there. That's one interesting approach and then another model that's kind of pretty recently is something that a tool called Keybase uses. This is a really neat, oops. There's a website called keybase.io and they have a really interesting solution to this bootstrapping problem which is social proof. So it's like you probably have your friends on Facebook and on Twitter and whatnot and it's probably pretty hard for an attacker to break into your friends Facebook account at the same time as their Twitter account as the same time as their hacker news account and so on. And so they have this interesting way of binding public keys to a set of social identities such that you can retrieve a public key once you trust some number of social identities corresponding to your friend. And so we have links to these in the lecture notes if you want to see these things in more detail. So that's it for our security and cryptography lecture and tomorrow's lecture will be on a random collection of topics that your instructors find interesting so hopefully see you in lecture tomorrow. I'll also be here for a couple of minutes after class if anybody has questions. Well, can you talk about why asymmetric, how asymmetric key crypto is slow and symmetric key crypto is fast and how you bridge them? Yes. Okay, so John, feel free to leave if you have to leave but I think nobody's using the classroom after us. I'm gonna talk about one other interesting topic. So John brought up the fact that asymmetric key cryptography is slow and symmetric key cryptography is fast. And so in practice, you don't really use just asymmetric key cryptography by itself. It's usually used to bootstrap a more sophisticated protocol that you're using. One thing you might wanna do is use asymmetric key cryptography for sending encrypted email, right? We talked about that example. And the way that works isn't what you might have guessed from our straightforward explanation of asymmetric key crypto. Like you don't just use that encrypt function up there and call it a day. In practice, what you do is you use hybrid encryption to use a combination of symmetric key and asymmetric key cryptography. What you do is, here I'll draw this as a big block diagram. You take your message M and then I have my public key that I want to encrypt for. But rather than just take these two things and pass it through the encrypt function up there, what I do is I use the symmetric key gen function to produce a symmetric key K. I'm gonna like prepend this with symmetric so we can distinguish it from the public key key generation function. And then what I do is I take these two things, pass them through my symmetric encryption box. This produces the cipher text. And now this by itself to the receiver who has the private key corresponding to this public key here. This is not really useful, right? Because this is encrypted with a symmetric cipher with this key K that came from this function that I ran on my local machine. So I need some way of getting this to the person who actually used to decrypt the email. And so what I do is I take this thing. And now this email might have been big and I use symmetric encryption with that because symmetric encryption is fast. But this key is small, like it might be 256 bits or something. So I can take this thing and encrypt it with asymmetric encryption using the public key. And this gives me an encrypted key. And this thing can be decrypted using the private key corresponding to that public key to reconstruct this. So this is on the sender's end. Now the receiver gets this and this and kind of does these things backwards. So you start with the encrypted key and use asymmetric decryption using your private key that corresponds to the posted public key to reconstruct this key that we used for the symmetric encryption box and then use symmetric key decryption using that key that was reconstructed to take this cipher text and produce the original message. So this is a kind of interesting example of how in practice symmetric and asymmetric key cryptography is combined. Question? So the question is will you be using the same symmetric key generators? The cipher. Ah yes, okay. So you need to kind of agree ahead of time which box you're using here. So you might be like oh, I'm gonna use AES 256 GCM here. But this is a well-known function and it's public. Like the attacker's allowed to know all the parameters of this function. This is the only secret thing that the attacker doesn't know, the key. Any other questions? Yeah. That's a really good question. What kind of data is important enough to encrypt? And I think that depends on your threat model. What kind of attackers are you concerned about? What are you trying to protect against? So you might have the stance that you just don't really care and that anything you communicate with anybody is allowed to be public. I might be willing to post all my conversations with everybody publicly on the internet. On the other hand, maybe you're doing some security-sensitive work. So you're working under a contract for the US government developing some sensitive military stuff. If you're sending that through the open internet while you're traveling, you probably want to be pretty darn sure that no eavesdroppers or anybody else along the way can see what you're sending and that whatever you're sending is in fact going to the right place and that whoever is receiving it can authenticate that it in fact came from you. So you might be worried about all different kinds of adversaries depending on your scenario. From random script kitties who are trying to break into websites to nation state level attackers and you'll need different types of techniques for defending against the different categories of attackers. Any other questions? Cool, so hopefully see some of you tomorrow for a random collection of things that John, Jose, and I find interesting.


This is our annual Glinda Woods Girls University. We're serving 60 girls at this location and 40 girls over at the neighborhood place for 100 total girls this summer for the first time ever. And this is our flagship program where we get to combine so many of the exciting curriculums that we use to educate girls in under one roof. So girls have gotten a really thorough and comprehensive experience this summer. With friendly persuasion, they're learning those different peer pressures and how to combat them and how to stand up against their friends whenever they're in a situation where there's drugs or alcohol around. Even if not, if there isn't those substances around them, they can still know how to use those tools in order to stand up for themselves. How to learn, how to be assertive, how to reach for their goals and to stay on a path to attain their goals and to learn perseverance and to never give up to achieve something for themselves but not only for themselves but for all women in general. It's not Justin. No, well, I love the hair. It's not really actually. Yeah, I would think so. Did he put his hair back flat or is that what it looks like when it's like that? Yeah, I think it actually looks like that. Economic literacy is teaching the girls about needs and wants. The society today, you know, it's always about having the latest style of clothing or the latest digital gadgets. Well, sometimes parents can afford that. So girls, it's important for them to learn their needs and the wants. And these wants are usually the material things. I learned how to be a leader and to take care of others and to be right there, to be there to help them as we learn. Just mostly about confidence will make me feel better. Girls are bombarded with messages all over from the TV, music, internet, even the magazines and books they read. So they have these images of how girls and women need to look, how they're supposed to act. And with media literacy, they're able to break down those messages and really see it's okay to be who they are. And bold. We're making a trampoline. We're going to, we're going to cut holes in it like this. And then we're going to cut holes in this bottom. And then we're going to stow it on so that when we drop the egg, it bounces. And then it'll come right back up. That's cool. That's what somebody does on a trampoline. Operation SMART is our STEM-based programming. So the girls are learning science, mathematics, engineering and technology. So the girls are being exposed to different concepts of science. And they may not even really like science in school because it's boring. Well here at Girls Inc. they're learning different aspects of science. They will be learning about inspiring women who have taken the career path of being engineers. I really hope that they'll take how to be strong, smart and bold girls in their schools. I really hope that they take how to resist peer pressure, how to stand up for themselves, how to make smart choices, how to remember to have a voice when they go to school. I really hope that they don't lose any of that that they've learned, that they do have a voice, that knowledge is power, and that they really do put that to practice when they're in the schools.


Welcome to Toffy TV, this is the Everton News Daily. Has the Gabrielle saga ended? Well, reports suggest that Everton have walked away or are preparing to walk away from the deal. It has been suggested that Everton have been trying to restructure a deal after seemingly agreeing a fee with Leel and a deal with the player back before obviously Covid struck. Everton unwilling now to pay the asking price. It seems that Napoli and Arsenal have met the asking price but Everton aren't willing to. They do not value the player the high anymore and are prepared to walk away. It would mean that this whole saga has come to an end, which is probably for the best. If Everton don't think the player is worth it and other clubs do, then he's obviously going to go to those clubs and not to Everton. We don't want this to be a drawn out saga and Everton can move on to their other targets, whether those other targets are centre backs or if it was just the case that Everton just really wanted this player. We'll have to wait and see but it looks like it's going to be over and it's going to be over without Everton being successful in signing the player. We'll wait and see what happens in the next two or three days. It's going to be an interesting month. The players are obviously back in training. They've returned to training yesterday. We've seen some old familiar faces in their Janach, Balasimo, Bessage, Lersall and John Joe Kenny was back as well after his spell in Germany with Schelcher. They were all back in pre-season training and obviously they were the only new additions without Everton bringing anyone in. So back in pre-season and looking forward to the game this Saturday against Blackpool, which is nice with the season not that far away really. Dimazio, the Italian transfer guru, other people have other names for him, has suggested on Skysport that Everton or obviously Alan were aware of, Decore and Roma, right-sided player, Franzae, 29-year-old would maybe alone, obviously he could cover right back, cover the right wing, but he's suggested that Carlo Ancelotti is interested in the three players. Obviously we're obviously aware of Alan's situation. Decore as well, there's been talk about Decore. Obviously this is a player that Everton looked at last summer and we were very tempted although a £50m price tag was not what the Everton board wanted to hear and we never went any further with that. So it's going to be interesting. Obviously fans getting a little bit impatient at the moment. They want to see that, obviously that first player brought in and wanted to be a sentiment fielder and we'll have to wait and see. The Alan situation obviously is very muddied. It might be a little bit less money this week though because there was a suggestion last week that if Everton went in and paid what Napoli wanted for Alan it would give Napoli the money to go and get Gabriel. Now, if we're out of the Gabriel situation, this might make Everton a little bit more willing to meet Napoli's valuation or certainly get a lot closer to it if it means that we're not getting Gabriel anyway. In fact, I see it as a bonus. I think if we buy Alan and it means they buy Gabriel, it means Gabriel's not going to one of our rivals in Arsenal. So I think that's win-win. Whether that happens, we'll have to wait and see. Alan's also been linked with Brusher Dormand and Atheist of Gumbagid over the weekend as well. Whether that's Napoli just putting the feelers out there to sign encourage evidence to come back to the table, we'll have to wait and see. But listening to Brusher Dormand and Atheist of Gumbagid want him, then he must be a good player. We'll have to wait and see. Final bit of news. It looks like Ronald Cooman is going to be taking over at Barcelona as well. He looks like he's going to be getting the top job, which will come to the surprise of a lot of Evertonians. There you go. This has been the Everton News Daily. Let me know your thoughts in the comments and any of the stories I've spoken about today. Give this video a like. Don't forget to subscribe. If you want more great videos, live videos, join us over on Patreon. The link is in the description. See you later.


people are angry about your boundaries it's because they plan on pushing them and just because people push your boundaries test your boundaries ignore your boundaries doesn't mean your boundaries are failing and not working it actually means they're working fine so don't keep adjusting your boundaries because people don't respect them remember boundaries aren't for other people therefore your boundaries are about self-respect not their respect


From most of the examples and the most of the things that we talk about from now on we'll look at we'll use digital data as an example So now if we have analog data, we know a way that we can convert that analog into digital So if I want to send audio across a communications network or a link I can convert that analog audio into digital So many systems today we deal with data in a digital form even if it's original in analog so From now on this topic and the subsequent ones. We're really going to focus at digital data This topic. We're going to just introduce one concept and again skip almost half of it and introduce the concept of error detection and I think most of you probably have have seen error detection in Maybe a computer hardware type course or operating systems. So it'll be quite easy The issue is I've got some data to send across a link from A to B So the data is in a digital form zeros and ones. I send it across the link but unfortunately in practice There's a chance that when I send the sequence of bits what's received doesn't match what was sent We've talked about some examples before where we can have noise from other sources that make the received signal to be a Lower quality and as a result we get errors at the receiver So with digital data if I send a sequence of bits one zero one one Four bits one zero one one. I send it across the link, but there are some errors. There are some problems in the link So what's received is one zero zero one? transmit one zero one one receive one zero zero one What's received is not the same as what is transmitted. There's a bit error One of the bits has arrived in error We need to do something about that. That's not good I send a file or I download a file across the internet if there are bit errors in some of the links Then I will not be able to use the file So the first thing that we want to do is that the receiver needs to know that there is an error You're the receiver you receive a sequence of bits one zero zero one you need to know is this correct or not? so the procedure we'll talk about or introduce is called error detection and Then the next topic we'll look at okay. Once we know that there's an error. How do we fix it? error correction and A couple of other things about digital data So we'll use mainly examples to explain this but we're gonna From now on assume that we can have bit errors When we send a sequence of bits Sometimes some of the bits received may be different from what was sent and Usually it's random. We cannot predict which bits Okay, because it's due to some noise or some some problems in the communication system So we'd like a way to deal with that. We need methods to detect those errors and When possible correct them fix them so that we get the original original data Sometimes the bit errors occur one at a time Okay, I send a thousand bits one of them is in error In other cases in worst cases I send a thousand bits and 100 in a row are in an arena error a burst of errors due to Some significant problem in the system Sometimes we have to deal with them in different ways, but we'll look at the simple ways to deal with errors Let's start with an example let's say you are the receiver Rx is short for receiver and You receive a sequence of bits Seven bits you receive We know the transmitter was going to send us seven bits. We received seven bits Is it correct or not? What's your answer Don't know. Why do you not know? We don't know what was sent. You're the receiver The transmitters on the other endpoint of the link could be on the other side of the world They've sent you data. You don't know what they sent. You only know what you receive So that's the problem we have we receive a sequence of bits. How do we know it's correct or not? Okay, so that's our problem Of course if we knew what was transmitted Then we would know whether it's correct or not, but we don't know what was transmitted The only way to learn what was transmitted is from them sending it to us So a simple way is that the transmitter Or a general way is the transmitter attaches some extra information before they send the data So the transmitter has some data a sequence of bits They attach some extra information There are different ways different algorithms to do it. We'll start with simple ones such that when we receive that data plus their extra information We use some algorithm to try and detect is this correct or not? and the simplest piece of extra information Now I think you may have heard of is a parody check or a parody bit We'll use that as the example. It's not the best but It's easy one to illustrate so Let's try a different example. Let's say we know the transmitter I'm the transmitter. I have a sequence of bits. What do we have? Let's say it's the same as before but not significant Just a random sequence of bits. I want to transmit to you With a parody check we attach with a single bit parody check we attach one other bit Which will be used at the receiver to detect an error and there are different ways to do it But let's use what's called an odd parody check We attach one more bit in an odd parody. We attach a bit such that the total number of ones should be odd So what do we attach to this sequence of seven bits? There are currently four ones in this sequence if we want an odd parody check We must attach another one such that the There are an odd number of ones so there are five ones so the parody bit in this case will be bit one So in our sequence of eight bits. We now have an odd number of ones So the transmitter will attach a bit such that there's always an odd number of ones transmitted. I Attached at the at the start Another scheme could attach it at the end. It makes no difference. There's still an odd number of ones So now instead of sending seven bits across the link we send these eight bits and now let's look at what's received Forget about what was transmitted now. You're the receiver. You don't know what was transmitted. You just know what you receive Let's say you receive this sequence of bits You just receive those eight bits and you know that the transmitter used an odd parody check So you know that the first bit is the parody bit the next seven bits of the data Correct or not Why is it correct? Because the number of ones is odd You know that the transmitter always sends an odd number of ones in their eight bits So if you receive an odd number of ones you assume That this is correct and that's the parody check and and how it's used for error detection in this case There are five ones so The receiver assumes I'll write it here We make an assumption that is of the bits received If the number of ones is odd we assume it's correct and if the number of ones is Even Will assume it's incorrect. So in this case we have an odd number of ones. So let's assume. It's okay Was it okay? Now you're the receiver. That's all you know, but we know That I know what was transmitted as well and it was this data Is it correct? Yes, the the data received is identical to the data transmitted. So this assumption was This assumption was a correct assumption So if we know both the transmitted and received data we can determine did the receiver make the right choice So in this case it worked Let's try some other cases Let's say instead you received a different sequence of bits. You're the receiver you receive those eight bits What do you do? What decision do you make you make a check and how do you check count the number of ones how many and What's the answer now? Assume it's incorrect Assume there's an error there are four ones and even number of ones. So let's assume that's The data I received this an error Where is the error? If you're the receiver, where is the error? You don't know Okay, you're the receiver. So figure it forget about what was transmitted remove that from your memory and just think You've got these eight bits The only way to check is to use the parody Parody check count the number of ones For ones we expected five Sorry, we expected an odd number of ones. So this must be wrong. It must be an odd number of ones received We don't know where the error is The receiver doesn't know where the error is we know because we've seen that the answer before Was it a correct decision? Now let's look from the perspective of Someone who knows both the transmitted and received data. Was it a correct decision to assume that the data was incorrect? yes, because we know that okay the seven bits and Transmitted 011 here. We have 010. There's in fact an error here if we check. So this was a correct decision To decide that this data is wrong was a correct decision So it worked in that case the error detection worked we detected the error a Couple of more quick cases What do we assume? again wrong We've got an even number of ones We expect an odd number So assume there's an error was there an error Well, there is an error The error is in the parody bit Okay, not in the data But in fact there still is an error in this case we transmitted Eight bits even though one was a parody bit. We still transmitted it 101 we received zero zero one. So there is an error in the transmission system So we have detected an error Even though the error wasn't in the data we still a correct in this case because We've detected an error of what was transmitted Remember we can't distinguish where the error is We can just detect or not. So in fact, this is a correct thing to do as well Even though it was the parody bit that was wrong What do we decide? It's correct. There's an odd number of ones. We expect an odd number of ones. It's correct. Good What's the problem? It's not correct. If we compare what was transmitted. We see that there are two bits in error here They're different from what was transmitted here. So this was the wrong decision So our error detection did not work in this case and that's the case with Every error detection scheme Sometimes it doesn't work. It's not perfect We want an error detection scheme that increases the chance that it would detect errors But in this case When we had two bits in error We assume the data we receive was correct But that's wrong because it's incorrect So this highlights that our Single bit parody check is not very good in some cases. It worked for these cases. It didn't work for this case When does it not work in general the parody check? When will a single bit parody check fail? Can anyone see the difference between the errors that cause it to fail in this case? Here we have two bit errors So we transmit an odd number of ones if we have two bit errors that it means two bits change So we still end up with an odd number of ones so an odd sorry an Even number of bit errors two four six or eight in this case will produce our error detection scheme to fail An odd number of bit errors with a single bit parody check will be okay in these cases So a single bit error it works Any bit changes will detect it because it goes from odd transmitted to even transmitted when you change just one bit But two bit errors or four bit errors and it won't work So parody check is very simple but not very good if you have more than one bit error Because you'll start to have it fail. It won't detect the errors So if you expect many errors in your data Then it may be a parody check is not so good. So all error detection schemes They may not detect every error But we want them to detect as many as possible and people do analysis to see and compare them There are other algorithms and we will not cover other algorithms But another one you may see there's one slide on it But another one you may have heard of is the CRC check that won't know the CRC the cyclic redundancy check CRC 16 CRC CRC 32 another variance Just more complex algorithms, but again a CRC check attaches extra bits Not just one bit. It takes the data attaches extra bits such that when we receive we do some calculation and and the result of the calculation tells us whether we assume there's an error or not and In general The more bits we attach For this extra information Here we attach one, but we can attach more if we use different algorithms the more bits we attach The greater the chance that will detect that will get a correct decision So if we attach more bits, there's a more chance that will make the correct decision Less chance that we'll get this case where an error will go undetected So that's better more bits means more chance of successful error detection But what's the problem of attaching more bits? The problem is that our efficiency goes down in our single bit parody check What do we do we we had original data of seven bits and We had the extra error detecting information The parody bit Sometimes called an error detecting code in general the extra information we added was one bit That was our our example So we can say the efficiency of this scheme For every seven bits of data, we need to send eight bits So the efficiency is seven over eight So I've got seven bits of real data to send But I need to send an eighth bit to get that to the other side because that's what's needed for the parody check Which is what? 87.5% saying that 87.5% of the time if I'm using this single bit parody check and just sending data Seven bits of data one bit parody seven bits data one bit parody. I keep doing that Then it says that eighty seven point five percent of the time I'm sending real data The other twelve point five percent of the time. I'm sending that extra parody bit. So it's eighty seven point five percent efficient What if we had a different algorithm where we attached? two bits that is if we sent data of Seven bits and every time we sent seven bits of data. We added the the extra info of two bits Then the efficiency is seven over nine Seven bits of real data for every nine bits that we need to transmit. Which is what? 77 percent About so the more bits we attach the lower the efficiency for the same amount of data That's bad Because I've got my link and I'm using it for sending real data less percent of the time But the trade-off is the more bits we attach The more chance we'll be able to make the correct decision The less errors will miss By using a single bit parody check We saw that we'll miss errors if there's two bits or four bits in error by using a two-bit parody check we can in We could change the algorithm to decrease the chance that will miss those errors So attach many bits to make the error detection better But attach few bits to make the efficiency better So we need to choose an appropriate trade-off and that applies to all algorithms no matter how complex they are the more information we add The lower the efficiency, but the better error detection capabilities Any questions on parody checks error detecting? We're not going to go through any other algorithms. It was just using a parody check as a simple example, but there are other better ones There are other algorithms Okay question if we just go back to our examples What do I mean by assume the blue one and correct the red one remember the receiver receives data they make a decision Do I assume the data is correct or not? That's what I marked in the blue line the blue column here. That is we were assume this data is correct That's a tick in this second case. We assume the data is incorrect The red column I'm saying was that decision correct or not? In the first three cases, yes, it was correct because if we compare the received data those eight bits To the original transmitted data. There's a difference Sorry for these two there's a difference So it was a correct decision for the first one. There was no difference. So it's still a correct decision in the last case The receiver assumed the data was correct, but that's the incorrect decision They they the algorithm was wrong in that case we don't want those cases to occur and to in general to Reduce the chance of those cases we attach more bits. We have an algorithm that uses more information Instead of one bit add add more bits and you'll reduce the chance of getting this case But you'll reduce the efficiency at the same time any other questions error detection on its own is not very useful So in Say in the second case here the receiver detects an error. It assumes that there's an error. It was correct What does a receiver do? What do we do when we detect an error? When you you're you're doing your exam you're answering questions Then you've got an answer and then you go back and check it and you find it's in error What do you do? You check again, and you try and fix it. Okay, you try and correct the error Of course if there's an error we want to fix it and get the right data. Well, what's the receiver do then? How can they fix this? They've received eight bits. They think there's an error. They know there's an error. They don't know where They would want to they want to receive the original data. They want to fix it So the next step is error correction error detection is detecting it error correction is fixing it and There are two basic approaches for error correction one of them is to attach similar to error detection attach more information such that The algorithms can tell us where the error is Our parody check couldn't do that. It told us there was an error, but not where If we had an algorithm that told us ah, there's an error and the error is the fourth bit Then it's easy to correct change the fourth bit from zero to one and we've got the original data so there's Algorithms that will also be able to tell us where the error is so how to fix the error That's called forward error correction. I'll go back to the slides in a moment. What's the other way to correct errors? I receive data. I detect there's an error. What could I do? send the message again and Hope it will be correct. Good. So I Receive data error. I tell the receipt the transmitter The data you just sent me was wrong Please send it again They send it again and hopefully this time what I receive is correct okay, and Well, why would it be correct the second time if it was wrong the first time? Well, what causes errors usually errors are due to noise Random variations in some cases. So usually usually when errors are not so often I don't know there's one error every one million bits So if we send a thousand bits and we're unlucky and get an error the next one thousand bits We should be lucky and not get an error. So usually sending again can be quite Quite good because the second time we send There won't be an error. It depends upon how often errors occur And if they send again and I detect an error in the second time, I can just ask them, please send again Please send again. Try again. Try again Well at some stage I may give up and say Data transfer failed Because after so many attempts that I didn't receive the correct data so two ways To correct errors attach extra information so that the receiver can find where the error is and fix it That's called forward error correction The second way is when you detect an error tell the transmitter to send again We're going to cover the second way not the first way the second one is more common in the systems We will see so let's just look at the slides and see if there's anything with we need to know more If you understand what we've gone through that simple example of parody check and the goal and the general concepts of error detection Then that's all you need for this topic These slides try and explain it in general saying okay, we send k bits of data We attach extra bits at the end in this picture So we have k bits of data we attach an extra n minus k bits so when we add them together we get n bits In our example we started with seven bits of data. We attached one extra bit We ended up with eight bits to be sent We transmit that There is What do we attach? Well, there's some algorithm that tells us what are those extra bits in our it was add a bit Such that the total number is odd, but there are other algorithms We send those bits those n bits the receiver receives those n bits and uses that extra information to and Compares that with what they expect to try and determine is there an error or not? that's what we did we Took the receive data and compared to what we expected if it wasn't what we expected error detected That's the general pro approach for error detection The more bits we attach The more chance we'll be able to be successful at the receiver But the lower the efficiency and I think that's the main point there We did an example of a parody check odd parody check. It wasn't that example, but it was another one There's also a cyclic redundancy check at another common algorithm use and there are others But we will not go through CRC. It's much more common, but a little bit more complex We don't have time for it. Then there's error correction What do we do when the error is detected? Well, like we said we can ask the Transmitter not transmitted ask the transmitter to send again retransmit We cover that in the next topic. We'll spend a lot of time on on the retransmission schemes There's another way called forward error correction the sender similar to error detection We attach extra information so that this Receiver can find out where the error was and fix it without getting a retransmission forward error correction They have different advantages and disadvantages. They generally some Retransmission works well when there are not so many errors just a small number of errors FEC works better when there's Quite often we have errors So there are different trade-offs. We're not going to cover forward error correction It's interesting, but no time but The last slide captures maybe the key trade-off for both error detection and forward error correction For a given amount of data Say k bits of data we want to send In our example, we had seven bits The total number of bits we send n So in our example, we had k equal to seven bits of data. We send n equal to eight bits For a given value of k bits of data the larger n the larger the more we send The better we are at detecting and correcting errors. That's a good thing But the larger n The lower the efficiency of the transmission. That's a bad thing. So that's the trade-off we observe here We had seven bits of data where he transmitted eight bits in total if we transmit Nine bits or ten bits or twelve bits instead a larger n we'd be able to detect more errors But it'd be lower efficiency because we have to send extra To get that original seven bits sent. Any questions on error detection? That was a quick topic Let me draw this sequence of eight transmitted bits again We'll explain one more. There's some new terminology What do we have? We had a sequence of bits transmitted That was our example. We had seven bits of real data One bit of header Or I gave it away. One bit of extra information. We call that extra information a header sometimes We attached it at the head of the real data Now when we deal with communication systems we'll often talk about not signals Not just a sequence of bits But we'll group those bits together to get what's called a message A frame or more generally a packet A chunk of data at a time is sent So in this example We had seven bits. So these seven bits That was our original data The first one bit Was we can call the header And together those eight bits Header plus data There are different names for it, but we may refer to it as a frame Sometimes a packet so We have a million bits to send If we're using a single bit parity check each frame would contain eight bits We take seven bits of data, attach one bit Send that Then the next seven bits of data we attach another bit and send that So we'll look at from the perspective of Okay, we have a frame of data Which contains some original data Plus some extra information And if we put that extra information at the start we call it the header If we attach it to the end and we can in some cases we call it what? What if we attach it to the end? It's the trailer at the end. So in general we can have a header data trailer Not just for error detection for for many Systems and protocols we'll look at from now on we'll see that structure If it's at the front of the data we call it the header if at the end the trailer And sometimes rather than listing the sequence of bits. We just will draw as a Set of rectangles. So this means the data whatever it is whatever sequence of bits is represented here We have a header at the front and a trailer at the end. We don't need to have All three sometimes we'll have header plus data Sometimes data plus trailer no header sometimes we have header no data or trailer We'll see some special cases, but from now on we'll start to see Diagrams similar to that and together we call that a frame Sometimes a packet. This is one frame of information one frame of data The header doesn't have to just be the error detection code. So An example of what is in the header Our example was some error detection information So the header in general may contain error detection information same with the trailer. What else could the header contain? Now I think I'm sending data from a to b I send that data in a frame Often in the header will also include who sends it and who's it destined to It's coming from a it's going to be So we'll often include the addresses of the source and destination The source address may be included And the destination doesn't have to be but that's common in some systems And other stuff that helps the protocol work To help us communicate clearly so We have a million bits of data. We break it into many frames We send the first frame In the header we may include a number saying this is the first frame In the next frame we send we include a number saying this is the second frame So when the receiver receives it can put them back together in the right order So that's usually called a sequence number And many other things may be included in the header or trailer I've just given an example of four common things we'll see Who sent it Who's it going to Which order did this come in in a set of many frames so a sequence number Maybe some error detection information a parity check bit or some other information and Through the rest of this course we'll see examples of other types of information inside headers They all contribute some overhead to the data transmission We have the original data to send plus the overhead of the header and trailer The more information we add in there The the larger the overhead but To communicate effectively We usually need some of this information. We can't just discard it. So it's needed for different protocols So from now on we're mainly going to talk about frames and eventually packets. We're not going to talk about sequences of bits Any questions on the structure of a frame before we move on to the next topic


Welcome back to the Average Golfers Channel and today is about wedges and these are special wedges in my opinion they'll let the cow out of the bag already I'm loving these things, been playing around with them all morning here at Wall Street Golf Club and whether you like shiny things whether you like that raw finish on your wedges or whether you like these things that you've seen this kind of copper finish in Mizuno irons of late then they've got every base covered in terms of how they look also in terms of the grinds they offer the lofts they offer the question is why do I think these are so special and why do I think that every golfer is going to absolutely love them in the bag get up get up get up oh in the end that was perfect the interesting thing for me is these wedges first of all we've already seen just how good these things look they're incredible I think honestly and I know there's a lot of positivity around wedge reviews in the last few weeks to be honest with you and it's not something I generally get excited about but I think with Mizuno with these wedges they've took it up another notch in terms of on my eye and I think not just the fact that there's three different types of finishes that you've seen and I think they could appeal to every eye but I think they look really good at addresses the key point it's definitely a player's profile it's definitely more the sort of classic look I don't know whether it would again a few people might be put off by it it's certainly not what you class that sort of game improvement style wedge this is classic wedge done really really well with an immense amount of feeling it I mean again forged head they've just got a set of wedges here which are going to appeal to a lot of golfers and if you're a Mizuno iron player sticking these in the bag I think will pretty much be a no brainer right so you've seen some imagery on just how good these look at least that's what I think but what I want to know from you in the comments down below if you're choosing one of these finishes which would it be is it this chrome is it the the raw finishes to call it or is it the denim copper which I don't really know where the denim bit comes from but anyway once you put your comment down below and took your pick because I reckon you'll fancy one of these three one of the next things I want to talk about is just the confidence that these things give you a tight lie links turf bit of an awkward little shot pin right at the front these sit for me again really nice at address and the thing you want to hear is a bit of confidence I think in terms of how it sits behind a ball so it doesn't feel awkward if you like and I do think some wedges can lie a little bit awkward for me it sits really nice and then it's it's a field shot so again what these give you back into the hands in terms of some feedback they're just absolutely stunning well I think we've done a little bit too firm the idea was to kind of sting it into the bank it didn't quite do that and it's hopped on a bit but again it's just like I said it's that responsiveness out the face and I can only stress that if you've played mezzuno irons nothing feels like a mezzuno well they've pretty much done that and the wedges in terms of the feel and it's their biggest deal the biggest separator if you like for me it's just how good these things feel compared to the other wedges that they're up against I was a really good wedge in terms of distance control and just looking at the pitch mark as well but uphill lie that's got plenty of stopping power control and if you see some of the short shots that I'm playing now in and around greens what you're looking at now is we've got three wedges we've got a 50 a 56 and a 60 these three shots are each played with those and you can see the difference in the ball flight and again very very different not necessarily want every wedge in the bag and you could close the face on a couple of these or open the faces up and get a little bit of variety with maybe just one of those wedges in the bag but the fact that they've got so many different lofts so many different grinds which every brand has got right now can we old birdie can we old birdie now it's stopped on the lip oh there is a 10 second rule and we should just perhaps wait a little in case that one drops now we can't do a wedge test without testing out a bunker certainly not at wallacy golf club these things are gorgeous on the 12th hole it's absolutely surrounded by i'm revetted bunkers looks superb but how good can we get out with a I've got 60 degree in my hand right now can we pop one up that's just coming off the bank that wasn't too bad you know we take that anytime but I think again judging wedges by bunker plate is a difficult one to do at the end of the day it's I think that's very much about your ability as I suppose a lot of this is in terms of the review sits nice plenty of club face open there in terms of 60 degrees it's what I like to play did we learn a lot from that probably not him now one quick thing to mention is that there's a lot of positivity surrounding reviews right now I always say this and so maybe I'm playing these things the feedback I can give you is positive on the field positive on the sound positive on the looks it's all like it's getting a bit boring and so the question is what I'm looking down at these wedges now and what I just thought well if I was feeding back some negativity what would it be and I'm struggling so again if you've got anything in there that you can see that might be a negative that I'm not picking up on then please feel free to stick it in the comments because I'm not seeing it right now but like I said I might be missing something you're going to go in no that's gone past the flag left ourselves a tricky one back but I've got to say that's probably the last shot I need to play in terms of testing these wedges another little tight lie that was 50 degree wedges just played there and again feel is super a variety of shots that you can play I've loved having these 50 56 and 60 in the bag and in all honesty they could quite possibly stay there because this is a wedge that's really hard to find fault with and then you couple that with the kind of looks that they've got when I said hard to find fault hard to find fault in terms of performance then you look at how good they look then you look at the sort of compactness of the club then you've got the feel thrown in it really is a wedge that you cannot find fault with and that's the way I think we'll end it if you're looking for wedges I think if you're looking at vocies you've got vocies in the bag if whatever you've got right now next time you test your wedges make sure you give them a go because they're right up there with the very best I have tried if not the best


Well, I think once again funding is a major challenge, and that's unfortunate as I mentioned because it has been an immensely good investment for the various donors. And there is something that is referred to in the trade is donor fatigue. And I think that's unfortunate. If you look at entrepreneurs, when they have a winning strategy they tend to stick with it. The area was certainly part of a winning strategy, made a tremendous amount of difference to the people of the world and alleviating both poverty and hunger. But the donors get tired, they want to do something new and something different. I would hope that the donor community could say, we'll stick with this winning horse and keep on with it. So that I think is a major challenge. The other challenge would be to continue encouraging the brightest, the best and the brightest of rice scientists to join the area, to work with the area and to enjoy and benefit by that work, which I think they would. It's a problem or it's a challenge, not a problem, and I would hope that that can be overcome. At this session that we're at right now, I've been very pleased to see the strategic plan and to see that the staff recognizes this and is mobilizing to overcome these two issues, both staffing for the future and funding for the future.