 Let's get started. All right, so we're continuing with photography. We've been talking a bit about hash functions. So can somebody remind me what a hash function is? What is the speed of like, hash something down to a certain value of storage? Think of a hash map. Different, different than a hash. So hash is a function you can use to equally distribute through your hash map. Message to a set size. Cool. Yeah? What else can we consider one way? Yeah, so we wanted to go one way so that it's very difficult to go back so that if we have the hash, we're not able to recreate what exactly that plain text was, or the original message was. And unfortunately, I forgot to steal this picture, but I will just draw it really quickly. So there's an awesome, let's see if this works. OK, anyone not know what a blender is? I think we're going to get really dicey because I'm going to try to draw on things. Maybe like a blender. It's like a thing here. And maybe like the stuff in there. Can we all agree this is kind of a blender? You can draw like a thing and it's got buttons on it. Is it getting better or worse? Better? It's getting worse. OK, how does a blender work? Somebody remind me. What is it? It's not a trick question. It chops up bits. Yeah, you put stuff in it, it chops up, moves it, mixes it all up. You can get insane blenders that can, I don't know, grind it really fine in terms of a certain number of microns, so I don't really know what they are, but small particles. OK, cool. So let's do a list of what things I can draw. Let's say we have something that approximates a banana. And something that kind of looks apple-like, an acorn. An acorn? Sure, whatever you want. OK, so we can put a bunch of stuff in our blender. What's going to happen? Let's say we have an infinitely sized blender. We can put as much stuff in it as we want. And it's a really great blender. So when we start turning it on, what happens? Yeah, everything gets mixed around. It gets completely blended. And then, well, this I know you probably know. OK, then we can go and let's say we can pour our juice into a shot glass. So how much liquid could fit in a standard shot glass? A shot of it? Yeah. I don't know. That would be just as much right here. I'm going to take two ounces. Two ounces? Yeah, we're now going to half, I think it depends. We'll go with two ounces. So we can pour that juice into those two ounces. So can you go backwards? Would you be able to reconstitute the fruits from the juice that we made in this blender? No. And my blender is really good. You may not even know what type of ingredients even went in. You may not be able to create that exact thing of juice. So anyways, so similar to hash functions. So arbitrarily size message, all the fruit we want can go into this blender. The hash function is when we press that button, it mixes everything up. And then when we pour it out, we always pour out the exact same amount. So this is how that the output is always the exact same size. So that's like a fixed size hash. OK, analogy make kind of sense. Half functions, blunders. Got it. OK, but we also want other things that we talked about, right? We want essentially a one-way function. So just like our blender, we want it to be that it is very easy to blend, but it's very difficult to de-blend. Would any of you call it re-blenders have that property, right? You can go forward, but it's very difficult to go back. All right, we'll keep an eye on that and see what happens. OK, so we have a case where now we have our hash of M. Output is two bits. So we know there's only, we can just enumerate them, right? We have 0, 0, 0, 1, 1, 0, 1, 1. So we have four possible outputs of any message that we put into this hash function. So we have Alice. Alice, the message is, let's say, I. So Alice is making statements about who, those, or what. OK, so the message is iobob $1,000. So we run the message through our hash function. Somebody want to pick their favorite two bit? 0. 0. So the hash of that message is 0. OK, Eve. And so now we have the signature, right? So the signature of M is the secret key of Alice of H of M. So encrypting the hash of the message with the secret key, that's going to be something so that everyone can verify that this hash came from Alice. We can't break this hash, right? Because we don't have Alice's secret key. We can only decrypt it with her public key. We can't forge a new signature. So what does Eve want to do? Well, Eve wants money, but Alice doesn't owe her any money. So Eve wants, hey, here's a message prime that says, I o e $1,000. OK, so this is our message. So what happens if we run the hash of this message 1 on it of message prime? What if Eve's very unlucky? What will it be? 1-0. 1-0, OK, cool. OK, so if she's stuck, now we can change the message. What if I now say message double prime? I owe $10,000. Let's say this is 1-0, and she tries another one. And we can think of these in terms of probabilities. $10,000, 3 will be 1-1. Really unlucky, so let's just keep trying. I'm just going to put 4 up here. And finally, we get 1 that matches. So now, what can Eve do? So Eve can send signature of M and M4 to Alice. And what does Alice know at this point? What does Alice do to verify this? Decrypts the signature. Yeah, it takes the hash of M4, right, says, is this equal to taking her public key, so the public key of Alice on the hash of the message, which is our original signature. Oh, wait, no, this is Eve. So public key of Alice on the signature of the message. So the public key on the signature will give us the hash of M. So is the hash of M equal to the hash of M4? Yeah, so Alice says, break, and then gives Eve a million dollars, and it becomes immediately bankrupt. So what was the problem? It comes in some pen and that message is deeper. Yeah, OK, so the content of the hash. So sometimes the content of the hash of the message will always be different, because we're shredding down the message into a small number of bytes. But the important thing is we found two different messages that both hashed at the same value. And here, we only had to track four. How come we only tried four? Yeah, well technically we could have kept getting unlucky and getting, I don't know, repeating 0-1 or something. But if we try enough, we're definitely going to get a collision at some point, assuming all of those hatches are equally likely. So we're definitely going to get there at some point. Now what if I did the same scenario but said my hash function, instead of being two bits, is two to the 56 bits? How many would I need to try? A lot more, that is correct. How much more? Which is, let's see, 1.15. I like Wolfram Alpha, 1.15 to the 77, something like that. So now I have this huge space where, even if this takes me, I don't know, a very short amount of time to test these things, it's going to be very, very difficult to ever find a message that maps to that, that same hash function. Cool. So some of the ways that hash functions are used, and we'll talk about these properties more specifically that we want, some of the uses are we can do file or message integrity. So just like we saw, if the message has a message, we can verify that. So we can verify files as well. So anybody use the ZMS file system? So this is a file system that does cryptographic captures and checks of files so that it can detect when files have been changed, because it turns out hard to write directly not as reliable as we think they are and sometimes they'll silently flip a bit. And if you think that happens and it's a good thing, it's definitely not a good thing, right? You don't understand exactly what it is. So this file system incorporates hashing into the file system so that every time you access a file, it will know that it hasn't been changed or any silent bit flips. And then if you do it right, you can do it in a way such that it can recover those bits, but that requires more hard drive space. Well, also as we'll see, this is done for password verification, so a high level idea here is rather than store your password as it is in plain text in the database, if I store a hash of your password, that's slightly better because then I can't just read and go backwards to your passwords. This has actually a lot of problems and a lot of complexity, which we'll get into later. Also used in, you've heard of proof of work in the term of Bitcoin, right? And this is how you mind blocks is essentially, so at a high level, the way kind of Bitcoin and the hash chain is essentially, all the transactions are, so you have one block of transactions, and then to figure out what the next block of transactions are, every miner gets a bunch of transactions from the network and tries to generate a unique value that will cause the hash of that to start with, I think, five or six leading zeros. And that's, and the first person to do that wins and gets themselves Bitcoins, and then you wanna cast that transaction to the whole network and say, hey, I solved this one, and then they go to the next one and they keep solving that and they get this chaining where the hash of every transaction includes the hash of all the perceived transactions and that current block, and it all has to set to some prefix. So this is why you can increase the difficulty of how difficult it is to find and brute force that by saying two zero leading zeros instead of three leading zeros or four leading zeros or five leading zeros. Anyways, it's super cool in there. Also in terms of an identifier, so maybe not in terms of integrity, but this is what we talked about briefly, and we use a commit. So you can see those long hashes that uniquely identify a commit. So it's not really for the purposes of integrity, but it's more so as a unique identifier to talk about a specific commit in a project's history. Cool. Okay, so what do we want from the hash function? So we already talked about a little bit of some of the properties that we want or that need to have happened, right? We need a fixed size output. We need a canteen one-one mapping. We need to be termistic. You can come up with a really crappy hash function that just does that, right? So take, let's say take the first 256 bits of the file or whatever the message is, and that's the hash. You want it to be difficult to find in that search that gives you that hash? Yeah, so just like in the previous example, right? We had a message M, and we needed to find another message M prime that the hashes collide. So this is also a, we started with the term hash collision. So this is when two messages have the same hash output. So a hash collision. So we want it to be difficult to find that. Okay, cool. So let's go here. We're still running, good. Okay, so yeah, the basic idea is given M, it should be difficult. Why can't we say it's impossible? Yeah, there has to be, there's infinitely many, right? If we kept trying, we would find them. But the idea is the search base is so large that it's gonna be unlikely for us to find them. So it should be difficult to find M prime, such that hash of M is equal to hash of M prime. Okay, we also have a property that we talked about a little bit that I will state. Oh, so, okay. So what about the one-way property? So we have this notion of the difficulty of going backwards, but how can we state that? So we go backwards, what do you start with? The hash, do you have just the hash? And what are you trying to find? Sorry, say it again? Yeah, so given the hash of the message, right? Difficult to find M, such that the H of M, we'll even call it M prime, because we actually don't know if it's the same one. Because there's infinitely many messages, right? But we don't wanna be able to find any message. So we don't wanna find the original message and we don't wanna find any other message that also hashes to there. So this is why it can be useful in the password case, right? So if I have the hash of your password, it should be difficult for me to figure out your password from the hash. But my point out is not always the case because people create more passwords is essentially that answer there. But we want that from our hash function. If it was very easy to derive and go backwards, we'd have a big problem. Okay, so what about, so this is maybe another slightly take on number two. Okay, so let's say I'm using cryptographic hashes. I think maybe talk about this on Thursday, where if you think cryptographic hashes and I want to give you a hash and then some event happens to roll whatever and then I'm gonna prove to you that I predicted the winner because I gave you the hash beforehand and I'm gonna give you a message that hashes to that same value. Do we want that? So do you, what do I want you to think about that? Yeah, so that's part of the term that's taken. Yeah, we definitely have that. If a message is hashed once, it will always return that same message. If you only have the hash, so I only gave you the hash, you don't have the message until after the event took place. So what do I want you to think? So let's start with a good, like, I don't know. I want you to think that that was the message that I used to generate that hash, right? But how do you know I didn't find maybe two different messages that one message happens to say before an average win and the other message happens to say the cheese win? I figured out that they won't hash to each other. Two, second one has to do with cheese. Yeah, maybe plus two. Maybe in terms of that, so we definitely want two similar messages having two different hashes. We also, like, going beyond this, right? So the second pre-image is given a message, it should be very good, we'll find another message. But here, because I play around a lot with each of the messages. So if you think about just that message, who's gonna win? I can have white space anywhere within that message and you'll just think, well, this is weird, but whatever. The content of the message is still the same. So here, I can kind of search for two messages simultaneously that have the same hash. So rather than being one message is fixed and saying this is the message, I've got to find, so for instance, in the case of the Alice message, right? We broke it with this, right? We found we were given Alice's message and Alice's hash. So we could not change the hash. And we need to find another message with a hash to that same value and have a hash collision there. We also want it to be the case, all right, so let's look at this one. So pre-image resistance, so given a hash message, hash value h, so we're giving the output of a hash function, we want to derive a message that matches that. Right, so in this case, what is the attacker control? Yeah. Can't control the message but doesn't control the output of the hash function, right? Or another way to think about it is what is fixed in this case, right? Fixed is the hash function, the attacker cannot change the hash, sorry, the hash function's always fixed, the output of the hash function. So the hash of the message is fixed and the goal of the attacker is to find a message that maps to that same value. This is different than second pre-image resistance. So if we're given a message M, we want to find another message M2 such that the hash is matched. What's the difference between pre-image and second pre-image? The attacker controls the input but not the hash function. Exactly, so the attacker is given the message, right? So they already have one message and they know what the output of the hash function is on that message. And the idea is it should be difficult to find another message that hashes to that same value, right? So what's fixed is the original message and the hash of that original message and the goal is to find some other message. So this can be based on weirdness and the implementations of hash functions. Maybe it's easier, the second pre-image than pre-image resistance. Pre-image resistance, is that true? Yeah, I'm not gonna claim that, okay. And then when we talked about the last one, the collision resistance, right? So now, how much freedom does the attacker have here? Provide a, for example, he can like provide a, he can't claim to only provide a long, a long thread to me, but also produce another key. Yeah, so this is kind of a second pre-image resistance kind of in advance. So the attacker can create and control both messages. So they can alter both messages. The really cool thing is on hash functions that have been broken, like I think MD5 is the traditional one that's super broken at this point. You can generate different PDF files that all have different messages that all hash to the same MD5 hash. So it says, so when it's, this happens it's really broken, like this is a, definitely a bad situation, but that doesn't mean that just because you've broken collision resistance, doesn't mean you've necessarily broken all of the others. Questions on this? The other, let's see, some other important things about hash functions. So MD5 is a famous one that's definitely been broken. I think SHA-1 has also been broken, but we can talk for a second about what this means in a cryptographic context. So when we say a, so again, this all goes to, I think SHA-1 uses 256 bits. No, maybe 128 bits, doesn't matter. So we know we can break this by doing roughly two to 128 number of work, right? We can find a message that hashes to the same value. We're likely going to find that message. What's something like, if you were gonna call something broken, what would that be to you? The message that has the same hash function in a reasonable amount of time. Yeah, so reasonable, so it would be reasonable. That's the map, I don't know. Maybe a couple of weeks. Depends on what you're trying to, depends on the original message, what you're trying to, oh, is this message still important in three weeks within two weeks to five? Cool, yeah, just like we talked about with encryption, right? Time to break it is an important factor. So what is the important time? If the hack that you're talking about breaking are, let's say, packages that you download from the Ubuntu distribution that has hashes of all of the values there, so that they're verifying that nobody's tampered with the binary and trained it. If it takes an attacker three weeks to do that, maybe it's okay. Yeah, so this is kind of the interesting way to think about broken. The funny thing is cryptographers have kind of a strict definition of, it's essentially broken if it's anything less than two to the 128. So it's considered broken if you're just able to reduce this by a factor of two, and say I can do it into the 127 reliably. And the super interesting thing is that this is basically to demonstrate that over time, it's always able to make these attacks go faster and faster and break it more and more fast. But as soon as there's any hint of trouble with a hash function being broken, it's time to move to a new hash function. Cool, questions? All right, so now that we know about signatures, the problem is I wanna check that this is recording, but now when I go back, I don't know if it's recording. Okay, so, and we're gonna get back to hashing, especially as it relates to passwords, don't worry. We'll talk about a lot of different properties there. And so, what are, so we've now kind of looked at a lot of different things, right? In terms of photography, we've looked at classic encryption, we looked at modern symmetric encryption, what was the main problem with modern symmetric systems that caused us to move to the public key cryptosystems? Do you guys think any symmetric cryptos had public key cryptos? Or did CVC, I like how to use symmetric cryptos, but that definitely wasn't a problem. The shared secret. The shared secret, right, the key. So the key problem with symmetric cryptos, we've packed into the key, we have to transmit this key over a shared medium. And so we said, well now we have this great revolution because now we have these public key cryptosystems that we don't need to share a secret, but what do we need to have happen there? What were some of our assumptions in public key cryptos? Yeah, so specifically, so we can assume everyone always has their secret key, right, otherwise, I mean, everything falls apart, we say that, but we assume that everyone do everyone's public key. Is this feasible? What happens, let's maybe walk through a case. What happens if this is not true? Alice and Bob, and they all have their keys, right? Bob's public key, Bob's secret key, Alice's public key of Alice and the secret key of Alice. But they don't know each other's keys. So now how do they communicate? And we have Eve over here, so remember, we can't forget about Eve. That's the public key of Eve, secret key of Eve, yeah. So Eve could just tell Alice that Bob's public key is Eve's public key, and then you have the public key. Yeah, so we have this problem of how, essentially how do Alice and Bob share their public keys with each other, and know that they actually own that to the public key, right? So we assume that Eve is a really strong adversary, Eve can listen to, monitor, alter any of the transitions between Alice and Bob. Okay, keep going. Cool, just because Amazon is still a problem, it's the way to know to be hard for someone to make that public key that you can access it anywhere. Yeah, but the first time I act, I'm a brand new machine, I go to Amazon.com. How do I know that? How do I know that Microsoft or Apple hasn't put some crap on my computer, or got installed in the factory by somebody to pretend to be Amazon and steal my Amazon username and password and login and act as me? I don't know if it's Spotify or the Google search engine, they verify it and it's really nice. Yeah, I gotta trust somebody in the problem, and this is actually the key problem. The question is who, right? Cool, so we'll look at two different ways, there we go, okay. Okay, so this is a massive, massive, massive problem. And okay, so let's think about some ways we can solve this. Do we have Amazon? So now what if, so what if we just had another entity, right, we just had some other entity that Bob can ask and just say, hey, secure tech or secure company, what's Amazon's public key? And then Amazon, and then it would return us back the public key of Amazon. And then maybe Amazon could then ask secure tech, hey, what's the public key of Bob? It would give us the public key of Bob, and then we'd use those public keys and never have to exchange them. Benefits, does this solve our problem? Yes? If you trust the connection you have with secure tech, then yes. Yeah, so now I have a problem of trusting the connection to secure tech, what else do I have? I burned into my computer the public key of secure tech, so each of us, me and Amazon can both establish a secure communication to secure tech. Yeah, so now it's burned in or something. Yeah, we'll go with that. We'll assume that that's trusted. We'll at least assume we know the public key of secure tech. Yeah. And then what happens if secure tech goes bankrupt? Yeah, what happens if they go, or what if they're just knocked offline for five minutes or 10 minutes? Think about how many requests are, how many websites are there on the internet? I think millions is... At least 200. Maybe too low? I don't know. I think the Google... Yeah, can somebody Google that? I think it's, Google's probably indexed 60, 600 million? I don't really know. One billion point. A billion, that makes sense. And that's just the sites that they can index. So there's a bunch of other things that they don't necessarily index. So roughly a billion, so, and how many people, how many users does Facebook have? Let's think about that. And we know the number, 2.9. Yeah, I know it's upwards of a billion. We'll go at just three to make it useful. So we have three billion people who all wanna talk to Facebook.com at least once a month. Each of them would have to talk to the secure tech to get the secret key of Bob's before they could ever even talk to Facebook. And think about the, if there's just two billion people accessing a billion websites, how many websites do you visit in a day? Five, 10, zero? You're using apps, they're apps are talking to backend databases, they're all communicating. You have to verify again. So you can think of almost every web transaction under one point of failure, which would have to be able to support essentially not traffic as the largest of the largest internet carriers. So something like this is doable, but it's probably not technically feasible to a level of reliability that we would want. And also, so in terms of reliability, we don't want this because if they go offline, literally the internet would probably stop working maybe. Also, what if Amazon is an updated public key? How does it do that? And then how does that then go to all the people who use Amazon? What are some other downsides? What happens if secure tech gets hacked? Yeah, so you can have access to it or you can update or change the public keys of different users you can have. Your secure tech service responds differently with Eve's public key, when specific users talk to that service so that Eve can do a man in the middle attack on them. Yeah, you can do all kinds of super bad stuff here. So this would be like a centralized model. Then this is kind of the most central where you have one entity in the middle. It seems a little bit crazy to at least have everyone make requests to this secure tech. So how do we take them off of the loop? And send public keys with secure techs? Yeah, so now if I have... A secret key. Public key of Bob. Secret key of Bob. No, public key of Bob, secret key of Bob, Amazon, boom. Okay. So now maybe beforehand, how can, and the question is, this is a good test for kind of like crypto primitives, how can Amazon prove to Bob that secure tech has verified their public key? Hatch from secure tech, so Amazon could register in some secure way to prove to secure tech, hey, I actually am at amazon.com. And they could then get back a what, a hash of their public key. How do I then, how does would Bob know that that hash actually comes from secure tech? Instead of a hash, you could encrypt, you could have secure tech send back the public key encrypted with their secret key. Yeah, but it may be big. I don't want to use hashes, hashes are great. So then do that with the hash. Right, so now I've encrypt, I've signed, so it's the basically the, so secure tech signature on the public key, right? So that's what we can call this. So secure tech has encrypted the hash of the public key of Alice with their private key, right? So they've signed the public key just like we talked about with hashes and signatures. And then Amazon now can store this and when wants to talk to Bob says, hey, here's my public key and here's the signature from secure tech on my public key. Now how can Bob verify this? What does Bob need to verify this? Does Bob have all the information to verify this? No, what's Bob missing? Yeah, so this is where we still get back to that thing where well Bob still needs to know in advance the secure tech public key, right? But if we again make the same assumption that that somehow burned in, everyone knows secure tech's public key. And in this case, if secure tech is responsible for doing the second encryption for all the internet verified keys, it would make sense for that public key to be put on planes and all kinds of things, right? Literally everywhere, so that everyone knows that that is their public key. And Bob could do the same thing. So Bob could then register as well, get a signature from secure tech that says, hey, I am this company. Okay, so we've fixed the, let's say we rely, so we don't need now, so every, in this scenario, everyone who wants a signed public key by secure tech needs to verify with them, maybe offline or something like that. But then once they have that signature, they can send that and anyone can verify that their public key is, and they are who they say they are. What's the downside? If secure tech gets hacked, then they might need to change their secret key, which means everything, every signature from before would be invalidated. Yeah, so we need some way to, if the secret key, so if Eve is able to steal the secret key of secure tech and nobody knows it, if you can forge a signature, if you can pretend to be anyone, right? So we've created a single point of failure where in this one hacking point, where somebody hacks into that system, it's game over for everyone. So the security of this model still rests on secure tech like it did before. And we can call this a, so we can do some terms, so we can call this, so we can call this a certificate authority or a CA, in that the secure tech is issuing certificates, which are these signatures of the public key with the public key. Two people are taking their public key, creating a certificate that anyone can validate that it came from secure tech. But relying on just one company is kind of crazy, right? And again, and if you think about it from an economic perspective, what do we give into secure tech? What kind of prices can we expect from secure tech? Whatever they want, why? Yeah, they established a monopoly because they tricked us into burning their key onto all of our machines and trusting their public key, right? So they have a monopoly on essentially the certificate that they give out and so they can essentially charge any website whatever they want to do this. So kind of from an economic standpoint, it's not a great idea to build something like this, even if we get this great public key crypto system. And so we maybe want some ways to create maybe competitors here, right? So, bless you. So we maybe want to, very secure tech would wanna come up and we need a way to get their public key of very secure tech. Also think about politically, this is why these decisions are not just technology decisions. Politically, if a U.S. company controls the sick certificate authority, do you think that would fly in other countries? Yeah, the U.S. could do so, even if this company could access maybe their secret key and start impersonating people, right? Or it would give, even if you don't think that overtly, David Lee would read about that, I meant to send it out. David, you've seen that news article about that crypto AG company. So crypto AG was a company that in the 40s sold the U.S. a lot of their cryptographic systems. And I think they were a U.K. company, they were definitely in Europe. So eventually the CIA and the German secret service essentially bought control and the NSA probably, bought control of this company. Now they have proof that this is actually what happened. So this company was selling cryptographic services to not the major players, so it wasn't Russia or China, but it was like, I think Iraq was in there maybe, in some other countries. And so various companies bought their crypto system from this company that was ascended backdoor by the CIA. So this is a clear proof of why you don't want to rely on other countries for your countries to cure cryptography and communications. So the actual way in the model this works is, so this entire question and operation is around this concept of public key infrastructure. So this is, you can probably have a whole class just on public key infrastructure, all the problems, all the attempts of solutions to solve these things, of how do you do this? And so the way it kind of works now is you essentially have a, anybody use any, well, we'll talk about that in a second, okay, sorry. So there's, so it's essentially a formalized model trust, no, we call it secure tech. And okay, you can think of there's a roots of these trees that are certificate authorities that whatever system actually does trust. So this burn in process literally does happen. So when you download Google Chrome, there are a set of certificate authorities that Google says they trust. And then they can actually delegate trust out to other companies and other entities. So you can have a central, maybe the USCA, which actually doesn't exist, but you have one CA and then that CA signs a certificate for VeriSign. So VeriSign now has the public key of VeriSign. And you have the signature from the certificate authority on the public key of VeriSign. And then VeriSign could say, oh, and we also trust this other company, Foo, and then they would get the public key of Foo, the signature from VeriSign on the public key of Foo, and probably also the signature of certificate authority of EVS. And so if your browser, your Bob, and you get something with this, you know the public key of CA. You can verify all of these public keys that you're given. This entire, what they call this, root of trust. So you can verify all these public keys that you know, okay, if I trust CA and I trust who they delegate to, then I can verify that these are all been signed correctly. So you also get this nice kind of desensitization process where it's not the central CA that has to do everything and has to operate for everyone. They can also do competition models here. There's competition with the browser. So your browser can decide, and actually Google, definitely Google has revoked access to certain certificate authorities that it was found that either through hacks or whatever, they were creating public keys for Google.com, which they definitely should not be doing. And once they find that, they revoke the public key. Anybody use Let's Encrypt to run a server? That's a free server you can use if you ever run a web server to get a free public key, which is super awesome, could you prove that you own? Because otherwise through VeriSign, it's like, I don't know, $120 a year or something, maybe higher. With Let's Encrypt, you can do it for free, but then they had to fight to get that certificate authority included inside this whole PKI infrastructure. Because otherwise browsers don't trust it. The other question I'm gonna ask is, anybody either use a military, I've tried to access a military secure site, like not secure secure, but secure in the terms of HTTPS secure? If you do, you'll notice that oftentimes it'll say the certificate warning because your browser does not have the Department of Defense certificates inside of it for obvious reasons. And so if you want to have it so that that certificate is verified, you can actually import, and so everyone can add, you can choose to add other certificate authorities to your browser, so your browser will then trust them. And then this is how, if you remember, way back when we talked about people who use their employer's laptops, and I said your employer can man in the middle all of your connections because they've installed their own certificate authority on your work machine that said we'll only trust this, anything signed by the certificate, and that means they can intercept and monitor all of your traffic. So all that stuff all comes down to this idea. Cool. And we also have, so yeah, we have this main problem then of revocation. So how do you, if Amazon goes to their certificate authority and says, we've been hacked, we need to change our public key, right? How does then the certificate authority tell everyone else not to use this public key? So you have this massive revocation problem. And then I think we'll maybe stop there. Oh yeah, cool, okay, we'll do this very quickly. So this is, now you've actually learned enough to understand at the conceptual level how encryption works whenever you're visiting an HTTPS website. So HTTPS, which uses TLS and SSL under the hood to do the networking, it uses a public key infrastructure. There are root certificate authorities. They're distributed in either your operating system or in your browser software. There are, and the super interesting thing is there are different types of certificates. So some that just say, hey, I've validated the domain versus an organizer versus extended validation, EV, means that they've actually verified that you're a corporate entity or a person that owns this domain. And that's why, if you've ever seen this, so you can see this was on Safari a while back. But if you went to my website on Safari, you would see a little lock icon. So what's this lock icon telling you? Yeah, so A, that this communication is encrypted, so it's using HTTPS. And B, that the browser, and this is something that's not surfaced, but directly. But B is verifying the identity that this certificate from adamdupay.com was actually cryptographically signed through the certificate authority. And I can verify that one of the certificate authorities in my browser trust that certificate. But if you go to something like apple.com, you can see a different indicator where it's green, a green lock that's nice and colorful. It says Apple Inc. And this is the extended validation. So Apple went through the process with a company to verify their identity and have it show up here. And you can see this too in Chrome, although Chrome is now getting rid of this secure warning. I think they've done this recently. Has anybody noticed that on desktop? It doesn't say, when you go to HTTPS, it looks normal. And when you go to HTTP, it looks red. There's a red line through it to indicate to you that it's insecure. So rather than, it's kind of like a, the way they phrase this is it's kind of like a check engine light on your car. So what does a check engine light on your car mean? Something's wrong, right? There's not a light on your car that says everything's great and though there's a problem, it just suddenly goes away. So it's the same mental model here where they've changed it in Chrome to where HTTPS is essentially the default. So if it's not extended validation in HTTPS, everything works as great as normal URL. And then if it's on an HTTP site, you'll see a red dash through it to warn you that it's actually an insecure channel that you're using. Cool, so we'll think about what's an alternative. So what if you don't trust a central authority or a certificate authority to deal with this problem? How do you try to solve that? So we'll look at that on Thursday.