As you can see, I fell straight into Troy's trap of using bits and things on the background with the bluish color and everything. But this time it actually makes sense. I don't have a hoodie though.

But this time it actually makes sense because I'm going to play with these things. I'm going to play with numbers and letters. So you'll see. The point of this talk is to talk a little bit about crypto, show some of the problems that you can run into if you're using crypto the wrong ways and hopefully you'll know what to do later.

This is me. My Twitter handle, email address is not there right now. I'm not a cryptographer and I'm no crypto expert either.

But I've worked quite a lot with testing and I've uncovered quite a few crypto flaws in applications. So that's sort of the background here. The worst thing that you could ever do is to invent your own crypto.

And look what Bruce Schneier says here. Anyone from the most clueless amateur to the best cryptographer can create. Even the best cryptographer can create something that he himself cannot break. But that doesn't make it secure. Because the way we build crypto algorithms is that someone makes one and someone else tries to break it.

Because they will think differently. So that's why you should never ever invent your own crypto. Just be warned. Before we begin on the actual topics, I'd like to show you one thing that I need to reload. Because obviously I don't have internets here right now and I'm going to need that later.

And I see that Mr. Niall up there is running some funky business here as well. So that's always nice. If you want to see something funny, go check the Wi-Fi. Hopefully I will connect and then my VPN will come up and running.

And then I won't be in Niall's lair any longer. What I'm trying to show you here is something called CryptoPALF. This is a set of tasks that you can do. And you have to program, by the way. This is a set of tasks that you can do. So there's one set that starts with the basics and there are some tasks.

And then you can sort of work and become more advanced as you go. So I really recommend this site if you want to try any of the stuff that I'm showing today. I've also created this stuff. This is just to make it easier to actually hack on crypto stuff from the browser.

Because I'm going to do that in the demos. And that's just so I can do something like this. So I can do key equals array random bytes 16. So I want an array of 16 random bytes and I'll get something like this. And then I can take the plain text that I have up here, create a byte area of it,

XOR it with some key and then encode it as hex. Same thing, I can decrypt it by doing something like this. So it's just to make it easier and not have to write as much code all the time and repeat the same things all over. So you can find this on GitHub. So let's start.

These are some of the words I'm going to use. So plain text, that basically means the data that we're going to encrypt. So that can be a file, it can be text, it can be anything. Cypher text, that's the encrypted data. And then we have a key and we use this key to encrypt the data, obviously.

Or we could use it to sign something. We have something called IV and nonce. Those are usually random values. And we use them to make sure that if we encrypt the same thing twice, we don't get the same output, basically. We'll get back to that, so we'll see how it works.

And one important thing to see here is that a nonce is a random value only to be used once. That's quite important as well. We have symmetric encryption, where you use the same key to encrypt and decrypt. So basically if I'm going to send you a message, we both need to have the same key. Then there's asymmetric encryption, where you have a public and a private key.

So I can encrypt something with your public key, but you're the only one who can decrypt it, because you're the only one with the private key. Just to set the stage here. So what we want out of cryptography might be one or several things.

And sometimes we think we're getting more than we're actually getting. This will typically be we're encrypting something and we think we're getting integrity, but we don't. And I'm going to show some examples of that. But confidentiality, that's just I'm going to hide my data so no one can snoop on it while it's transferred over the wire,

or while it's sitting on my disk or whatever. Authentication or integrity, that means that no one has tampered with the data. So we can have integrity without confidentiality. I want to transfer something to you and anyone can see it, I don't care, but I don't want anyone on the way to be able to change it. And identification, that's typically something we get from signing something.

So if I sign something with my private key, I prove that I'm me, and then you can verify that with my public key. So I want you to look at the dates here, or the years here. This guy died in 1903, so this is quite a while back.

And he said that a cryptosystem should be secure, even if everything about the system except the key is public knowledge. So if you're inventing some kind of crypto stuff at your office, and if someone should see the algorithm, then it would fall apart, then it's not really crypto. Because the system itself, you should be able to publish that,

everyone should be able to review it, but the key is the thing that keeps things secure. So, the first thing we need to talk about when it comes to encryption is entropy and randomness.

Because a lot of the stuff that we're doing is dependent on someone not being able to guess the key, or not being able to guess something about it. When we're building a password, we're basically trying to avoid that someone can guess our password. And when we're creating a crypto key, it's even more important that that key is secure.

So it needs to be generated by a secure random generator. Not something like this. Humans or trolls are probably not random either. And this is actually true, you could get 999, because if it's true random, then there's...

You don't know. But that's the thing, it can be kind of hard to know if something is random. And there are tools that can help you with that. For instance, if you're running burp-suite and you want to test your session IDs, you can get it to give you an estimate of the entropy. One interesting thing that I've run into is I tried to deploy an app on Docker, on a host that I was running on.

And this was a Java app, and it was compiling, and it was starting, and then it stopped. It never started, never got to the point where it was actually starting and listening for HTTP connections. And I was wondering, what's going on here? Why doesn't it start? And the reason it didn't start was because it didn't have enough randomness, it didn't have enough entropy.

Because the OS provides entropy to Java or to .NET or whatever you're running, it provides entropy. And it does that by looking at properties of the system, things like temporary files, CPU processes, etc.

And if you're starting a brand new Docker container, there's very little things going on in there. There's nothing in the temp folder, there's very little things in there. So I actually didn't have enough entropy to generate a single session ID. So in this case you have to sort of pass the random from the host OS and into the Docker container to give it random.

Gunnar Allendahl and some of his co-conspirators on this one, they recently did a check on these self-encrypting hard drives. So basically you can buy a hard drive, you plug it into your USB port, it mounts as a CD and you run some kind of application.

And then when you enter a password into this application, it will unlock the drive so you can see your encrypted content. And they wanted to see, well, how secure is this really? And one of the things that they found was that for one of these chips that are used in these drives,

if you grab a single sector of the hard drive, you can deduce the crypto key because the randomness is so poor. And this will typically happen in all kinds of devices. Think all these IoT devices that Troy talked about, like these light bulbs. There's very little going on in there, it's basically just running a light bulb.

So how good a random can you get? Now, some people have tried different ways of getting more entropy in a way that it's really hard for an attacker to find out. One of them was putting a lava lamp in the server room and then having a webcam pointing at it and using that as entropy.

Someone tried to use the chip of a digital camera and put it in a dark space and then use the noise from the chip as entropy. Because that's really hard for anyone outside to know anything about. But don't ever use like math random or something like that.

Use the secure random provided by the paper or you might end up like this. But even if we have really, really good keys, this is sort of what we've been thinking recently.

Like, well, we have all these keys and we have all these stuff and it's really, really secure. And then Snowden came along and showed that, well, everyone's being monitored and then, well, we need more encryption, obviously. And the problem is often not the crypto itself. The crypto is good, but there's something else, like either the human or the implementation of the crypto is wrong.

So, let's say we want to encrypt something, I want to send something to one of you. And I want it so that no one else can read it. So, given a ciphertext, given an encrypted text, it should be impossible to find the plaintext.

So, let's start there. What we could do then is to do something like this. We could use what's called a one-time pad. So, we generate a random key and then we XOR the plaintext with this key. And to decrypt, we once again XOR it with the key.

Because of the way XOR works, we get the original back. So, we have something like a secret message. These are the ASCII values of these characters in hex. And we generate a random key and there we have a ciphertext.

Is this any good? Well, let's just look at what happens here. If we're going to XOR bytes, we can look at them at the bit level. So, if we look at a capital A and lowercase a here, we see that the only difference is this thing. And coincidentally, that's actually the space character.

Or it's probably not a coincidence. So, actually if you do A XOR space, you get a lowercase a. And it also works the other way around. Like if you have a lowercase letter and you XOR it with space, you get the uppercase letter. It even works for those crazy Norwegian letters. So, that's basically the way XOR works.

And of course, if you have a value and you XOR it with a 1, it becomes the opposite. So, if A is a 1 and you XOR it with 1, you get a 0. And if it's a 0 and you XOR it with 1, you get a 1. And if you XOR it with a 0, you get the same value back. And if you XOR one thing with itself, you get 0.

Because we just flipped a bit there. And it doesn't matter which direction you do this. You can even move things around. So, if you have something where A is XORed with C and A is XORed with B, that's actually the same as A XORed with A and B XORed with C. And of course, this we know is 0.

So, A XORed with C and A XORed with B becomes B XORed with C. And this is actually quite important. Because the one-time pad that I just showed you, where you generate a key and you encrypt it and then you're done.

That actually works really well for a single message. There are some problems though. We can only use the key once. How do we exchange the key? I mean, we both need to have prior knowledge of this key. And because the key length needs to be either the same as the message length or longer,

we have the same problem all over again. If I want to exchange some confidential data with you, I first have to exchange the key. And that's actually the same problem as exchanging some confidential data in the first place. So, this doesn't really work. But the reason why this is very secure is, if we have a set of letters and we have a one-time pad,

then depending on the key, that message can be anything. So, it could be a secret message, but it could also be hello world. Because it depends on the key. So, as long as we only have one single message, this is quite secure. But, don't do it. So, why can we only use this key once?

Well, we have one plaintext and we excerpt with the key and we get the first ciphertext. We have a second plaintext and we excerpt with the key and we get a second ciphertext. But if we excerpt those two together, the key goes away. And we now get the first plaintext excerpt with the second plaintext.

So, the key has disappeared. And, of course, also, if I know a single plaintext and a single ciphertext, I can now get the key. I've added some links down here on some of these,

just to point you at the actual challenges on CryptoPals. And the interesting thing here is, if we have a lot of messages encrypted under the same excerpt key, we can just do statistical analysis on each letter and then we can find the actual key.

So, this only works for a single key. So, if you wanted to use this, you would have to exchange, meet face to face first, exchange a list of excerpt keys and then you'd have to know which one you're using at each time when you're exchanging messages with someone you know. And, of course, it is kind of a problem that the message length either needs to be the same or less than the key length.

That's usually not a very nice property to have when we want to do encryption and we want to encrypt large stuff. So, if I want to encrypt a two gigabyte file, I need to have a two gigabyte key. That doesn't make sense. And there's some interesting stuff as well. Usually, when we're trying to attack crypto, we do something called the chosen plaintext attack.

That's one of the things that we can do. So, if we can supply a plaintext of our choice and send it to something that will encrypt it for us and then we'll get to encrypt the value back, we could just encrypt some nulls. So, if the plaintext is null, the key will come back.

So, there's an attack as well. So, these keys can only be used once. Well, do people actually do this? Well, yes, they do. There was recently an app called NqVolt and it was to encrypt files on your smartphone. The problem with it was actually that it only encrypted the first 1024 bytes because that was the key length.

And this app has less than it should have said, over 30 million users worldwide. And it uses XOR with the same key for all files. And this is the way they build the key.

The password.hashcode and then they XOR it with 1111111, so they basically flip it. And then that's the key. So, that's not a good way to do crypto.

So, let's try to redefine this a bit. So, we still want it, if we have a ciphertext, it should be impossible to find the plaintext, of course. That's the basis of confidentiality. And I'm saying impossible here, because there might be other ways of doing it, like showing up at the wrench. And we want to have a reusable key, like a key that we can use for more than one encryption.

And, of course, knowing a plaintext and knowing a ciphertext should not reveal the key. Because then we can't use the key anymore. Because sometimes you can guess the contents of a message. Like, if it's an HTTP request, you know that a part of it is going to be like get slash HTTP 11 etc.

So, you know parts of it already. And we don't want that knowledge to help us reveal the key. And, of course, we want the plaintext length or the message length to be able to be a lot larger than the key size. There are basically two types of ciphers that we can use.

The first one is called stream ciphers. Stream ciphers, they take a single key and they generate a key stream. So they kind of expand the key into something huge. And then you can actually use XOR or you can use some other way to encrypt the message byte by byte.

One example of such a stream is RC4, which you should not use anymore. It's been banned from modern browsers now, I think. And because it has something called a bit bias. And a bit bias basically means that a 1 appears more often or more seldom than a 0 in a certain location than it should.

And that's enough for cryptographers to actually be able to decrypt the message. So the stuff that comes out after we encrypt something, it needs to be random. And if we change a single character, the encryption needs to change dramatically. We have the properties here that we can have a plaintext length that's a lot longer than the key size.

But still, one of the problems with stream ciphers is that it leaks the plaintext length. And you can mitigate that, of course, with padding or nonce or something. But it does, because that's the way stream ciphers work. So one example here, let's say we have some secret votes.

And we don't want anyone to be able to see what the others voted, even though they get this data. So here I've encrypted yes and no under the same key with RC4. And it's pretty obvious who voted yes or no, because we have 4, 4, 4 and 3. So this one is shorter than these, so this one must be a no, and these have all voted the same thing.

But what if we encrypted them with individual keys? Well, we still have the same problem, because this one is 4, 4, 3, 4. So it still kind of leaks some information. So we would have to pad it in this case, like add some data at the end to make sure all messages have the same size.

What we could use instead, we could also use a block cipher. And block ciphers are pretty common. That's usually what you will use if you're encrypting something, if you're using the standard APIs. And you'll typically use AES.

AES is a very good cryptographic algorithm that at this point is still considered secure. So what we do then is we split the data into blocks of a given size, and then we encrypt each block. I wrote separately here, and that might be a mistake, as we'll see.

DES is also a block cipher, but you should not use that anymore. Probably not triple DES either. One thing to note here, by the way. Triple DES was used in the Adobe breach that Troy mentioned. So all the passwords in the Adobe breach, they were encrypted using triple DES.

And as far as I know, no one has been able to crack the key. But they were able to crack all the passwords. Why? Well, because the password hints were not encrypted. And if the password hint is Adobe x2, then you know what the password is. So someone actually created a crossword puzzle that you can play online,

where you get a list of password hints, and you're going to try to guess the password. So basically you shouldn't encrypt the password, you should hash them. Like using scrypt or bcrypt or pbkdf2. But I'm not going to go into that right now. So how does this look? Well, we have our plaintext, we split it into three chunks.

We pad the last one, so they're all the same size as the block size that we need. So this could be AES, the encryption using the key K. That could actually be AES. So we split it, we pad the last one. And we can encrypt them individually, or we could do this in parallel.

And then we have the ciphertext. And we want to decrypt them, we once again split them to the block size. We run them through the decryption function. We remove the padding, and then we have the plaintext back. Very easy. The problem with this mode of operation, where we're encrypting one block at a time,

is that if two plaintext blocks are equal, then the ciphertext blocks will also be equal. And the best way to show this, is this picture. So here they encrypted the Linux penguin using EZB. And then they tried to uncover the image without actually knowing anything about it.

And even though the colors are pretty off, we can still see what the picture contains. So we need some kind of randomness, we need to introduce some kind of randomness. This is basically the same reason why we need to have salt when we're hashing passwords, right?

This doesn't work. If we encrypt the same thing, we get the same ciphertext. So we could do something like CBC. In this case we start once again by splitting our plaintext and padding. And then we introduce the IV. And what we're going to do with the IV, is we're going to XOR it with the first plaintext.

And then we're going to encrypt that. And then we take a copy of this first ciphertext block, and we use that as the IV for the next block. So all the blocks are basically now depending on each other. So now we can no longer do this in parallel. We have to first calculate the first one, then the next one, then the next one.

And then we have the ciphertext. And what we normally do then is we combine the IV with the ciphertext and send that across the net. Because then you need the IV to be able to decrypt it, and the IV can be public. But the IV needs to be random. You should never ever use a static IV. You should consider the IV a nonce, basically. So when we want to decrypt this again, we split it out, we grab the IV.

We decrypt the first block, then mix it with the IV, and that gives us the first block of plaintext. And then we continue doing this. All the way down until we get the plaintext, we remove the padding, and we have the actual plaintext back. So of course this chain could be huge.

And this could be annoying. Let's say you're working on a 2GB video file and you change something at the start of the file, then that propagates throughout the file. Let's say you've encrypted your file system on your hard drive using this, and then a small change to any file would propagate throughout the rest of the disk. But let's not go there right now.

But we can try to attack this. So let's consider this. The top here we have the I's, that's the IV. And then we have the ciphertext over here. And now we're going to try and decrypt a single block, but we're going to tamper with it. Normally this IV would go down, be excerpted with whatever comes out of the decryption function,

and we would get this result at the end. But if we change one of these values, the way that these encryption functions work is that that will affect all of these. And when this is excerpted with this, that will of course also affect all of these. So a single bit change up here would change all the data down here,

because we have a good encryption function. So any small change will propagate throughout all of it. But what happens if we change the IV? If we change this guy? We only affect this one. Because that doesn't go through the encryption function,

it just goes on the outside and is excerpted. So a change there will be excerpted with the V3 here, and we will change the outcome here. So what can we do with this? Well, it's become quite popular these days to have client-side cookies,

or client-side sessions, I mean, in cookies. So maybe we have an encrypted cookie that contains user ID 5. So we take this JSON, we encrypt it, and that's our cookie, and we pass that along all the time. And because no one knows the encryption key, no one else can create a valid cookie, that's what we're thinking.

And no one can change it because it's encrypted. And we forget that encryption in this case only gives us confidentiality, it does not give us integrity or authentication. So what happens if I now should change the 11th byte of the IV? I would end up changing this thing.

And that's what I want to do. So we need to remember some of the XOR stuff. And the 5, the character 5, that's 35 in ASCII, or hex ASCII, and 1 is 31. So if we have that, the I11 excerpted with the V11 becomes a 5.

We could start like, OK, let's excerpt with a 35 on each side, then it becomes a 0 on this side, and we have the 35 here. Then we XOR with 31 on each side, and that becomes this thing. And then we can rearrange it a bit, because we can't change this thing.

We can't change the V11 here, because that's going through the encryption function. We can't do anything with that. But we could actually modify the ID. So we could set it to what's here. So we XOR it with the letter that we expect to be there, and then we XOR it with the letter we want. Because if we XOR with the letter we expect to be there,

it becomes 0, and then we XOR with the letter we want, so we get back a 1. So let's actually try to do this. So I'm just going to bring up a small little application that I have running here. Yep, it's this one.

So I can click the login button, and I'm logged in as Homer. But I don't want to be logged in as Homer. I want to be logged in as something better than that. So I'm going to now grab my beautiful little code from GitHub, if only I can find it up here. This thing, because that's going to help me.

I'm just going to paste that here. And now I want to change... Well, let's look at what's going on here. We have a cookie here, and it looks like this. Session 2, and there's this long, weird value here

that looks very much encrypted, and what can we do with this thing? Well, let's try. First of all, this site is stupid enough not to use HTTP only on these cookies. So we can also get it here, and then we can do split on the equal sign,

and just sort of grab that value. So there we have the value. And of course, this looks pretty much like it could be base64 encoded. So let's try to base64 decode it, and create a byte array of the result.

So here we have all the bytes after decoding, and these are all the values. So probably the first part is going to be the IV, the second part is going to be the ciphertext. So I'm just going to pick a random, and it's not so random because I've done this demo before,

but let's put this in like this, and I'm going to change, I'm going to see, like the ninth letter in the IV is a 59. So let's just try to change it to 60, and see what happens.

And of course now we need to pack that back into the cookie. So I'm going to do document cookie equals, and then it was session to equals. And then I take A, I convert it to a string, and I base64 encode it.

And I need to give it a path because that's where these cookies are. So hopefully now I was able to change that cookie here.

So let's see now what happens if I refresh. Oh, it no longer says Homer, now it says Omer. Hmm, interesting. What can we do with this? Okay, let's try to become someone else. Who do we want to be? Of course the admin. So I'm just going to run this again so I have all the functions available.

And I'm going to grab the current cookie. So I have that here. And I'm now going to change, so I'm going to say, okay the ninth letter was obviously now an O. So I want to change it from the O.

So I exhort it with the O, and then I'm going to exhort it with the letter I want it to be. And the next one, that was also an O, and I want it to be a D.

The next one was an M, and that's fine because I want to be an admin. So M is also the third letter of admin. So I'm going to go to the twelfth one. I'm going to change that from E to I. And I'm going to change the last one from R to N.

And then I stick it all back in the cookie, hopefully. There we go. And let's see what happens if I refresh.

So, we now clearly see that just encrypting something does not give us integrity or authentication. It just gives us confidentiality. We could also do this in another way, which is also quite typical.

Let's see, it's this one. So we have this link for a paper, and it says the next one will be released in a week. And if I click this one, I get some kind of paper here. And if we look at the link of this thing, let's see if I can take it out of full screen mode here for a second.

Actually, I'm just going to copy this link and paste it in the console because that's already magnified. So we see we have paper one, and we have some kind of signature, and this one looks hex-encoded. There are no capital letters here, and those kinds of things.

So if I were to try to just open paper two, for instance, it wouldn't work, but I could actually modify it here. Once again, the same way as I did before, and be able to read the next paper. So now we see that the integrity is off.

But I never really mentioned what we're doing when we're padding the last block. So basically, we fill the last block with some data, and there are many ways of doing this. We could do a zero padding. When we do a zero padding, we just add zeros. But we also have to add a length, so that when we decrypt the message, we know how many of these to remove.

We could add some random values. Once again, we need to have some kind of length indicator to know how many of them we should remove. But then there's something called PCKS7, which is a very common form of padding. And it basically looks like this.

So if we have a block where the plain text length is 1, then we add 77777, if the block length was 8 in this case. So the number that we add is the same as the number of bytes we add. So basically we can read the last one, and that will tell us how many of these we should remove. And if we happen to end at the exact boundary of a block, we have to add an entirely new padding block.

Because otherwise it wouldn't know if this last byte here was a padding byte, or if it was a plain text byte. So we add an entire block in this case. This is a very common form of padding. And frameworks tend to react to this if we mess up the padding.

So in this case we're saying that this should have a padding of 3, if we look at the last one. But then there's a 10 and a 5. And what these frameworks will do then is typically they'll throw some kind of error. Like a bad padding exception, or a cryptographic exception. Padding is invalid and cannot be removed.

Or even more generic, just a 500 internal error. So alright, let's just see my nice little application here with the papers and all. So, what happens if I were to change this? I'm gonna just do this from here, because the address bar is too small.

I'm just gonna go ahead and change the last from a 2 to 1. Uh oh, it says decrypt file, bad decrypt.

There's some kind of error message here. If we look at the network and we rerun it, we should see... It gives us a 500 error. So okay, it actually leaks if we have a padding error. Alright, is that a problem?

It can be. So, consider this. Once again we have the same application, we don't know the value that comes out here. We have no idea what comes out here. When we send this message in, it gets decrypted, it becomes something. And of course, the plaintext, we have no knowledge about that. All we know is the IV and the ciphertext.

However, if the server leaks the fact that the padding was wrong, we can actually use that to decrypt this. So, we first take a copy of the original IV up here.

And then we generate an entirely new random IV, and we stick that up front instead. And what we're going to do now is we're going to change the last byte of the IV, because we know that's going to change the last byte of the plaintext.

So we're running some requests, we're changing the last byte, as you can see up there. And we're making a lot of requests to the servers. This is quite a noisy attack. We're trying to figure out when we get a 1 at the last one. Because if we get a 1, then the ciphertext will be valid.

Now we know that this is a 1, because now we didn't get a padding error anymore. Now we got another error message. We didn't get this padding is invalid or not can be removed. We didn't get the 500 message, maybe we got a 400 instead. So now we know that with this IV we get a 1 down there.

And then we can calculate the last byte of this value that comes out of the decryption block. Because we can just XOR the 1 with the IV and that becomes CB. So CA XORed with 1 becomes CB. And because we have the original IV, we can now find the first byte of plaintext.

Because all we have to do is we take the IV and the 1 and we XOR with the original IV. Or actually we can just use CB and XOR it with 1 and outcomes whatever we want. Now we know the last byte of this block, it should now be a 1.

And now we can repeat this. So we change this to be a 2. And we're going to try to break the next one. Because it's going to be wrong if it's 23 or 25 or 2FF. But if it's 22, then the padding is valid again. So we modify the IV up there so that this one will become a 2. And then we try to change the next one.

So once again we're making a lot of requests to the server. And then we keep doing this, like okay we found the next one. Now let's put the previous 2 to 3. And then we're going to try to break the third one to get that to be a 3. And we keep going like this. So now we've seen down here that the first bytes here were obviously 333.

So that was the padding. And now we're seeing the message. And this is interesting, because in the movies when they're hacking stuff and they're trying to get the password, they always get one letter at a time. And this is exactly what happens. I've always laughed at that from the movies. Like oh well it doesn't work like that.

When you try to guess the password you try to guess the whole thing. But no, it actually works like this. So now we actually got to decrypt the message just because it was leaking if there was a padding error. And we made 1969 requests, or basically 124 requests per byte that we decrypted.

So once again this is a very noisy attack. And we can actually do this from the browser if we want to. So we have this thing here. And I'm going to go ahead and copy in my code again. Just because that makes things easier.

And we're going to try to attack this thing. I'm not going to do the entire attack because it takes quite a long time to run it. And I'm going to use a little tiny cheat sheet that I created here.

So, we're going to grab the signature, or signature as it's in this case. And we're going to actually create, or we're going to make a copy of the IV.

And a copy of the cipher. So we just decode it and we grab the first 16 bytes, and that's the IV. And the last 16 bytes, that's the cipher. Then what we're going to do is we're going to create a copy. Or actually a random IV.

I just called it IV copy. So create a random block that's very different from the original IV. And then I'm going to start at the last byte, which is index 15. It's the 16th byte, but it's index 15. And I'm going to try to break this thing.

So what I'm going to do now is I'm going to run a for loop from 0 to 256, or 255 really. I'm going to set the 15th byte to I, so it will go from 0 to 255. And I'm going to try to load that as an image.

Just to see what happens. So we get a lot of errors, like 500, 500, 500. But somewhere in this forest of 500s, there should be a 403. There.

Because now it managed to decrypt the message, but the contents were wrong. So this one is different from all the others. So this is actually something we could do, just from the browser, just attack this thing. And what we would learn then was that the signature is in fact just the name of the file encrypted.

So as long as you're leaking the padding, you can decrypt the message. I know this is quite heavy. There was a bug in ASP.NET some time ago, where you could actually use this to download files.

You could even use it to download web config. Because you can even use this thing to encrypt data without having the key. Because when you have the ciphertext, you can change the encrypted data. So you can use this to download any file. You can download the web config through these AJAX helpers, basically.

And there was an attack on SSL recently called Poodle, which is padding oracle on downgraded legacy encryption. And padding oracle, that's actually the name of this attack. So a padding oracle is something that reveals whether or not the padding was wrong.

So this is a typical thing that can happen if we're using CBC. So how do we stop the padding oracles? Well, we could try to do something like this.

But I want you to tell me what's wrong with this. So we're attempting to decrypt it, and if we get a padding exception, we also return not found. So we return 403 in both cases, right? Now we've foiled these evil attackers.

But you could do a timing attack. Because if it fails to decrypt, it doesn't look up this in the DB. It doesn't do anything more. It just jumps out here and goes straight down here. So there might be a timing difference between if we go from here to here or if we go from here to here. So we might be able to separate the two. So this is wrong.

And there are many types of these side channels, as we call them. Troy actually showed one of them for these bcrypt passwords, right? If you entered a correct username but a wrong password, you would get a long response time.

But if you entered an incorrect email address, you would get a short response time. So that's also the same kind of thing, really. But for real cryptographers, they do all kinds of crazy stuff. They look at the CPU usage. So if you're running on the same VM, or even in a separate VM but on the same host, you might be able to figure out what kind of keys the other processes are using.

There are power consumption, like you draw more power if you're doing this thing than this thing. Electromagnetic leaks, all kinds of stuff that you could use to find these kinds of side channels that can help you to decrypt the message. Just by observing the state of this thing when it's decrypting messages.

So we could do something called encrypt then sign. What we do then is basically we encrypt the plaintext and we get the ciphertext. Then we sign the ciphertext. And then we send the signature and the ciphertext to the other side.

And this thing will actually look at it and verify the signature first before ever attempting to decrypt the message. So if the signature fails, it will not try to decrypt it and thus we will have removed the padding oracle. This is an okay construct that many people use and it works pretty well.

But it is important to check the signature first. And there has been mistakes made here in different kind of crypto libraries where they actually decrypt and then check the signature and then of course all the bets are off.

There is also something called authenticated encryption. So now we can encrypt something and get integrity as well. To do that we use an encryption function that creates a MAC or a TAG as a part of the encryption. So now we have something that provides both integrity and confidentiality.

Examples of this are AES-GCM or AES-CCM. So instead of using AES-CBC we could use AES-GCM. And those are both built on something called the CTR mode. The interesting thing about this one is that we are no longer encrypting the plaintext, we are actually encrypting something else.

So in this case we choose a nonce and we have a counter and for each block we increase the counter by one. And we concatenate the nonce and the counter and we encrypt that and that becomes a keystream.

And then we XOR it with the plaintext. So we are basically building a keystream from a block cipher. The problem here is what happens if you use the same nonce twice? Well the output of the encryption will be the same, so the keystream will be the same.

So it's super important if you ever use GCM or CCM or CTR that you have good random on the nonce. If not, well then we are in the same problem that we had earlier. You can XOR two things together and out comes basically the two plaintexts XORed.

This is how GCM looks, I am not going to go through it. But you see the construct that I just showed you is up here where you take the counter, you encrypt it and you XOR it with the plaintext and you get the ciphertext. But then you take the first block and you do some magic with it to get what we call the authentication tag, which is essentially the signature or a MAC of some kind, a message authentication code.

So that's how we can build that from construct that we already have. So, nonces must be generated by secure random and they can only be used once.

If we look at asymmetric encryption, we have many of the same problems that we talked about earlier. For instance if you are using 2048 bit RSA key, you can only encrypt messages that are shorter than that.

So the way that we usually use these things in HTTPS for instance is we generate a symmetric key, we encrypt that with the RSA key and then we use the symmetric key to encrypt data. And symmetric keys or symmetric ciphers are often a lot faster than the asymmetric ciphers as well. So when you are doing HTTPS, you are contacting the server, it generates this session

key and encrypts it with a certificate or actually you create it and send it. And that's the thing that's being used from then on. And there are different ways of using RSA. And notice here we are talking about padding once again.

So the same guy who discovered the attacks on CBC or at least wrote one of the first papers about it called Bleichenbacher, he also discovered that this works on RSA if you are using what's called version 1.5 padding. So there is a different padding here which is optimal asymmetric encryption padding which is safer.

So use that one instead. Now we've talked about how to get confidentiality but we want authentication as well. So we want to sign stuff. So don't invent your own signing. Use something that someone else has created.

So this I've seen many times. You take a secret and you take the message you want to sign and you use like MD5 or something on the outside. And the thought here is that because no one else knows the secret, they can't do this. This is a secret construct. But it's broken. And it doesn't matter if you use MD5 or SHA-256, it's still broken.

And also if you append the secret at the end instead of prepending it to the message, it is still broken. The reason why it is broken is something we could see from a bug that was in Flickr's API in 2009, which was discovered by Thaidung and Juliano Reso.

And they used something called the length extension attack on this exact construct with MD5 secret plus data. What they discovered was that this was the way that Flickr was building the signatures. So you take all these URL parameters and you remove the equal sign and the ampersands

and you just sort of mash it together, you put the secret in front of it and there you have a secret. And you do the MD5 of course on top of that. The problem was it couldn't separate between this one and this one, because it was stripping out all the equal sign and ampersands. So this one would have the same signature as the one at the top.

And the way this works is this. Let's say we have some kind of a secret, that's the purple thing here, and then we have some data, that's the blue part. And we have this yellow thing here, that's called the S-value, that's the start value for the MD5 algorithm. So once again we sort of split this thing and we have to pad the last block out to the block size of the hash function.

In this case it's not using PKCS7 or something like that, it's using some zeros and some length and something like this. By the way, it says MD-based algorithm, so this is also valid for SHA-1 or SHA-256.

So we split it into blocks and we run the function first with the S as the start value and we merge it in. And then we take the result of that and we run it again. And we sort of use the previous result as the start value for the next, much like we did with CBC.

The problem is, what happens if someone tried to hash this thing and then wanted to have some data at the end? We have this part, that's our value, that's the value that we've gotten but we don't know the secret.

But if we wanted to hash this thing, we can now skip the first steps because that's already been done for us. So we could now add stuff to the end and get a valid signature without knowing the key. So that's what happened in Flickr.

So use an HMAC instead. HMAC is a secure construct, it's even still quite secure if you're using HMAC MD-5, because it doesn't have the same weaknesses as regular MD-5. But we could also sign with a private key.

And this also provides identification, because if I sign with my private key, no one else could have signed with that key and thus you can know that it's me. We should use a proper signing function here, not one with a broken padding. But let's look at how this works with XML, because that can be quite interesting.

So this is the XML that we want to sign. We have a username and we have some login time or something, and in this case we're only interested in signing the username. And XML signing, it works like this. Big chunk of XML.

And the interesting part here is that there's a reference in the middle here that points to hash underscore zero, and that's the idea of the thing that we want to sign up here. So to briefly explain what it does, it hashes the tag and it does some transformations, because XML can be in many different forms. It hashes it and then it creates a signature on top of that.

So it only signed this piece of information right now. So what happens if we have some code that looks like this? There's a huge flaw in this code. Who can find it?

What happens if there are no signatures? It just skips this for loop altogether. So we'll never throw the security exception.

Okay, interesting. But this sounds kind of weird, doesn't it? Like, who would do that? Well, there's a guy called Juraj Somorowski. He found this bug in SAML libraries. So the kind of libraries that you use for single sign-on. He found that some of these were doing it. If you just remove the signature and then you could change the name and become whoever you wanted to be.

So, let's do something like this instead. If there are no signatures, we throw an exception. Okay, good. We've guarded against that. And then we check the signatures, we see that they're all valid.

And then we grab the username. But in this case, we didn't check what was signed. We just checked that there were some signatures. They could have signed some random other stuff. And this leaves us with something called the XML wrapping attack. So what we do in this case is we take the original signed XML element and we shove it under some random other element.

So that when this last piece of code here will try to grab the username, it won't find this one, the one that was signed, it will find this one instead. So we've just moved the thing that was signed and it's there and the signature is still valid, but it's not being used.

And once again, Juraj Somorowski found these kinds of bugs in the SAML libraries. So this is the paper that they wrote about it. And the interesting bit is this. Eleven of them, of the fourteen, had critical XML signature wrapping vulnerabilities.

Eleven of fourteen. That's quite a lot. And what's wrong with this code then? We have some signature, we're going to try to check it. And I'm just going to tell you right away because we're running out of time.

In this case, it's checking it one letter at a time. So by doing a timing attack, we can figure out how far it got before it stopped. Because when we're doing crypto, all functions that compare strings, they need to always run through the entire strings. They can't be dependent on how far you get in the string.

There are many kind of mistakes that we can do. What Bruce Schneier said, with all these Snowden revelations, is basically that the math is good, but the math has no agency. Code has an agency and the code has been subverted. So we see now that the NSA has tried to introduce random generators into software

and those random generators are broken in a way that the NSA could actually find the key material. And many other kind of mistakes that you can do. One more thing, JSON web tokens.

You'll see that these things, they're using an HMAC here with SHA-256. And there was a bug in many of these libraries as well. Because you could actually set the algorithm here to none. And because the header here is not covered by the signature, these frameworks here were just, ok, there's no signature, I'll just happily accept this token and everything is fine.

And you could also change it so that it would think that the public key was an HMAC key, which is symmetric, and then you could do some trickery there as well. So when you're validating signatures, verify the signature, verify that the elements you expect to...

signed are in fact signed and verified that they are signed in the way that you expect them to and make sure you actually use the data that was signed. So you can't do these wrapping attacks and things like that. So never ever invent your own crypto. Bruce Schneier is watching you so don't do that. Learn how to use the cryptographic constructs correctly so

you don't fall for any of the mistakes I showed. Use secure randoms and and do the CryptoPals challenges if you want to learn more about this stuff. And please do not put your keys in source control on GitHub. This happens way too often.

And of course say no to crypto backdoors. A lot of government properties are now trying to get backdoors into crypto in ways that only they can decrypt it. Like the TSA keys for suitcase that was leaked. We can't have this. It's going to ruin the crypto

so it doesn't work anymore. Another presentation that you might like. Everything you need to know about crypto in one hour and the YouTube video is actually two hours. Some slides. And these people are people you may want to follow on Twitter if you're interested in cryptography.

So that's it. Now it's time for lunch. We'll do the questions on Slido I think.