advertisement

>> Justin Stiles: Thank you for coming. I see a lot of friendly faces in the crowd and hopefully the online presence is good as well. I'm Justin Stiles. I'm a part of OSU security and we're sponsoring along with Research this talk that Josh is going to be giving us. There is a sign-up sheet somewhere around the room. Raise your hand if you've got it. If you happen to make all six in person you will get a special prize. Online doesn't count. Sorry, everybody, but that's kind of one of the fun things that we are doing to get you to show up. We hope it's an interactive conversation so Josh is ready to take questions during the talk, or you can save them until after, but make sure you sign up on the sheet if you're here, if you're present. It won't be something, you won't win a vacation to Disneyland or anything, but it won't be some random tchotchke. It'll be worth, hopefully forthcoming for if you started today. Josh in my eyes really needs no introduction. If you want to know cryptography or have questions on cryptography, he's kind of the guy. You guys can read his bio. You know he is well qualified, but don't let him slip up, if you've got any random crypto questions during his talk. I think he's up for the challenge, so let's give a round of applause for Josh Benaloh [applause]. >> Josh Benaloh: Okay. Thank you very much Justin. I presume I can be heard? Good. Those of you who online and didn't know about the prize, you can still make it here by the end of the talk and get your name on the list. Just to make it clear what's going on, we've got six sessions planned. This first one is going to be pretty much a broad overview touching on a lot of things that are very high level and then the remaining five will dive into more detail on various things, and there will be some flexibility. I've got some things in mind that I want to be talking about, but if you have things, directions you want to take things let me know and hopefully we will be able to accommodate. Anyway, to start things off a lot of people like to talk about internet security. That's kind of why many of us are here. It's worth remembering that the internet was not designed at all with security in mind. It was designed basically for a small number of mutually trusting and trustworthy entities to exchange whatever they wanted to. And pretty much sending anything on the internet is like sending a postcard through the mail in the case where you don't really trust the post office. It's a difficult environment to work in, but we can manage some things. What does a typical internet transaction look like? Assume that we've got you out there browsing the web and maybe some merchant you maybe want to buy something from. Let's say you want to get a book from Amazon. You may have in exchange. Let me look at this. Here is the information. I like that. People who looked at that seemed to have looked at these books also, so you look at those books. Eventually, maybe you get to a point where you hit you have convinced me. I want to buy something. Amazon is very happy and they say great. Please send us your credit card number. Well, okay. Here's my credit card number. Remember that thing about postcards and whatnot. This is not a very good state of affairs, so we want to find a way to do better than this. Ideally, everything, that whole conversation is protected so that people can't see my browsing history and my Amazon browsing history just in that little environment. But at the very least, we would like to encrypt or someway protect the credit card numbers so that only the merchant sees them. Even that's a problem and I will talk about that later. Let's try to get at that as our first goal. This is going to take us a while. It's going to take us most of the next 30 minutes or so. To begin with, it's worth mentioning Kerchhoffs's Principle. This dates back about 130 years and says that if you are building a security system that the system itself, the security of the system itself shouldn't depend on everything being hidden. You shouldn't use security through obscurity. You should be able to make everything you are doing public except some very small bit piece which is the key. That's the goal. It's interesting. At this time locksmiths adopted this wholeheartedly and that's an industry that has now flipped the other way and they are like you shouldn't be able to understand how locks work. Knowing how locks work makes you a special person who we have to keep track of, so that's an industry now that is based very largely on security by obscurity, not knowing the tricks in how to pick a lock, for instance. There are other industries that have gone hard in that direction of trying to hide things, but interestingly, some industries have embraced this coming out in the open. Not just cryptography but, for instance, the gaming industry, Las Vegas, you can go to conferences and workshops where they'll talk about all of their vulnerabilities completely openly, what tricks have been used at the blackjack tables in the last 12 months and whatnot. They'll talk about things and they decide that sunshine is a good thing and I think sunshine is a good thing. I think this principle is worth following, but it does mean you have to be very careful with your keys. When I talk about keys, let me talk about what I mean by a key. First of all, I'm not talking about a PIN. This is just a little tiny nothing. I'm not really talking about a password either. This is something small, something pretty guessable most of the time. What I mean when I talk about a key is a big random at least 128 bit string. The reason that this is important is that pins and passwords have a place but they only have a place where off-line attacks are not possible. Think of what happens if you try to enter a password too many times. You get locked out very quickly. If I had a way of checking through a password space without being online, without interacting, then passwords, pins wouldn't work at all. For cryptography though, if we're going to encrypt something you can check off-line whether the, what possible key will decrypt it. When you have an off-line attack, then anything like a pin or a password is terrible. Everything may be subject to an off-line attack and it's something we need to consider. An attacker just as a rough estimate, might be able to search through as many as two to the 64 values. That's a good indication as to the size of the space that an attacker may be able to search through. Think about what that is. That could be all numerical pins of fewer than 20 digits. There are very few people who I have seen that enter 20 digit bank pins. Passwords, fewer than 14 lowercase letters, most of our passwords aren't quite up to that. We could add a few characters of the alphabet. How about alphanumerics, still fewer than 12 characters or printable passwords, still, anything fewer than 10 characters is in some sense searchable. These things still work for the online only application of entering a password to get access to something and you get locked out. But if you are trying to use this in a cryptographic manner as a key, you're going to have problems. Don't even think about using any user chosen passwords as an encryption key, please, nor anything that's been derived deterministically. That's just as bad. Basically, given some ciphertext, an attacker can just do some sort of an exhaustive search, a guided search through the space of up to two to the 64 things and crack your user chosen password or anything. Basically, there's no such thing as a user chosen key. Think of a key as something that is really just a big random value. Something that doesn't apply that much anymore but I decided to keep this in his dictionary attacks, because you do hear people talk about these against the space of passwords, say. The idea is, basically, it can often be the case that you try one password and encrypt this common password one, two, three, four, five, A, B, C, D, E, whatever, and then you can sort of scan through and try it to see where this encryption matches something because you saw the way it was encrypted. There is a little trick that is often used here of make sure everything is encrypted differently and use some sort of a SALT, some sort of initial value. It can be public, that value but make sure it's a different value for each encryption in some way and we'll be using that a lot more later in the next session. Let's get into the meat of things, into the S’s and start talking about what you might think of as encryption. An encryption starts out as symmetric encryption. Basically, symmetric encryption is there is a key; I've shared a key with somebody else. I use the key to encrypt; you use the key to decrypt. That is traditional encryption as it existed for literally millennia. Caesar ciphers, in fact, can be thought of as bad. That goes back quite a way. How do we do this? When we talk about symmetric ciphers, there are usually two major classifications, two broad groups of symmetric ciphers we can talk about, stream ciphers, and block ciphers. I'll spend a few minutes talking about each and surely you have a work and we'll spend more time looking at these in a future session. Stream ciphers are few examples but really RC4. This one is like everything. This is like 99.9 percent of what you see. A5/1 is used in cell phones, so that has come up a little bit more lately, but RC4 used to be like 99 percent of all encrypted traffic anywhere in the world was RC4. What you do with any string cipher is basically you build a pseudo random generator. If you've ever seen a pseudo random generator, thought about these, these things are very, very important for many applications, but all a stream cipher is is just a pseudo random generator and all you do is you take the stream of output bits from the pseudo random generator and XOR it with plain text to form ciphertext. Here's pretty much what it looks like. You take your plaintext. You take your seed and put it in your pseudo random number generator and you create a stream of key bits and you just XOR every bit and you get a bit of ciphertext. How do you decrypt? You do exactly the same thing. You can even use exactly the same function. The ciphertext goes in the top, gets XORd. When you XOR with the same key bits twice you get back to where you started; you get the plaintext back. It's very simple, very easy, so much so that I will show you one common example. I talk about alleged RC4. There's an interesting history here. RC4 is a trade secret of the RSA Corporation. It has presumably been leaked. There has been leaked implementations and leaked descriptions of what this looks like, but technically still if you use RC4, you have to pay RSA Corporation, but as a trade secret this thing called alleged RC4 has been discovered. It seems to on all inputs and all outputs for anybody who has tried it does exactly the same thing. But we will talk about alleged RC4 here. It's quite simple. You take a byte array, 256 bytes and you stick in all possible values in order. You also take another array of exactly the same size and you replicate your key as many times as necessary to fill this array. It's completely flexible. You can use 128 bit key is commonly the case. You can use a shorter key. You can use a longer key, just repeat the key; fill this array with that key, repeat it over and over. Then just for the setup you go through this little tiny loop, 256 times and what you're doing is just shifting this array around. You will still have one this is over all 256 possible bytes in that array; they will just be in a different order. What you do is take what's in position i here and what's in position i here and add them with a j which started at 0 and compute a value and then just swap two elements in this array. And just go through a bunch of times and do a swap and get it all scrambled up. And this key caused the swapping to be done. Once this initialization is complete, this 256 steps of initialization, then you can start streaming out bytes and the way you do this is I started 0. You just keep incrementing i. You keep incrementing j not by 1 but by the value in the i position and you do another swap each time, so you just keep on swapping those values in this array and you compute a new index which is the two values that you swapped and you output whatever is in that position. This is the entire pseudo random number generator known as RC4. You can put it on a T-shirt. You can put it into slides. You can put it in any way, but it's still alleged. It is extremely fast. It's extremely nice. It's got a lot of good properties. It was discovered years after it started being used. There's a little bit of a bias in the early bytes of the output that had been used to break some things, so the current recommendation is just sort of throw away the first thousand or so bytes and just start a little bit later. Stream ciphers are great. They are typically very, very fast. You can see this thing just screams. You just do a few steps and then you get another byte. Then you just keep on going, 10 cycles or less per byte. They are very simple. Encryption and decryption can be identical, literally, but there are some problems. I'll hit the first one right here. What happened there? It wasn't on my machine. You can probably guess what that operator is supposed to be. I don't know why that -- but anyway. If you ever use the same key stream, ever, ever you have a problem. Here's plaintext one. Here's plaintext two, ciphertext one and ciphertext two. If you XOR these two ciphertext what happened to that key? It's gone. The key XORd with itself. You just get these two plaintext XORd together. And from two plaintexts XORd together you can usually tease those apart. Now you have the two plaintexts and you can derive the key that was used and the packet and anything else. This happens surprisingly often even amongst people who know it should happen. A few years ago I was working with a team in Office that will not be named and using a stream cipher and saying yes, yes. We know about all the pitfalls. We are very careful; we don't use the same key stream. What we do to make sure of it is we derive the key stream based on the filename with the whole path. Okay. Think about this for a minute. I'll point it out. That's great for separate files, but what if you change a file? And I watched 12 jaws around the table simultaneously drop. Yeah, okay. It's a mistake, but basically stream ciphers are fragile. It's really easy to mess them up. Here's another way in which they can be messed up. Take a look at basic stream cipher; how we designed it is bit by bit. Every single bit encrypts to a single bit. There's no interaction across the bits. I hear people joke sometimes that this is terrible because anytime there is a 0 here, that means that bit when unencrypted. [laughter]. Okay. But there's another problem when you're doing it bit by bit. It's very easy for an adversary to alter the ciphertext in a way such that it will have very specific known impact on the plaintext. You may have read well structured text. Maybe here is some sort of a bank transfer notice. Please, transfer two dollars and you know exactly what the form of this is. Here it comes. It's encrypted and I know that the second byte in this value is going to have the amount. I can just take the ciphertext and just flip one little bit and suddenly the bank transfer is an encrypted version of this. That also leads to undesirable results, may be undesirable for Bob, no for Alice in this case. But you can see that it can cause some problems. These are the two biggest problems with stream ciphers. The reason that fragility exists so much with them is lack of integrity checking to make sure that this hasn't been done and key reuse which happens to even people who think they are being careful to avoid it. Microsoft policy requirements, part of the SDL, don't use stream ciphers. They are so easy to mess up. Don't use them. They are nice; they have lots of good properties and if you really, really have a good reason, you come to the crypto board and you plead your case and we'll make sure that you are doing it okay, because we do use them in places where they are reasonable to use, but as a rule avoid them. The alternative is block ciphers. A block cipher basically look something like you take a key, you take some data and you churn for a while and outcomes ciphertext. Let's take a look at what this might look like. There are a bunch of ways of building these things, but I'm going to show you a really clever way of building block ciphers that works very well. Lots of block ciphers have been done this way. It was invented a little over 50 years ago by a guy named Horace Feistel. The basic idea is you want to make something that's really ugly function that takes bits and scrambles them all up and is really hard to figure out what is going on. That's what encryption is in some sense. But it has to be reversible. Reversibility is kind of hard, but if you want to encrypt, you've got to be able to decrypt. How do you make this really, really ugly and nasty and difficult but also make it reversible? Here's this really clever trick. You take your input up here and you break it into two halves, the left half and the right half. The right half goes through the ugliest function you could imagine and it doesn't have to be reversible. What you do with it is take that XOR with the left half comes through and that becomes the right half. The old right half just goes through unchanged here. The nice thing about this is that even though you've gone through and under reversible function here, you can reverse this. You can get from the output back to the input by just going up and doing the same thing because you still preserve the input into here. You've still got it so you can reproduce it and do the XOR and get back to where you started. That works pretty well. Except, wait a minute, we left this half unchanged. Okay. Sure, but we can do it again. Coming from here now we will do another. Now both halves have been messed up and you actually can do both of these things essentially in parallel because you can see this is coming down to here. You have to wait a little bit, but you can compress the effort, but now both halves have been done. And things go through much more easily and you have done some encryption. This is good. It's not really good enough. Usually when you do these things you keep on churning. One thing you do, put in the key here. Whatever key you had, the same key doesn't have to be used in both of these functions. You can mix it up a little bit, but also you iterate, so typically one of these Feistel ciphers are iterated for at least 10 rounds, 16 rounds, often more. You use different sub keys for each round and with this, even if your ugly function in the middle is very weak, you can get a very strong cipher by just iterating enough. I would never recommend that you roll your own cipher. If you had to, don't do it. But if you had to, if you take some really lame little ugly function here and iterate it 100 times through a Feistel network like this, you'll probably have a pretty good cipher. It'll be slow. The trick is making it so you don't have to iterate it for 100 rounds, which can reduce the number of rounds and make it fast and efficient and still very strong. If you iterate it for 100 rounds you will probably get something that is very good. I'll just take a moment to show you an old style cipher that uses this. It was very common in the old days, not so much anymore, but the data encryption standard was the first widely used public block cipher. The main reason, the main problem is, besides being a little slow is that 56 bit key. Remember we talked about being able to search through 2 to the 64 size space. This is smaller than that. You can do exhaustive search on this. Just to get a sense of what can be done and how a real cipher can be built, also the 64-bit plaintext, by the way, is a little bit short for larger block sizes now. A Feistel cipher is done here, 16 rounds. Let's take a look inside one of these rounds for DES. All that's going on is one of these Feistel rounds and the only thing you have to describe is the ugly function in the middle, and in the case of DES it looks pretty much like this. I'm oversimplifying a bit, but you take 32-bits in because it was 64 bits. The right half is now 32 bits. You take a piece of the key, 32 bits there, XOR them together, take this, break it into 8 4-bit blocks. You have a substitution table for each block that says if you see these four bits, you substitute those four bits and then you do a permutation and then you have used 16 rounds of this. Now the actual DES is a little bit more complicated but not a lot. What's done is this 32 bits is expanded to 48 bits by every block taking a neighboring bit off of the neighboring block and just absorbing it. Than the substitution tables go from six bit values to four bit values and the subkey for each round is 48 of the 56 bits, just taking some subset of the 56 bits each time. That's all of DES. That's a full symmetric encryption function, a full block cipher. Let's get back to where we started. We know how to encrypt now. Great. We can go back and solve this problem. We get down to the point where we want to buy something. You get the question of what's your credit card number, and you say here it is. I can encrypt my credit card number because I know how to encrypt. I got a key. I can encrypt. Except what likely happens is I want to make a purchase and Amazon might say okay. Encrypt your credit card number with our shared key because this is how we're doing this, right? And if this is the first time you have gone there and say what's that shared key again? And we could have an infrastructure that says okay. First time you go to Amazon you say I want to set up an account and via snail mail three days later comes an envelope with the key in it. You type this 128-bit key into your browser and now you can buy your book. If we had no alternatives I guess this would be the best business model we had but hopefully we can do better. To do better, we need to fall on asymmetric encryption. Asymmetric encryption deals with the case of a user and a merchant which have no prior relationship and allows someone to encrypt a message without knowledge of decryption key. Somebody in the back of the room right now who I have not met, I could give you instructions and say okay. I want to send you a secret message. I tell you what to do, do this, this and this, tell me what you got. Pick some random numbers, do the following things and tell me the answer you got is. I will use that answer to encrypt my message to you and only you will understand. That's what we can do with asymmetric encryption. I'm going to show you how. Again, we'll talk about it in more depth later, but most of asymmetric cryptography, whether it's RSA or Diffie Hellman or elliptic curve cryptography, uses this equation in some form. When we deal in elliptic curves, we usually write it differently, but I prefer writing it this way even for elliptic curves, making the group operation multiplication and it still looks this way. Basically, this is an equation in some form or another that we need to work with and solve. Let's look at this equation a little bit more. When the unknown is over here, you are just computing this modular exponentiation and it turns out it can be computed efficiently. I'll spend a few minutes on that. Let's look at some other cases. When this is the unknown, this is known as the discrete log problem. If we eliminated the mod n for a while, then you are just computing the logarithm of z to the base y. We can do that. If there's no mod here that's easy. There are lots of ways of doing it, but you could always do it just sort of by a binary search and interpolation and get closer and closer. What the mod n does here is it makes things chaotic because taking things mod n -- just to make sure everybody in the room knows, mod n is just take the remainder when divided by n. It's basically just dropping off everything but the low order this, or the low order portion of anything. Think about what's happening there. We're just keeping the low end, so think about like you have a timer that's running really quickly and you see the low order stuff going wild and the high order stuff is slowly implementing, but the low order stuff is kind of chaotic. And if we're just taking that and we're trying to find values that cause something to happen at the low order, we're trying to do a binary search, which is not going to work because if we change this just a little bit there are small changes up at the higher end order stuff, but the low order stuff gets you something completely different. Binary search just doesn't work, and other methods just don't work. We've got this thing that is believed to be hard. We don't have a proof that it's hard, but it seems to be hard. What about some other cases? If y is the unknown, this is also believed to be hard to solve, except if you happen to know the factorization of n it turns out root finding, which again is easy if it's not mod n. It's just finding the x root of z, but if you know how to factor n then it turns out you can compute root’s mod n. I'm not going to tell you how today. I'll tell you how in a month or so if you come back to that session. It turns out it's not that hard. The final one just for completeness, I like to look at this. What happens if n is unknown? There's really not a lot of work there. I've heard of a couple people looking at that. I think it's an interesting problem. How hard is this? I don't really know. It might be worth investigating. Might be able to do something with it. Let's look first at the how do we compute this, y to the x mod n. You might just compute y to the x mod n by taking y to the power x and reducing it mod n. The problem is we like to use for integer operations, integers of at least 2048 bits. That's another group the word SDL requirement, RSA, similar things, 2048-bit minimum. If you have 2048 bit integers, x, y and n are 2048 bits, you raise y to the x power and to get something of about that many bits. Just for comparison, that's how many particles there are in the universe. Storing this number is going to be a problem. [laughter]. We can't come close to storing that value, so we're going to have to find another way. Fortunately, we can be a little bit more clever. We can do this mod n reduction with each multiply. We don't ever let the value get very big. We can multiply and then reduce, multiply and reduce and keep the value from ever getting big. We can solve the storage problem that way, but to do this exponentiation by just doing 2 to the 2048 multiplies, we have to do a lot of them pretty quickly. That's about how many we would have to do every second just to finish before the sun burns out. A good processor now, four gig, 2 to the 32 computations per second, so we're getting there, just a little slow, okay. We want to be able to do our encryption a little faster than this. Here's the trick. Think about how you learned to do multiplication in elementary school. Multiplication is just repeated addition, nothing more to it than that, but you don't multiply 23 x 49 by adding up 49 copies of 23. There are tricks. Basically what you could do is repeated doubling. We work base 10, so we don't do it by doubling; we do it they stand, multiples of 10. It's actually a little bit harder to learn to do it that way. Think of if we were doing everything base 2. To compute x times y what we can do is just compute y -- it's not obvious why I've highlighted a few of these yet, but it will be. Y, 2y, 4y, 8y, 16y and some up whichever of these we need to get x times y. Sorry, I should have mathed this initially, but here's the example. Suppose you want to do 26 y. I really should have this one tilted in a way. I see people are having trouble seeing the things low, sorry. I don't know that there is anything I can do about this at this point. I'll just try to lead and make it clear. Suppose you want to compute 26 y. If we write it out in binary, write 26 out in binary, you find that you need 16 y +8 y +2 y. And I don't know why I made that 2 green, sorry. Instead of doing 26 additions, or maybe 25 additions, you're doing four doublings and two additions and the doublings are additions; they are just easy additions. We save a lot of work. Exactly the same thing can be done with exponentiation. Suppose we want y to the x or we just repeatedly square value and all these things are done mod n, by the way, because we know we want to reduce it mod n, keep a small. Don't use of the universe. So we do these squarings and then we just multiplied together the things we need to get y to the 26 power, so we're not doing 25 multiplies. We're doing four multiplies here, four easy multiplies here and two more multiplies, much faster. If we count it up, now if we were trying to do, multiply 2000 bit, you do and exponentiation of 2000 bit values, then it takes about 3000 multiplications, 3000 ordinary multiplications to do it. Basically, 2000 squarings to get all of the things that we need and about 1000 side multiplications to multiply roughly half of these will have to be multiplied together, depending on the binary representation of this x up here. Make sense? Questions? Okay, good. Great. We can exponentiation quickly. Now let's do RSA. Let's show how we can use root findings to solve the problems that we have here of asymmetric encryption. This is going to be RSA in two slides and it really actually, most of its in one slide but two slides get everything you want to know. I tell you you want to create an RSA key? Take too big primes, multiply them together. Published the product. Tell everybody the product. That's public now. We typically use the x-value, the exponent, 65537. It's two to the 16th +1. It has a very nice binary representation. A 1, a whole bunch of zeros and a 1, right? So we have very few of those side multiplies, a nice little convenience. It doesn't have to be a huge exponent for the encryption. We tell you to encrypt your message y by just taking y to the power x, mod your chosen n and since you know the factorization of n, you can solve this discrete root problem and invert it. You know the factorization of n; you can do this if you don't know the factorization of n, it is a secret. It is opaque to you. That is RSA. Because if you take the x power and then the x route, you get back to where you started. That's all it is. In fact, RSA has another really nice property and this is slide 2 of RSA, signatures. We know that you can encrypt and then decrypt the encryption and get back to where you started, but there's also this odd little feature that you could decrypt first and then encrypt, take the x route and then the x power and you will also get back to where you started. Looks bizarre. Why would anybody want to do that? This is something that nobody else can do, so taking the x root of y effectively serves as a signature on y. It's something that only I could produce, so I have signed y by producing a value which is the x root of y and anybody can verify that signature by raising it to the xth power mod my n and they get y back. That's a digital signature. Great. We got encryption and digital signatures all in one simple thing. Back to our confidential data transfer, our purchase from Amazon. Now we are in much better shape. I want to make a purchase, really, I do. I'm trying. Amazon comes along and says here's my key, now encrypt with that. I send my credit card over that channel. Looks good. Everybody happy? No. Okay. Why not? Anybody want to help? I'm sorry. Try again. Are you sure it's their key, I thought I heard. Yep. That is a big problem. You might have an intermediary hanging out there. It's not just you and Amazon, but there may be somebody in the middle. You start browsing through the Amazon collection and the intermediary intercepts everything and forwards it on and gets the responses and forwards them back-and-forth and eventually, you get to a point where you want to make a purchase. The intermediary happily says, sure, I want to make a purchase, and Amazon says here's my public key, and the intermediary says and here is my public key, but it's different. It's a tilde, a crooked E. Uh-huh. They send back a crooked encryption function and you encrypt your credit card number very dutifully to the intermediary and now the intermediary has your credit card number. And if the intermediary is clever, it will then take your credit card number and re-encrypt it for Amazon so that you get your book or blunder or whatever it is you were trying to buy and you are none the wiser and Amazon is not the wiser, but your credit card number is now in somebody else's hands. This isn't good. So we add a feature, a digital certificate. This is, basically, a statement that somebody has signed saying what Amazon's public key really is. If we have a certificate authority that can do this signature and we believe that certificate authority, then we know what Amazon's real key is. The problem is now we just have bootstrap the problem or put it back down to how do we believe the certifying authority. Baked into our browsers are the root keys of various certifying authorities, so if they're good and they do their job well, then we can trust them and everything is good. Of course, there are a lot of certifying authorities in the browser, maybe some more trustworthy than others, maybe some more careful than others. If you look in your browser you can still find some old keys that have been explicitly disallowed because they were issued by the certifying authority VeriSign to Microsoft because somebody called them up and said I'm Microsoft, please sign my key. Please certify it and they did and nobody at Microsoft seems to know who that person was. Those keys never seem to have shown up, but you have to be careful. Okay, so we've got a cert. Can we do this now? I want to make a purchase. Amazon sends back a public key and a certificate saying this really is Amazon’s public key and now I encrypt. Okay? Are we good now? We're better, but you're wise. You know not to trust a cryptographer. >>: Replay attack. >> Josh Benaloh: Replay attack, perfect, thank you. I'll pay you later. [laughter]. Just give me your credit card and I'll be fine. This seems to work just fine. Here's a perfectly good exchange and somebody overheard this perfectly good exchange. And then later on whoever that eavesdropper was to overheard this goes back to Amazon and says I want to buy some really expensive, something really nice. And Amazon says, okay. Here's my public key and the certificate. And all I have to do is say sure. My credit card number is that thing, whatever that thing that went over the wire last time, yeah, it's the same one. And Amazon dutifully decrypts it and suddenly somebody else gets charged. So we're going to add one more component to this. We're going to add what's called a nonce, which is a coined word from number once. A nonce is just a random value that goes in and it changes every time and you send the encryption of the credit card together with a nonce and the next time Amazon sends it to someone else they will send a different nonce and if the same nonce doesn't come back each time than Amazon will know this is wrong, disallow it. Are we done? We're done to the extent that this is what is done today. I'll show you how. I'll claim it's not good enough, but let's take a look at how this is used today. There is a sordid history of SSL, which probably most people here have heard of and TLS, which probably most people here have heard of, and PCT which is a Microsoft standard which probably very few people here have heard of. The history, roughly, is SSL came out in 1994. It was produced by Netscape. Now, 1994, those of you here who are techno history buffs might recognize as this was the time of the big browser wars. Actually, this was a little bit before they started, but this was still the first salvo, essentially, and Netscape had this nice secure protocol and we weren't going to use, well we kind of had to, compatibility, but we didn't want to be bound to Netscape, so we came out with our own protocol called private communication technology. Part of the excuse for coming out with it was we, and when I say we in this case I mean especially Dan Simon who now works in Windows Phone, I think, found a big bug in SSL2 and we said we can fix that bug. We've got something better and we've got these nice new features and people should be using PCT and PCT was put in browsers and it was default and it was even used occasionally [laughter]. Next year Netscape came out with an improved SSL3, which fixed the bug and was very common. Lots of people used it. It was good and it got some new features. We are still competing with them. We have to come out with our next version, but how are we going to, even though we put in lots of enhancements in the new version, beat SSL3 with our new version? The trick is we come out with version 4. [laughter]. And we put out version 4 which had some nice enhancements and 4 is bigger than 3 so it must be better. And it was enough eventually to bring Netscape to the table in an IETF meeting and we eventually all got together and agreed on TLS which, version 1 existed for a long time. There is now a slightly newer, better version, but still it's a very, very nice protocol. It has a lot of good features. Basically, the way it works, the thing that has made this survive for so long is the handshake. The trick of the handshake is you've got a client and a server and the client starts off with okay. I want to set up a secure communication channel. Here are the protocols I understand. Here are the ciphers I understand. Here are the tools. Here are the languages I speak in some sense. The merchant can go through the list that the client provides. The server goes through and says okay. This one is good enough. I'll take that one. The server gets to choose. Let's use this protocol. Let's use RSA or let's use UCC or let's use Diffie Hellman and let's use this hash function and this symmetric cipher. I don't like DES anymore; I'll use AES, whatever. They can choose. And here is the public key and the certificate and the nonce and then okay. The public key is used to transmit a symmetric key and then all the subsequent communication is with the symmetric key once you've done this exchange. The really nice thing about this is it's very agile. We don't have to decide that next Thursday the internet is going to change ciphers. Everybody has to shut their old cipher down and start using a new cipher Thursday. It's very smooth. Servers can start accepting new ciphers. Browsers, clients can start implementing new ciphers. If they're not yet understood by the servers, that's okay. Eventually, old ones the servers will stop accepting. It's a smooth, gradual process. It's very agile; it's very nice. It's a good way of doing this negotiation and this has allowed this protocol to survive as new primitives, long and old ones lose favor. It works quite well. Once the negotiation is done, you get into the SSL/PCT/TLS record layer which basically says from then on you just use the symmetric cipher with the key that you sent over and you integrity check it with a hash, which I'll talk more about in another session and you wind up with what is sometimes known as hybrid cryptography. We use asymmetric crypto and its nice features for things that we can't do like sending a symmetric key to somebody that I've never talked to before. But the symmetric crypto is much, much much more efficient, so once we've done those things which we can't do without asymmetric stuff, then we do pretty much everything else symmetrically. And we have this hybrid of asymmetric wrapping the symmetric keys were doing the digital signatures and the bulk stuff is done with the much faster symmetric stuff. One thing I haven't talked about much and this is going to be, we're getting close to the end, which is good because I'm getting close to the end of my slides, is authentication and authorization. This is something which has been done woefully badly in the protocol that I just showed you. The reason is when a merchant is on the other end of this conversation, gets my credit card number, does the merchant really know who this merchant is talking to, that I'm the one on the other end? No. Not with basic SSL/TLS. There is something called client auth that can be used, but really never is. All they have is here's my credit card number. Okay. I will charge this person. I will assume that this credit card number is good and go from there. But I am my credit card number effectively. That's really not a really good way of doing things. Does the merchant know that I authorized the purchase? No. The merchant just sees my credit card number coming over the wire. If possession of a credit card number is used as a proxy for identification, then I can be impersonated. My claim is this is the reason for things like the Target reach. People will talk about well, Target had this failing of security, this failing of security. Not. The problem is right here. The problem is Target has data which allows an attacker to grab and impersonate millions of people because all you need to impersonate somebody is their credit card number. If we got rid of that there would be other sensitive data, what purchases I've made in the last year, but people aren't going to go through too much trouble to steal that stuff, at least not as much trouble. The real problem is we built this insane infrastructure in which a credit card is everything and if you have my credit card number you can impersonate me, or other things. Maybe my credit card number and by Social Security number or my date of birth. I can find for probably most people in this room, find your date of birth in less than 2 minutes and your driver’s license number. This is all public data, easily discoverable. It doesn't cost anything. Ask me at the end and if you want I'll show you how to do it. It used to be that your election records in this state, you could change your address with your date of birth and driver's license number. It turns out the driver’s license number in this state is deterministically computed from your date of birth, which is public. That's been fixed a little bit. It's a little bit better now, but not a lot better. I had a discussion with the director of elections a couple of years ago and we agreed. They have now added driver’s license issue date, which is far most people within two months of the expiration, which is on a birthday that is a multiple of five years. There's about six bits of entropy in there, better than nothing. Also, if my giving a merchant a credit card number is a proxy for an authorization, then merchants can cheat all they want. They can say you told me you wanted to buy this expensive thing. You sent me your credit card number, right, so you must have. It's not really authorization. There are ways that we can do better. We could use private authenticators like what people usually do with a bank. My bank and I somehow agree on a password and this password is supposed to not be shared with anybody else, supposed to be. Okay. That can work reasonably well for authentication. My bank can't impersonate me to somebody else if nobody else recognizes that password as having any meaning. It doesn't have any authorization value. The fact that I gave my bank a password and gave it some instructions and it shows this transcript of all these things that happened, doesn't mean that I was really on the other end. I can say you had my password to begin with. You could have done that all yourself. How do you know I was involved in that? And, of course, we all know the usability is horrible with passwords. People can't remember passwords. People are supposed to have individual passwords with many, many different entities, so they wind up having the same password and it just doesn't work well. Biometrics is a possibility. This has some value for local authentication. It's really bad for remote authentication and yet people like to use it for that. You see my fingerprint coming down a wire and you think I must be on the other end as though it's some sort of a secret? I leave my fingerprints everywhere I go. It's not a secret. It's a worse secret than just about anything else you can imagine. But somehow seeing my fingerprint means that I'm there. I don't know. That's really not a very good choice and, of course, biometrics are very difficult to revoke. I'd like to keep my fingers, thank you, so treating biometrics as some sort of secret data is often done and it's a terrible way to do things. It can have value for a local authentication. What we would like to do is the digital signatures. I think we've got like two slides. Digital signatures offer a good authentication mechanism. You can do a lot with them, but you need a public-key infrastructure of some sort to do this. Amazon has gotten a digital certificate on its key. How many people in this room have a public key that has been certified by some certifying authority? Okay. A few, but not many. Until we find a way of getting there, we need the killer app that will cause people to get certified. Some governments are issuing cards to citizens and if you have this and a good way to do this kind of real authentication, then it's great, but until we get there we're stuck with biometrics and passwords and broken systems. Another thing to mention is digital signatures you can do as a human being. You need computational systems, but they can be used as authorization if you do it right. It's more than two slides but these are quick slides. Sorry. Within SSL/PCT/TLS you can imagine you want to make a purchase. You get something that says please sign this authorization and you go and say okay. Here's my signature. Here's my certificate. There are still problems with this. It's not quite this simple. You have replay attacks. That signature could be reused if you don't make sure that it contains data that won't allow it so it should have nonces or something of that sort. There's also malleability issues. Malleability is signatures can be transformed in various ways. Or remember with RSA, signing something is exactly the same as decrypting something. So somebody comes along and says please sign this authorization and what they are really saying is please decrypt this for me. We have to build into the protocols ways of making sure that you never just signed something that you're given, that the signer also has to put something into the thing being signed of the signer’s choosing so it's not deterministic. And there are the human limitations of dealing with just how do you do the computation. People can't digitally signed things without computational assistance. The final thing here is we want to get some sort of hybrid authorization where we authorize a device, our own computing device to authorize on our behalf, but how do we do that? It changes the whole notion. Normally we talk about the protocol, but instead, we should be talking about what a former Microsoft college used to refer to as a ceremony. It's not just you and the merchant involved in the protocol. It's you and your device and your merchant. There's an interaction between you and your device and there's an interaction between your device and the merchant, whether your device is a smartcard or it's your home PC or it's your phone or whatever it is. The protocol is going all through here and there are all these places where there could be a break where this could be a perfect protocol but the interaction between you and your device can be taken advantage of. It should be that when you get to the point that you tell your device that you want to make a purchase and that gets passed on, there's an authorization step here. There's an authorization step here and you can enter something that you can do locally to your device, something reasonably simple. Your device, then, does the digital authorization, but this all has to be taken into account as a whole, not broken up piecemeal. That's kind of an overview of the kinds of things that I'll be talking about. Subsequent sessions -- just when did there, but that's okay. Subsequent sessions we'll be talking about symmetric protocols, asymmetric protocols, the sort of standard integer ones, non-integer ones, especially elliptic curves, lattice space systems, various protocol properties, forward secrecy and then some applications and maybe if people allow me I'll sneak in some election protocols at the very end. But if people want to hear about other things, if people are less interested in some of these things, there are other things, let me know. I want to keep this flexible and tried to find a way to sort of fit whatever people want to hit on. By the way, all of the other sessions, 1927, I apologize for the confusion. I think that must've been my mistake. My office is building 112. My admin’s office is 112. Somehow that slipped in. But we are in 99, but the future sessions will be in 1927. It's a smaller room that way, just around the corner. Okay. That's it. Any questions? [applause]. Seny? >>: You showed RSA? [indiscernible] version of RSA? Are you going to talk about some security at all? >> Josh Benaloh: Yeah. Maybe not in exactly that form, but yeah. The RSA that I showed, nobody in their right minds would use that in practice. You have to be very careful about exactly how you had things in the actual use of RSA and I'll talk about that. Among other things, to make sure that encryption is distinct from signatures and there is no possibility of confusion, but there are a lot of things. The Symantec security that you mentioned is one important aspect of understanding exactly the kind of security that the RSA can provide. I do hope to talk about that as well. Yep? >>: That last example of the ceremony during authorization, is chip and pin credit cards an example of that? >> Josh Benaloh: Yes. Chip and pin does that. Now it doesn't solve all the problems because chip and pin typically the way it's used credit card number still get transferred and maintained, so it's better, but chip and pin, which is done a lot in Europe, and there is now some expectation that they will come to the U.S. But people don't know; basically it's not enough to swipe a credit card, you have to have a pin also. There is a pin on the credit card and the credit card is supposed to engage in a more sophisticated protocol than the usual one of here I am. Here's my number. Anybody want my number? Which is what many of our cards to like our [indiscernible] cards. Basically, you ping them. Here's my information. We want to do better than that. We can do better than that. Chip and pin is a little bit better than what we're doing, but it's not what we should be doing. Yeah? >>: You did a talk about some of the tricks, algorithm in AES. Were you talking about [indiscernible]? >> Josh Benaloh: Yes. Actually, I debated whether or not to put in cipher mode today and I decided we are already over time so I'm glad I didn't. We'll spend plenty of time talking about cipher modes. >>: So we can go until three? >> Josh Benaloh: The usual way this is done is in the hour of talk, plenty of time for questions. We are flexible so, if people would like hour and a half talks, I can talk ad nauseam, I promise. But the tradition, anyway, is it's on the calendar until three o'clock so that there is some flexibility at the end. I'm not going to talk about cipher modes now. I'll talk about them next time unless you really want something, talk to me later. >>: I'm curious. There's a lot of government databases that hold very sensitive information regarding individuals or medical purposes. How good are those? >> Josh Benaloh: What's the quality of medical databases and other similar databases? It's very mixed. Some are pretty good. Some are not nearly as good as they should be, but there are problems as to just what's in there. Usually, there's a lot more in there then needs to be, then should be. Medical databases are kind of an exception because that's very sensitive stuff that really does need to be there for the most part. That's a case where we have to try to be very careful and instead not expose them as much as they tend to be exposed. They need some extra security. As opposed to Target which probably doesn't need the extra security. What they store is only what you bought in the last two years. It's still kind of sensitive, but it's a lot less sensitive than what medical tests I've had in the last two years. There isn't a good answer to that. It's not great. We can talk about some methods that are used, but you probably don't want to know all the details. [laughter]. >>: Actually I do. >> Josh Benaloh: Okay. We can talk little bit. Honestly, I don't know all the details. I know some of, but not all of it. Yeah? >>: [indiscernible] about the exponentiation where you multiply multiple times to go to n? >> Josh Benaloh: Okay. You know what? I'm going to try to do it this way. >>: While Josh puts up that slide, anybody here who hasn't signed that spreadsheet, then on your way out the door please do. >>: It's on the back table now? >> Josh Benaloh: Oh no. I hit the wrong key. I hit F5 instead of shift F5. This one? >>: Yeah. >> Josh Benaloh: Okay. You want to go a little further. >>: Where it was simplified. >> Josh Benaloh: So let's do exponentiation. >>: Yes. If someone knows how many times you exponentiation and how many times you added, is it hard to reach 2n or is it computationally [indiscernible] >> Josh Benaloh: If it's just the number of times, then you are pretty secure, because there aren't that many possibilities. The number of times you -- this is square and multiply here. You are always doing the same number of squares; basically, you should always be doing the same number of squares. The multiplies, the number of multiplies that you do should be clustered tightly around half of the number of squares and knowing that allowed you to actually figure out somebody's key, there aren't that many possibilities you could guess that and try it. The problem though is that sometimes if you are close in you can actually tell the difference. The usual approach is not due all the squares and then do a bunch of multiplies, it is while you are doing it, you square and then multiply or square and then not multiply and if you are not careful in your implementation, then there's a side channel attack and probably I should put on the list side channel attacks, which has been some time talking about some of those. But there's a side channel attack which is just sort of a timing attack or power analysis or listening to, if you can get close enough to a device it can even be done acoustically, listening to it. You can record it and listen and tell the difference between a multiply and a not multiply and that way you get the bits of the key one at a time. That would be very detrimental, so we are very careful in our implementations. One of the reasons you should use the Microsoft internal approved implementations and not roll your own is we're very aware of side channel attacks and try to build in as much resistance as we can. Anything else? >>: If you go back about two slides to the slide that had the 2048 on it. This one I thought when you said the crypto board recommends that all three be 2048 signatures. Is that what you said? Is that what you said? One of those everybody uses 65537 and so can you explain that? >> Josh Benaloh: These two need to be 2048 bit. Sorry, not these, these two. >>: [indiscernible] 65537. >> Josh Benaloh: It's n that's important here. Y is the message, so y will be padded separately. It's just a message. The message means that the computations will be done on 2048 bit values. It's just how many competitions and it turns out that with RSA as long as you're a little bit careful about a small exponent seems to be just as good as a large exponent. You get some interesting effects out of this and it's worth mentioning. This exponent is going to be public anyway, so you're not hiding anything by, or revealing anything by using this special form. The question is, does it make it easy to attack? It turns out that if you want something that is of this special form 1 all zeros and a 1, there are very few possibilities that meet all of the requirements. Three actually does, but there is some reason not to use three. There are some attacks on very, very small exponents if they are used carelessly. Basically, you could get something that doesn't get large enough to wrap mod n and if you had very badly and you just use raw RSA, you don't wrap mod and, then it just becomes taking cubed roots. So we want something that small, has this structure and sort of 65537 has turned out to be the perfect value and virtually everybody uses it. It leads this interesting asymmetry in asymmetric encryption with RSA that encryption is much, much faster than decryption, a couple of orders of magnitude faster. Verifying a signature is much faster than signing something because the verification is with a small exponent. The decryption which is root finding is, it's also just an exponentiation. It just turns out to be a large exponentiation. You use a full size -- and that case the exponent becomes 2048 bits here. You wind up encryption and decryption are using basically the same function, but the exponent is much larger for that secret operation and therefore, encryption is fast; decryption is slow. Often you can use that to your benefit. Sometimes you wind up on the wrong side of it. You end up with a weak client having to do the expensive operation and that's a nuisance. We try to formulate things when we can so that it's the other way around, but we can't always do that. >>: Will you be going into this in a lot more detail on your third talk? >> Josh Benaloh: Yeah, the third talk is when it's most likely. Yep. And I do intend on showing you how we compute these things. If you like math that's the talk to come to. Anything else? Okay. Thank you. Be sure to sign the sheet if you want a chance at the trinket. [applause]