So is everyone having a good conference so far? Do your heads feel like they're about to explode, all the information you've been getting? I know how you feel, I've been to quite a few sessions myself.

Okay, so we'll get started. So my name is Stephen Hauntz, and we're here to talk about cryptography and .NET. So a little bit about me first. So I'm a development manager for Boots. So has everyone heard of Boots? I'd hope so. Love that meal deal. So I work in our healthcare and pharmacy dispensing area in the business,

and we're currently looking to replace our dispensing software in the entire estate of about 2,500 stores. So you can imagine some of the challenges we have, and encryption is a real important subject which we have because we deal with patients' medical histories and medical records. So as well as working at Boots, I'm also an author with Pluralsight,

and I write books for Syncfusion. So has anyone heard of the Syncfusion ebook library? So all the books on there are free. It's an absolutely fantastic resource. So you just go on there and get lots of books. So we're going to cover quite a lot of ground in this talk,

but there's some resources that are available to you afterwards should you want to pursue any of this in your own code. So don't feel as if you have to sit down and take lots of notes while we're talking if you just sort of focus on what we're talking on here. Then afterwards you can get my book, Cryptography in .NET, succinctly. So I'm not trying to sell you anything. It's free. And also if you're a Pluralsight subscriber,

I've got a course called Practical Cryptography in .NET. So does anyone use Pluralsight here? Oh, cool. Okay. So that course is there along with all the source code which you can just steal and use. Okay, so what's this talk about? So as a software developer, you have a duty to your employer to secure and protect their data, and that's quite an important duty

because as you can see in the press pretty much daily these days, companies are being hacked all the time and having data stolen from them. So it really is down to you guys and girls to help secure your company's data. And if you don't do it and you just ignore it, then hope is not a strategy.

So just hoping that you won't get attacked and hoping they'll go after someone else is not a good strategy to go by. So you really do need to pay quite a lot of attention to this. So what this talk isn't about, it's not going to be very mathematical. We're not going to peer beneath the covers of these algorithms, and I'm not going to show you lots of scary mathematical symbols

because it confuses me as well. So there's no maths, which is great, except for one little question I ask you about halfway through. And it's also, it's not about cryptanalysis. Cryptanalysis is the art and science of getting encrypted text and trying to break it, the sort of thing that the NSA does all the time. So it's not about that. What this talk is about is about people like me and you

who work on Teams. So you work on Teams every day, you go to work, and you're developing code for your companies. So the code that we're going to look at targets the traditional .NET framework. So that could be server-side with Web API, WCF. It could be Windows services that you've got running on servers.

Or it could be client code, so things like WPF, WinForms, if anyone still does that. Anyone do WinForms? Hang your head in shame. I love WinForms. I started off with WinForms. So a lot of the code samples we're going to look at,

they're not that complicated, you'll be glad to know. This stuff is all actually very easy to do. But just because the code is focused on the .NET framework, actually the principles that we're talking about are kind of universal. So whether it be Java, Ruby, PHP, Python, Node.js, Go, any other system out there,

what we're talking about is just as applicable to those systems, just the APIs will be different. So a quick show of hands, is everyone here a .NET developer? Cool, I guess because of the title of the talk you would be. Okay, so what are we going to cover? So first of all we're going to look at random numbers. Random numbers underpin everything we do in cryptography. It's probably one of the most important things we need to talk about first,

so we'll start there. Then we'll cover hashing and hash message authentication codes, or hashmax as they're known for short. Then we'll talk a little bit about secure password storage, because we have a lot of the hacks that have gone on, and we'll talk about Ashley Madison a little bit later. This is a really important subject. Then we'll cover symmetric encryption with AES,

asymmetric encryption with RSA, and then digital signatures. By the time we get to that point, we'll have enough tools in our tool chest to move on to hybrid encryption, which is where we use the best of all of these different primitives and use them all together to create a really powerful encryption protocol.

So what is cryptography? Cryptography essentially is the art of protecting information, and you generally do that with encryption. When you encrypt data, you encrypt it with a key, and then the recipient uses the same key to decrypt that information back into the plaintext. When we've encrypted the data, it is generally called ciphertext,

and the art of breaking encryption, or trying to recover a message without the key, is called cryptanalysis. But there's a lot more to it than just encryption. So there's four main security requirements in good security. So there's confidentiality, and this is what we traditionally think of as cryptography. It's encrypting data, making it confidential. Then there's integrity.

So if I send a message to one of you guys, you want to know that that message has arrived intact and not been tampered with or corrupted. Then there's authentication. So if I send you a message, you want to ensure that that message came from me and no one else. And then non-repudiation. This is the one which confuses people the most, but a good analogy of this is the concept of a contract,

like a physical contract you might have with a solicitor. So has anyone used a company called DocuSign before? So that's a great example of non-repudiation. So I'll give a quick example. So the work I do with Pluralsight, when we pitch a course and they make an offer, we sign a contract. They send it to me on DocuSign.

I read it, sign it. They sign it, and so we've got digital signatures both ways on those contracts. So I can't then invoice for a higher amount and say, well, this is what we agreed. I go, no, it's not, and we've got proof. So that's what non-repudiation is all about. So cryptography is everywhere.

So the moment you switch your computer on, cryptography is being used. So when you browse the web, you've got SSL, TLS. When you shop online, you would hope that your personal information is being encrypted. Your credit card data should be encrypted. Also, when you use the cash machine and you put your PIN number in, there's a handshake going on between that machine and the bank,

which is all cryptographic-based. Another one which is quite common at the moment, which we're not going to talk about today, but that's the cryptocurrencies, so things like Bitcoin. They're all based around cryptographic mathematics. And also another one which is becoming fairly popular is that of voting machines.

So with voting machines, you have a government trying to get new candidates in. You can use cryptography to ensure that a person has only voted once and that they are actually who they say they are at the time of voting. Okay, so let's start off with random numbers.

So random numbers are probably one of the most important things we need to cover. And generally they're used for creating encryption keys or salts on passwords, which we'll look at in a moment. So having a good, unique random number is very important. You don't want anything that's predictable. So traditionally in .NET, when you generate a random number,

you might have used system.random. And if you're trying to do something that's not much more complex than a dice throw or generating lottery numbers, system.random is generally fine, but for cryptography, it's not very good because unless you change the seed every time, the numbers you get back out of it are predictable and it's also not thread safe, which doesn't help.

But a better system to use is a class called RNGCryptoServiceProvider and this lives in the system.security.cryptography namespace. And it's very easy to use. So we have a method here called generateRandomNumber and we pass in a length. This is a length in bytes. So if we want to generate a 256-bit encryption key,

which is 32 bytes, we pass 32 into here. And we create an instance of the RNGCryptoServiceProvider, create a byte array of our desired length, and then we just literally call getBytes on the random number generator objects and then return the result. So it's as simple as that.

But even though it's very simple to do, it's one of the most fundamental building blocks which we're going to build on today. So moving on to the next rung of our ladder, the things we want to look at, is hashing. And a common analogy with hashing is to think of it as like a fingerprint or a set of fingerprints.

So your set of fingerprints uniquely identifies you and it's the same concept with hashing. So if I pass some data into a hashing algorithm, and that might be a document or a piece of string, it doesn't really matter, you run it through the hashing algorithm and you get what's called a hash code out the other side. And that's just a byte array of random garbage numbers, letters.

But that hash code uniquely identifies that piece of data. And when we talk about hashing, there's four properties or four rules we want to satisfy. So first of all, a hash should be easy to compute. It shouldn't be complicated. Have some data, run it through a hashing function,

hash code comes out the other end. It should be as simple as that. It should be infeasible to generate a specific hash. So you shouldn't be able to say, well, if I've got this hash code, what data do I need to generate that hash? So you shouldn't be able to do that. And also, it should be infeasible to modify a message without changing the hash.

So if we, for example, have a PDF document and we want to generate a hash code from that, which we go and do, if you then go and change just one character in that document or one byte in that file, the hash code will be completely different. Not just slightly different, but completely different. And finally, it should be infeasible to find two identical hashes,

and this is commonly referred to as a hash collision. So you shouldn't be able to have document A and document B, run them both through a hash code or a hash generator and get the same hash out the other end. So that shouldn't happen. That's a bad thing. So hashing is commonly what we call a one-way operation. So if you have some data and you hash it, you get a hash code,

but you shouldn't be able to go back the other way. So you shouldn't have a hash code and then reverse it and go back to the original file. Whereas encryption is a two-way operation. So you have some data, you encrypt it with a key, and then another person can decrypt that data with the same key. So it's two-way. And hash codes don't work that way.

So a very common and traditional hashing function is called MD5. Has anyone heard of MD5? So an MD5 produces a 16-byte hash value, and it was designed by a chap called Ron Rivest in 1991. But the problem with MD5 is a hash collision resistance, or hash collision problem was found with this algorithm in 1996,

which means that people have managed to sort of generate the same hash from two different sources of data, which makes it insecure for use in cryptography. So generally, if you're writing a new system, you probably wouldn't want, well, you don't want to use MD5. You want to ignore it. But it's quite common that you might have to use MD5

if you're integrating with an older system. So I used to work for an internet bank, and most of our code was in .NET, but the actual banking platform was an application running on an AS400 mainframe. So when that sent you data back, it always sent an MD5 hash code. So even though we don't really want to use MD5, because we had that old legacy system,

we quite frequently had to generate MD5 hashes to compare it to what was being sent back from the server. So a much better set of hashing algorithms to use is the SHA family, or the secure hash family. And there's two variants which you can find in the .NET framework. There's SHA-1, which gives you 160-bit hash value back,

and there's SHA-2, which you can use either a 256-bit or a 512-bit version. There is a new one called SHA-3. So as you're going back a little bit, SHA-1 and SHA-2 were both designed by the National Security Agency in America, and then they became standards.

But obviously, with everything that's been going on over the last several years, there was a big competition that was launched to try and generate a new hashing standard that wasn't designed by the NSA. You can kind of understand why. And in 2012, a winner, and I'm never quite sure how to pronounce this, is it Kekek or Sessac, cipher,

was picked to be the winner for SHA-3. Unfortunately, SHA-3 doesn't yet exist in the .NET framework. You can get some open source implementations of it, but obviously you need to kind of be wary of the source or where that code's come from. Do you trust it, because you just downloaded it off the Internet.

Before we're going to talk about the rest of this course, we're going to use SHA-256, which gives us a 32-byte hash value. It's very easy to use. So in this method here, we have compute hash SHA-256 as our method. We pass in a byte array of our data to be hashed, and then we simply call a static method

on the SHA-256 object, and then we call compute hash on that object, and you pass in the data you want to be hashed, and then we just return a byte array of the hash code. So again, like the random number generators, you can do all this with just a couple of lines of code.

Moving on from hashing, so let's go on that next level down, we have what's called authenticated hashing. And fundamentally, this is very similar to the hashes we just looked at, except there's one key difference. In an authenticated hash, you can pass in a key, and what this means is that if you generate a hash code with a key and then send that hash to someone else,

they can only recalculate that hash if they have that key. And this is where we were talking about the idea of authentication. So we generate a key using our random number generator, you know, a 32-byte random number, use that as our key, hash some data, but our recipient on the other end has to have that same key to calculate the same hash.

So this gives you, as I just said, it not only gives you integrity, where you can actually sort of calculate this, you know, digital fingerprint of your data, it also gives you authentication, because you can verify where that hash has come from.

The hashing algorithms using a HMAC can be based on either MD5 or any of the SHA hashes, so SHA-1 or SHA-2, we're going to use SHA-2. And the strength of this is based on the length of the key. So if you have a really small key, you know, a few bytes long, that's not going to be very secure, but if you have a good long key, which is, say, 32 bytes, or 256 bits,

that's going to give you quite a lot of security. And the most common hack against this is a brute force attack, where people just try and randomly generate keys, or they start off at the beginning of the key space and just try and run through all of the keys to try and find the correct key. So it's quite computationally expensive. And just like we're generating a SHA-2 hash,

the HMAC SHA-256 is just as easy to calculate. So we have our method, we pass in a byte array for the data to be hashed, and we have a byte array with our key. And we just create an instance of the HMAC SHA-256 object, passing in the key, and then we just call compute hash on that object,

passing in the data we want to hash. So again, it's very simple to use. So if we take a sideways step now, we can sort of look at hashing passwords, or the storage of passwords. So it's very common these days in a system, either a new system you're building or an old legacy system, that you're going to have a database table

containing usernames and passwords. So it goes without saying, the worst thing you can do is store your passwords in the clear as plain text. Did anyone see Troy Hunt's 50 Shades of AppSec this morning? Yeah, he talked about that a bit in his talk. That's probably the worst thing you can do. But then what is quite common is that people would store a hash of a password.

So if someone, say, creates a password on the system, and their password is, I don't know, my password, that's nice and secure, and it goes into the database, you'd create a SHA-256 hash of that password, and you'd store that hash, so you'd never see the actual password. Then if you have a system where someone wants to log in on the client, they'll type their password in,

it's hash on the client, then that hash is sent across to the server and you compare the two hashes. If they're equal, then it's a correct password. If they're not equal, they're typed in the wrong password. So has anyone done hashing of passwords? Yeah, I've done it quite a few times. This does have its problems, though.

So just relying on a hash on its own is susceptible to brute force attacks, so someone can try and run through the space of potential passwords. Or they can do what is called a dictionary or a rainbow table attack, and this is effectively a massive, pre-computed dictionary of different password combinations, and these dictionaries are huge. I mean, they've run into multiple gigabytes,

and you can download them freely off the internet. And they'll have common variations as well, so if you've got a seven-character password, they'll have variations where the vowels have been turned into numbers, because that fools everyone. Now, the problem with this is that,

although it seems like a lot of work to try and break a password by looking in the table, the problem we have is, these days, modern GPUs, the graphics processing units on computers, they're computers in their own right. So people tend to write code that runs on a GPU, which can calculate or try and break billions of hashes per second.

So as Moore's law sort of keeps on going, and these processes get faster, although it might be not possible to break a 32-byte hash today, in two years, it might be possible, because the speed of the machines has gone up significantly, or it might be five years, you don't know.

A good example here, so this is a little snippet of a website called crackstation.net. There's many of these on the internet that you can use. In the example here, we've got a SHA-256 hash that's been posted or pasted into the top. You hit the crack hashes button, and it's recovered the password. So it really is that simple. And you can even post these or paste these

in MD5 hashes into Google, and it'll give you the result, because it just searches against rainbow tables. So what can we do? So next level on from that to try and protect ourselves is we add what is called a salt onto the password. And what a salt is is it's just a long string

of random data, most likely a random number if you use a random number generator, and you append it onto the password, because it makes that password much more complex. And then you recalculate the hash function. And when you store that password, you also store the salt. The salt doesn't have to be kept secret. It probably is advisable to store it away

from your passwords. And what this does is it massively increases the space of potential passwords that a hacker has to try and hack. But that still is susceptible, though. I mean, whilst it might seem infeasible to break a salted hash,

as you're saying, as these GPUs get faster and computers get faster, in five, 10 years, it might be very, very easy to break these. You just don't know. So the next solution, and this is the recommended solution to use, is what's called a password-based key derivation function, or PBKDF2, if you like acronyms.

And the way this works, it's very similar to a salted hash. So you have a password and a salt, which get combined together. But when we run the hash function, we also have this other number that we're passing called a number of iterations, or work factor. And what this does is it repeats the hashing process multiple times to deliberately slow down the hashing process.

So if you pass 10 into number of iterations, it will hash 10 times. If you pass 1,000, it'll do it 1,000 times, 50,000, 100,000, and so on. And the idea of this is you're deliberately slowing down that hashing function so that if a GPU can currently try and attack billions of hashes per second,

by adding a deliberate work factor in there, you might reduce that down to, say, 10 a second or five a second, depending on what the work factor is. So again, it's very easy to use. We have a method here called hash password, and we pass in a byte array of our data to be hashed, and we pass in a byte array of our salt, so that's just a random number,

and we pass in a number of iterations or work factor. But then we create an instance of the wonderfully titled RFC 2898-derived bytes class. So you'd be forgiven for overlooking that one in the .NET framework. It's not obvious what it is at all. But this is the class which does your password-based

key derivation function, and RFC 2898 is the name of the standard which is given to this particular method. So we create that class, we pass in our data, our salt, and the number of iterations, and then you just call get bytes, like we did when we calculated our hash. So here we're saying we want a 32-byte hash of our data,

and it gives us an array 32 bytes long with our hashed password in. So to give you an example of the kinds of iterations, I calculated the timings in this probably about a year ago when I was writing the book. So 100 iterations took two milliseconds to calculate the hash. 1,000 iterations took 16 milliseconds.

10,000 took 196. You can see it's getting slower. Then if we look down 100,000, it takes nearly one and a half seconds. 200,000 is nearly three seconds. And 500,000 iterations takes about seven seconds. So if you use this technique,

you need to think about where you're using it and whether this speed penalty is going to be a problem for you. If you're using it to log into a site, then maybe a two-second delay isn't that much of a problem. I've logged onto sites where there seems to be a bit of a delay once you put the password in. If that's acceptable to you, then you might want to use around 100,000 iterations.

If you make someone wait seven seconds when you put their password in, that might be a bit overkill. But you need to think about where you're using this. So is everyone familiar with Ashley Madison? It's probably one of the biggest hacks that's happened this year.

And when the attackers broke in, they stole the entire password table, and they also stole the source code. So it was quite a fundamental attack. But Ashley Madison, they've been pretty careful. All of their passwords were hashed with something called bcrypt. Now bcrypt is just another variation of a password-based key derivation function.

It uses a different algorithm underneath, but fundamentally it's the same. So it's a password, a hash, and a work factor. So they'd use bcrypt for all their passwords, which is great. So the attackers tried to break their passwords and didn't really get anywhere. So it's done its job. But the problem here, and this is quite an interesting story, is because they had the source code, they ploughed through the source code,

and they found a particular, I don't know if you... Well, I guess when Ashley Madison done it, they thought it was a feature or a fix. But it looks like someone had gone in and tried to optimize the login-in process, and they thought, hold on, this is taking quite a while to log in. So to speed the process up, when you logged in, they created an MD5 hash of the password and the username and stored it locally,

probably in a cookie. So once they realized this, they thought, well, let's not attack the bcrypt passwords. Let's attack the MD5 token that's been created. By some programmer, he probably didn't know any better. He probably thought he was improving the speed of the system. So they ran this process. They'd done the same hashing with MD5

across the username and password. Then they attacked those, and they recovered about 13 million passwords. So it just goes to show that security is only as strong as your weakest link, which is kind of the moral of that story. Okay, so let's move on to symmetric encryption.

So symmetric encryption is kind of the one which most people are familiar with. So with this, you have some data, which is your plaintext. You have a key. You encrypt the data with that key, and you get your ciphertext. And then the recipient, using the same key, can decrypt that data and recover the original plaintext.

So that's pretty good. There's a problem with this, though, and that is that sharing keys is very hard to do. So if I've got some data, and I want to share it with five of you in the audience, how do I get that key to you? Do I email it to you? Not a good idea. Stick it on Dropbox?

Probably an even worse idea. Print it out on a piece of paper and send it in the post? No, because someone could intercept it. Or do I physically go and meet each one of you and hand you the key? You know, it's a hard problem, but it's a problem we're going to tackle a little bit later on. So I'll bring this slide up again

just to illustrate the point where we said that hashing is a one-way function. You hash some data. You don't go the other way. But encryption is a two-way function. So we encrypt some data with a key. We can then decrypt it with the same key and go back. And the way symmetric encryption works is it encrypts several bytes at a time. So you're feeding a load of data.

It chunks it up into blocks, and it does loads of magic under the covers, and then out pops your encrypted data on the other side. And the blocks are padded. So if you're working with, say, 128-byte blocks, and then that last block doesn't quite fit, you know, it doesn't use up all the space, the block will get padded. And there's different padding schemes that you can use.

In the .NET Framework, we have support for three symmetric encryption algorithms. So we have AES, which is the one we're going to look at. But there's also support for DES and Triple DES. Now, DES was one of the original, sort of most widely used symmetric encryption protocols. It was found to be flawed.

And there was a big internet project, I can't remember what it was, sometime in the 90s, where a load of people sort of donated computing power to try and break DES, and they eventually succeeded. So to try and fix that, they came up with an alternative called Triple DES. And effectively, what Triple DES does

is it encrypts your data three times. And there's two different ways to do it. Either do it with two keys or with three keys. So again, like what we were talking about before, with hashes and MD5, you probably don't want to use DES and Triple DES for a new system. But you may have an older legacy system

that does use DES or Triple DES, which you might need to decrypt their data. So you might need to use it for supporting legacy integrations. But for new systems, I'd stay clear of it. The good thing is, though, once you know how to use either DES, Triple DES or AES, I mean, they all share the same interface. They derive from an abstract base class called symmetric algorithm.

So once you know how to use one, you know how to use the other. It's just a name that's different. So we're going to look at AES crypto service provider. So AES crypto service provider is a standard with the National Institutes of Standards and Technology in the U.S., and it became this standard in 2001.

And it was invented by two mathematicians called Joan Damon and Vincent Ryman, and it's based on their original cipher called the Ryman, sorry, the Rymdell cipher. So the Rymdell cipher is what won the competition to become the advanced encryption standard. And the way this works is, when we want to encrypt some data,

we have to pass in our plain text, so a byte array of the data we want to encrypt, but we also have to pass in something called the initialization vector. And what this is, is it's a 16 byte random number, and really, the best way of describing what it's there for is it helps jumpstart the algorithm. So the way the algorithm works under the hoods, it just needs this additional bit of data passing in

just to start it off. So when you send your message to someone, you need to store or send the initialization vector as well, but it's not secret, it's not the key. So with AES, there's three key sizes we can use. There's 128 bits, 192 or 256 bits.

Recommendation is use 256 bits, which is 32 bytes. So you pass those three bits into AES, and you'll get your cipher text out the other side. Now in the .NET framework, there's two implementations of AES that you can use. There's a class called AES managed, and there's a class called AES crypto service provider.

So AES managed is a native .NET implementation, so it was written in .NET, but it hasn't got a certification. There's a certification out there called FIPS 197-2, and what this is, is it's a separate body that certifies these algorithms,

and if they pass a standard suite of tests, they get this certification. And what that means is, if you have an algorithm saying .NET that is certified, and you have an algorithm or a version of it in Java, and that's certified, you know that data encrypted in .NET is gonna be able to be decrypted in Java, because they're both certified, they're both gonna be compatible with each other.

AES managed doesn't have that certification. That doesn't mean it's necessarily gonna fail, but obviously having that certification is a way of knowing that it's gonna work with other systems. So the other one is AES crypto service provider, and in .NET, this is basically just a wrapper

around the underlying Windows cryptography platform, and this is FIPS certified. So that's the one we're going to take a look at. So to encrypt some data, we have a method here called encrypt, and we pass in a byte array of our data to encrypt, so it could be a document that you've loaded up

and converted into a byte array, a string, it doesn't matter. And we have a byte array with our key, so in this case, that's gonna be 32 bytes long, which we generated with the random number generator we looked at earlier. And we also pass in the initialization vector, which is just a 16-byte random number.

And then what we do is we create an instance of AES crypto service provider, we set up the key and the IV, and then the way this algorithm works, it uses streams. So we create a memory stream and then a crypto stream, and then we call AES create decryptor, which is that bit there. And then we pass the data in,

we write it, flush it, that gives us the data back out, and we convert it into a byte array and return it, and that's our encrypted data. So you won't be surprised to know that the process for going the other way is very similar. So we create AES crypto service provider, pass in the key, set the streams up, but this time, we call AES.create decryptor.

And we pass the data into the stream, write it, and then extract the data out the other side. And that will give you your original plain text back, providing you've used the same key and the same initialization vector. Okay, so on the next part,

we'll look at asymmetric encryption. Has anyone heard of this before? Yeah, quite a few, I think that's good. So the one we're gonna look at is called RSA. And this works in a bit of a different way than what AES does. So with RSA, we have what's called a key pair,

a public and a private key. And those keys are mathematically linked, and we'll take a little look at what that means in a moment. But the way it works is if I have a key pair, so I've got a private and a public key, I can let all of you know what my public key is. You can all have a copy of it. So if you want to send some data to me,

you encrypt with my public key, send me the data, and then I decrypt it with my private key, which only I know. Then if I want to send some data back to you, I encrypt it with your public key. I send you that data and you use your private key, which is only known to you, to decrypt that data. And this gets us past that key sharing problem because we don't actually have to share any keys,

which, as we said before, was a problem with AES. So RSA was developed by RSA Data Security Incorporated by three gentlemen called Rivest, Shamir, and Edelman. And the way RSA works is it's more of a mathematical problem as opposed to an algorithmic problem like AES. So it's based on the fact that it's very hard

to factorize large prime numbers. So there's more that goes into an RSA key than just prime numbers, but fundamentally it's all based around prime numbers. And we're going to use a key length of 2,048 bits. You can go high, you can go to 4,098. It's not recommended to go lower to 1,024 bits

because that's been proved to be vulnerable. So remember talking about prime numbers and the way the keys are based around prime numbers. If you look at the sum on the board there, so 23 times 17 has two prime numbers being multiplied together. It's not that hard to work out what the answer is. You can either do it in your head or on a calculator.

It's quite easy. If we go the other way, so if I say what two prime numbers do you have to multiply together to get to 5,963? Does anyone know the answer? Good. The answer for that is 67 times 89.

So when we relate this back to the public and private key, our public key is 5,963, and the private key is the factor, the two primes that you multiply together to make that number. So if you dig into RSA keys more, there is more stuff that goes into the key,

but that's the fundamental concepts of what the keys are made of. And the way RSA works is it's all based around modulus arithmetic. So it's a mathematical process, and this means that when it comes to the amount of data that you can encrypt at once, you can't actually encrypt more than what the length of the key is. So if your key is 2048 bits, you can't encrypt more than 2048 bits.

It has to be that or less. So RSA is very easy to use. So if we look at how to generate the keys first, so we have a method called assignNewKey, and we create an instance of the RSA crypto service provider and pass in the length of the key that we want to use,

and then we just call export parameters passing in false to give us our public key, and then export parameters and passing in true to give us our private key, which we're just going to store in those two parameters at the top there. So encrypting data, what we do is we pass in a byte array into our method.

We create the RSA crypto service provider object. We import the public key, so remember we encrypt with the public key, and then we just call RSA.encrypt and pass in the data, and then the byte array we get out is our encrypted message. To decrypt, again, it's very similar.

Pass in the data you want to decrypt, create an instance of the class, import the private key this time, so this is the recipient using their private key to decrypt the message, and then you just call RSA.decrypt, and then that gives you the original data back.

So now we'll look at one of the final tools in our tool chest, and that's going to be digital signatures. So digital signatures consist of three algorithms that you need to use.

So first of all, you need to have a way of generating a key. Then you need a signing algorithm, and then you need a signature verifier. So if you remember what I was saying before is digital signatures are kind of like enforcing a contract, like a physical contract you might have with a solicitor. And the way this works is if you have some data,

like we have on the left here, you create a hash of that data. We're not actually going to create a signature across the whole data because it could be large, so we create a hash of that data and we then sign that hash using our signing algorithm. And then the result of that is our digital signature for that piece of data.

So if we look at this as an example, so we have Bob at the top, he uses his private key, and he creates a digital signature of a hash of a piece of data, and he then sends that digital signature across the internet, or the intergalactic spider web on my picture there.

And then Alice at the bottom, she uses Bob's public key to verify that signature. So can anyone spot any differences between this and RSA? Yeah, so with RSA, we encrypt with the public key, decrypt with the private key. This is the other way around.

When we generate the digital signature, we're using the sender's private key, and then the recipient uses the sender's public key to verify the signature. So if we look at how you do this, this is exactly the same code as what we had with RSA. So we want to generate two keys. So we create RSA crypto service provider,

and we just call export keys to give us our private and public key. And then to sign the piece of data that we want, or the hash of the data, we first create an instance of the RSA object, and we then import our private key. There's private key this time. And then we use the very snappily titled R-S-A-P-K-C-S one signature formatter class.

Who comes up with these names? I don't know. And then we create an instance of that class, set the hash algorithm that we want to use inside as SHA256, and then you just call create signature, passing in the hash of the data. And then you get the byte array back out, which is your actual signature.

So it's quite straightforward to use, but if you came across that on MSDN, unless you're particularly curious, you'd probably skip over it because it's not the most obvious name of what it does. So to verify the signature, again we create an instance of the RSA object,

we import our parameters, or we import our public key rather, and then this time we use R-S-A-P-K-C-S one signature deformatter. We set the hash algorithm, and then you simply call verify signature and pass in the data, or the hash of the data that you signed originally, and the signature.

And then that will give you a Boolean back, true or false. Yes, the signature is valid, no it's not. Has everyone managed to follow me so far? Cool, that's not intense, good. So if we quickly recap on the section we've looked at here, so we had four main security requirements that we wanted to satisfy.

So for confidentiality, the tool we picked for that was AES and RSA. So one symmetric and one asymmetric algorithm. For our integrity requirement, we picked SHA-256. This is where we want to generate that unique thumbprint or fingerprint of our data.

For authentication, where we generate a thumbprint but we use a key, we used a hash-mac, a SHA-256 variant of that hash-mac. For non-repudiation and digital signatures, we used a digital signature system in .NET.

So that's all of our tools, our little primitives that we're going to use. So what we want to do now is do something called hybrid encryption. This is where we use all of these things together, the best of each.

So if you remember back, then RSA has limits on the amount of data that you can encrypt. You don't encrypt more than the length of the key, because it's a mathematical process that's going on. But with RSA, it's flexible, it's very fast, it's very algorithmic, but sharing the keys is hard. So what we want to do is combine RSA and AES into a hybrid scheme.

So the way we're going to do that is we generate an AES session key. So we're creating a key for AES, and that's using our random number generator. And then we encrypt our data with AES, just as we did before.

Once we've done that, we then use our RSA public key, or the recipient's public key, to encrypt that session key. And then we send the encrypted data and that encrypted session key over to our recipient, and they use their private key, their RSA private key, to decrypt the AES key.

And then once we've done that, we can just decrypt our message as normal with AES. Anyone follow that? We'll walk through an example in a moment. So the data that we send from point A to point B contains the RSA encrypted session key. Now, as you said, sharing symmetric keys is hard,

so we're using RSA to protect that key first. We're going to send the initialization vector, now that little 16-byte piece of data we need to jumpstart AES. And we have the encrypted data that's encrypted with AES. So if we just walk through that as an example,

so we have Alice, she generates a session key, which is 32 bytes for AES, and she generates a 16-byte initialization vector. She then uses AES to encrypt her data using that session key she's just created. Then we encrypt the session key with the recipient's public key using RSA,

and then we send all of that data to our recipient, which is Bob. So Bob receives that message, and he then uses RSA in his private key to decrypt the AES key. And then with that decrypted key and the initialization vector that has already been sent,

he uses AES to decrypt the message. So the message here is, meet at noon below the clock tower, wear a red rose in your button. Very spy thriller. So now Bob wants to send a message back to Alice. So what he does, he generates a new session key, so you never really use keys.

He generates a brand new one. He generates a new initialization vector, that bit of data to jumpstart AES. He encrypts his data, and then uses RSA and Alice's public key to encrypt that AES session key.

And he then sends that across the internet or however he wants to send it to Alice. And then when she receives that data, again she uses RSA in her private key to recover the AES key. And then using that key and the initialization vector, she then uses AES to decrypt her message, and then she can read it.

So the reply is, I will meet you. I'll be wearing a blue hat and red boots. Very fashionable. So if we just think about what that's given us, it's given us a way of using the speed and the power of AES to encrypt our data,

but we've solved the problem of sharing the keys, so I don't have to meet you in person to give you the key. We're using the asymmetric encryption algorithm to do that key sharing, because only the recipient knows their private key, whereas anyone can know the public key, so you haven't got this problem of key sharing. So we can now take this one step further, and we can add the concept of integrity.

So exactly the same process as before, but once we've encrypted our data with the session key, we then create an authenticated hash of the encrypted data and the initialization vector together. And because we're using an authenticated hash,

we can use that same session key to calculate that hash. So this means the data that we now send to our recipient contains the RSA encrypted session key, the initialization vector, the encrypted data, and the hash MAC of that encrypted data and the IV.

So what this means to the recipient is once they decrypt that data and they decrypt the key, they can then recalculate the same hash, and if the hash matches what was sent to them originally, they know the data's not been tampered with or corrupted in transit. If those hashes are different, then you discard the decrypted data,

because it's either something's happened on the wire or someone's intercepted it and tried to change it. But the power of this is the recipient knows that the message came from the intended sender, because only they would have had access to that session key at the time, which is why we use a hash MAC,

so we get that element of authentication as well as integrity. So now using the final tool in our tool chest, we can now add digital signatures in there as well. So exactly the same as before, except we're adding this extra step. So once we've encrypted our data, we create a hash of that encrypted data,

and we can then create a digital signature, and that digital signature gets added into our packet of data. So we've got the RSA protected session key, the initialization vector, our encrypted data, the authenticated hash of the encrypted data,

and a digital signature. So what this means is the recipient, when they've decoded all of that data, they can also verify that that digital signature is valid, which again is sort of proof that the original sender sent that message so if the original sender tries to dispute the data or the message that they sent,

the receiver can go, well, no you didn't, because you've calculated this digital signature and I've verified it as being true, so you can't dispute this data that you sent me, because they can only create that digital signature with their private key, the sender's private key, which only they have. So they're either lying or their private key has been stolen,

which is a whole new problem. Okay, there it is, yeah.

Yeah, I mean, the public key is mathematically linked to the private key, so if you encrypt with that key, then only they can decrypt it.

That's a good question? Yeah, it is, yeah. Yeah, I mean, then you start opening up the sort of questions of key or square as well.

I can't hear, sorry. Okay, so what I was just saying there is there was a trend at open source conferences

where people would actually physically exchange their public keys. Okay, so everyone bought their public keys with them. Okay, can I just finish off going through the slides,

then we'll take questions at the end. So just to recap what we've covered, because we've covered quite a lot of ground in this session, so we've gone through random numbers, hashing hashmax, we've talked about how to secure passwords, we've covered symmetric algorithms with AES, asymmetric algorithms with RSA, and we've covered digital signatures,

and we've then used all of those features in combination to create a hybrid encryption scheme, which is a really good way of getting data from A to B in your systems. So, what next? So, as I said, we've covered quite a lot there. You'll probably forget half of it by the time you get, but especially if you've got the party tonight.

But if you are generally interested in sort of trying this sort of stuff out, I'd say you can get my book from Syncfusion. It doesn't cost you anything. I'm not trying to sell you anything. It's free. And the book's less than 100 pages. They're designed to be very quick to read. They don't hold your hand. They get straight to the point. If you want more background information and you want to be sort of hand-holding through the examples

in sort of live demos, then there's my course on Pluralsight. So, it's about just under four hours long, but it also talks about why this sort of stuff is important, as well as just how to do it. Also, I'll just show you these. These are some of my favourite books. So, cryptography is a fascinating subject. I mean, when you start peering beneath the covers about how these systems work, it's absolutely fascinating.

So, I thought I'd include a few links here, just in case you were interested in this sort of thing. So, the first one is called The Code Book by a chap called Simon Singh. It's about 350 pages long. It's about the size of a standard paperback novel. And it's very easy to read. And that starts off from the history back in the ancient times where people used to use Caesar ciphers

and all of that right the way through to the digital era up to RSA. So, it's an absolutely fascinating book. If you don't want to read anything too long, but you want to see a bit of history, then the second book by Fred Piper and Sean Murphy is called Cryptography, a Very Short Introduction. It's a tiny book, takes you about an hour to read, but it gives you a real sort of brief whistle-stop history of cryptography.

My personal favourite book on the subject is called Everyday Cryptography. And the first half of the book talks about how a lot of these algorithms work that we've discussed today. But it does it in such a way that it doesn't just completely bombard you with maths and equations. There's a little bit of that in there, but it's quite manageable. I mean, I'm rubbish at maths and I understood it.

The second half of the book equates all of that information to real-world use. So, it talks about how SSL, TLS and all those sorts of protocols work. It talks about how WEP and wireless protection works. And there's even a pretty good example about how the pin number exchange between a cash machine and a bank works.

So, it's a real sort of practical book. And then probably the most famous book is a book by a guy called Bruce Schneier called Applied Cryptography. This book was released in the mid-90s. It's the book the NSA wanted to ban, and I think they did ban it at one point. So, it became one of those sort of black market things that everyone tried to get hold of.

And this was at the time when effectively strong encryption was embargoed. There was like strong export and problems with the US. And this book goes into real depth. It's a really hard book to read, but it's quite interesting. And it explains how sort of DES, Triple DES, Blowfish and all sorts of algorithms like that work.

It doesn't cover AES, unfortunately. It was published before AES's time. But if you want to get a good insight into how a lot of these algorithms work and you're a bit of a sadomasochist for complex equations, then that's a really good book to read. So, thank you. Thanks for coming along.

As you leave the room, this is a really cool game you can play. It's called Put the Green Card in the Bucket. And the winners get awesome points. I'm going to be around for the rest of the conference. I'm hanging around the community stand next to the .NET Rocks guys. So, if you want to sort of learn about user groups and how to set user groups up,

there's a group of us talking about that as well.