 This talk is more sequence of cryptography. It's obviously going to be covering quite few cryptographic topics. The idea I had with this talk was to cover more interesting areas that I failed to fit into the first talk I gave on this topic, which I actually gave at this conference last year. I don't suppose anyone was here last year and saw that talk? A few? Cool. Well, don't worry if you haven't. This talk is completely standalone. It's just a completely new topic. So I'm going to give a quick refresher on cryptography to start off with to make sure everyone's up to speed. So one of the first questions that comes up is why do we actually need cryptography? What makes it important as something to use in development work? It gets a lot of attention in the media. When I wrote this talk, there was quite a lot of talk from politicians about putting backdoors into encrypted messaging services and things like that. And also a lot of news about Bitcoin. You might have heard and things like that. And obviously, with the rise of the internet and the fact that we're collecting yet more and more data on people and more and more and more sense of information, it's becoming vital to make use of more security around that data to make sure that it doesn't get into the wrong hands. If you watch the news, you'll quite regularly see companies that have been breached and have lost reams of customer data, ranging from just emails and passwords to more sensitive medical information or financial information. So cryptography is becoming more and more important to help protect this information and stop it falling into the wrong hands. What do we actually mean when we're talking about cryptography? So there's quite a few areas that modern cryptography covers. The first one is probably the most obvious one, the one that you probably think of immediately if someone asked you this question. It's confidentiality. We need to ensure that anyone who isn't the intended recipient of a message isn't authorized to view some data, can't do so. We've got hundreds of different algorithms which have been developed over the years which can be used to provide confidentiality. AES is currently one of the most widely used standards and it's probably the best one to use for just ensuring confidentiality. Most of these algorithms are what we call symmetric algorithms. This means that you use the same encryption key for both encrypting the data and then decrypting it later on when you want to read it again. And there are two main classes of algorithm here. There's stream ciphers which you can use to work on a continuous stream of data. That might be more useful for streaming if you've got like a continuously going connection like SSH for example. And then you've got block ciphers like AES which break the message up into small blocks and encrypt each one individually. Mode of operation, you have to be a bit more careful with block ciphers because you can actually introduce some weaknesses if you don't even think quite right. Stream ciphers are a little bit safe in that respect but they do have their own downsides. Not only cover much on those today but it's useful to know that the two exist. Another area that modern cryptography has to cover is key exchange. If you want to talk to someone else, you need to be able to agree on a secret key. One of the ways we can do this is using what we call asymmetric cryptography. That is where you can have a different key for encrypting to the one you use for decrypting. That means if you want someone to be able to talk to you confidentially, you can put the key used for encrypting and it's a public key out in the world because anyone can use that key to encrypt a message for you but they can't then use that decrypt messages that people have sent you. So you can keep the other half that key, the private part, secret to you and that means that anyone can communicate with you without you having to specifically go to them and agree on a shared symmetric key to use. Another area that we get into is identity, proving that when you receive a message that it actually came from the person you thought it did. This actually works in a very similar way to key exchange but in reverse, you can use an algorithm in which the encryption key is kept secret but the decryption key is made public. That means that you can encrypt a message as a signature with your private key and anyone in the world can decrypt it and verify that it came from you. This is known as a message signature usually. Another area that we get into is authentication. How do we know that the message that you actually received was the one that was sent? Again, for this, we tend to use hash functions such as SHA-256. When you receive a message that someone sent, if they send the hash along with it, you can compare the data sent with the hash value of the message and by either signing that hash or by including a secret key within the hash, you can verify that the message hasn't been tampered with. So I did mention briefly that we've got a difference between symmetric encryption and asymmetric. There's two classes of algorithm, each have a different purpose. Symmetric algorithms, as I say, have a single key we use for both encrypting and decrypting. They're generally a lot faster at working. You can encrypt data much quicker with a symmetric algorithm. They're optimized to run really quickly. Asymmetric algorithms, on the other hand, you have the two keys, one for encryption and decryption. They're a lot more computationally complex. So what we'll tend to do is use the two in combination. You will derive a random encryption key for your data, encrypt your gigabytes of images or whatever that you want to send with your randomly generated key, and then you'll encrypt just the key, a small amount of data, using the slower asymmetric algorithm. You can possibly think about this if you want this like a physical representation, think of a padlock, okay? Padlock's got a key, it's got a lock. I could pass someone at the back of the room a little box, metal box, and a padlock. They could write a message on a piece of paper, put it in the box and pass it to the front of the room. Nobody, provided they've clicked that padlock shut, nobody who's passing it forward and helping me out with this demonstration would be able to look in that box and find out what the message is. But once it comes to me at the front, I can use my key to unlock the padlock, padlock of the box and read the message. It's kind of similar concept to how asymmetric cryptography works. So one of the original asymmetric algorithms you've probably heard of, RSA. Now this algorithm relied on the difficulty in reversing multiplication in modular arithmetic to construct a function which was really easy to compute in one direction, but really hard to compute in the other direction, really hard to undo the function. However, you could make it much easier to reverse that computation if you had a secret piece of knowledge that you computed up front. Now RSA is quite an old algorithm and it's a bit out of date now. Both advanced in mathematical theory and in computational power. I've meant that in order to be secure today, you need to use quite large keys with RSA. Generally between 2048 and 4096 bit keys. Obviously when you're dealing with fairly large size of encryption keys, it requires quite a bit of processing power to actually compute the encryptions. Whereas that's probably not a problem on a really powerful laptop like this, probably like the MacBooks and all the development laptops you've got. If you're thinking about small embedded internet of things devices, which are running on battery power and they have limited processing, they wanna do as little work as possible while still remaining secure. Now this is where elliptic curves can come in. Elliptic curve cryptography is much more modern, more advanced, and it's based on a different mathematical problem which is much harder to reverse. We can therefore get away with much shorter keys. A 224 bit elliptic curve key can provide a similar level of security as a 2048 bit RSA key. So one of the first, I'm gonna look at today is how elliptic curve cryptography actually works. So what exactly is an elliptic curve? Basically it's an equation, a mathematical equation. They always take a similar form to this where you have a y squared term on one side and an x cubed term and some of the x terms on the right hand side. Obviously that's quite mathematical and abstract. That is an example equation which is used for the curve 25519. That's what Lipsodium uses under the hood for its elliptic curve cryptography. You don't need to remember that equation at all to implement it, but that's what it looks like. Probably a bit easier is to ignore the equations and think of it in its visual form, a curve on a graph. Now, a few interesting points to note. Elliptic curve always has this general kinked format. And so what else that's interesting about it is it's always symmetrical around the x-axis. This is really important property in the curve and in what we actually use to compute functions on it. Now, if we would actually want to actually build a crypto system, we need to define some basic mathematical functions. The first one we define is called the dot function. Now, this relies on that symmetry but also another really interesting property of elliptic curves. If you take two points, p and q on a curve, any elliptic curve, which matches that equation in the first slide, and you draw a straight line between them, let's say straight line here, it will intersect the curve in exactly one of the place. So straight line drawn through two points on a curve will hit the curve exactly once more, somewhere. It might be a long way off, but you can guarantee that if you extend that line to infinity in both directions, it will hit the curve again once. The dot function is based on this act of finding that intersection point and then reflecting it in the x-axis. So if I said to you, I want you to compute p dot q, you would draw this straight line, find the point and reflect it in the x-axis and the result of p dot q is that point r down the bottom. If we take this function in our elliptic curve as being similar to an addition function with normal numbers, we can start by defining a multiplication function through repeated usage of this. So we could multiply p by q and get r, and then we can do it again and multiply p by r to get another value, and that would be multiplication. That sort of works a bit like this. To apply the dot function to a single point, we've obviously done this, and we've gone here, reflected it, we've got this another point, and then we draw another line, we get the intersection point, and that becomes, so we've sort of iteratively applied that mathematical operation, and we've got multiplication. So we've actually done a three dot there. Now this function is the basis of elliptic curve cryptography because it has a really useful thing about it is that if I give you this point and this point and tell you that I've applied the dot function to it a number of times, it is really hard to compute how many times I've done it. Reversing that multiplication without knowing how many times the dot function's been applied is computationally very difficult, and this forms a basis of our cryptic system. Now, obviously the diagram from the previous slide is a really good way of visualizing an elliptic curve, however it's not quite how we use them in practice. To get a representation that is useful for cryptography, we restrict the points on the curve to just the integer values. So obviously a curve is a continuous line, but we break it up and we say only the ones that are whole numbers are what we're gonna use. And we also don't want a curve that extends off to infinity in every direction because computers have slight problems dealing with numbers that are infinitely large. They're much better at working in a confined space of numbers. So what we also do is we apply modulus function to the curve, and we say, okay, well we're gonna draw the curve and when it hits the edge of our boundary, when it hits a particular upper bound, we're gonna just reflect it round, wrap it round. Okay, so your curve just wraps around and continues. And what you end up, if you plot this result, it's something that looks a bit like this graph, and you just have all these points which are a curve restricted to that modular space. However, if you do this, all those previous functions, the dot function, the multiplication, they still work. Provided that you also wrap around, when you're drawing your line between the two points, provide you also wrap that round when it hits the edge. It continues to work and it'll continue to eventually land on a point. And we can compute these computations quite quickly and quite efficiently. And that's how we base it. That's how we do our elliptic curve cryptography. So once we've got a curve, like the one in the previous slide, in order to actually do a key exchange using it, you and your communications partner would have to agree upon a particular curve, pick a particular curve equation. You probably want to pick P25519, because that's in Libsodium. And you need to pick a point on that curve that's called a generator point. And obviously the modulus for the curve, what point you wrap around at. Then what we need to do is select a random integer, D. And then we compute a point on the curve that is the result of multiplying G by P D times. So you compute another point here. So you're applying that dot function over and over again, based on the random number you've picked. We can then exchange the public keys, which is the point that you've generated based on that D value. So Alice has picked a D value, a random, computed the P point for that integer. Bob has done the same, they've both got a different value, they've got a different point on the curve, they swap them over. At that point, Alice takes her D point and continues multiplying, continues the dot function from the point that Bob gave her. Bob does the same. And just like multiplication in normal mathematics, if you multiply two by three and three by two, you get the same result. You do an elliptic curve, apply the dot function, you get the same result. So if you take Bob's random number, Alice's random number, applying both to the same generator point, you'll get to the same point. They've computed a shared secret which no one else who's part of that communication can do because they don't know the secret D values that they generated at the start of the protocol. So both parties now have this shared secret, the shared point on the curve. And then we can use that as a basis for actually encrypting data. That kind of works a bit like this. So we've got a bit more visual for people who learn better visually. Alice generates her point, generates her random integer, A, Bob does the same. They calculate A times their generator point, swap them over and then do it again to calculate their shared secret. Okay. Now, our protocol as it stands does have a slight flaw. If Alice and Bob are unable to exchange public keys in a secure manner, e.g. in person, then it's possible that an attacker, a third party, could get in the middle and intercept their key exchange protocol. How this could happen is if we've got our attacker here, Eve, gets in between the communications, intercepts that network connection between Alice and Bob. She can actually perform the key exchange protocol separately with Alice and separately with Bob, pretending to be each of them to each other. Okay. And then Eve can calculate these two shared secrets and then when Alice sends a message to Bob, Eve can decrypt it using the shared secret that she's generated on the download with Alice, re-encrypt it with the shared secret she's generated with Bob but retain a copy of the plain text of that message. Now, that problem we've sort of touched upon is coming onto the next topic that I'm gonna cover in this talk, which is a web of trust. How can Bob trust that a public key that he thinks might belong to Alice actually does? Unless they actually meet in person, unless you go up to someone in a conference and say, hey, here's my public key. You can use that to contact me securely. You know, you can look at my delegate badge. You know that I'm Chris. I can give you my key and say, okay, you can now use that. You trust that it's me because we've met in person exchange those keys. If we're doing that over an unsecured channel over the internet, how do you make sure that that's been done correctly? One option we might decide to go with is just trust that our initial communication was actually secure and nobody got in the middle of it. You know, it's fairly unlikely that someone's gonna be slipping your connection and deliberately manning the middle of your connections. So that might be an option we take. SSH often uses this. If you notice when you SSH into a server and it says, hey, this key's not recognized, do you trust it? And you always go, yes. That's basically how it's working. It's a policy of trust on first use. But if you also notice, if you've regenerated the keys on your SSH server that you've logged into, you'll get this really big banner message that says, your keys have changed. And it refused to let you connect until you say, I know about that, I changed them deliberately. It's okay. So that trust on first use policy means that you get a warning if someone tries to man in the middle of your connection after you've set it up for the first time. But we can also do it in a different way. So with asymmetric ciphers, we can compute these shared secrets even over an insecure channel. But obviously we're still open to that man in the middle attack problem. What they can do, even if you've not met in person, if you have a trusted third party, let's call him Trent, a very trusted person, very, very trustworthy. And Alice knows Trent personally, they've been to conferences together, they know each other, she trusts him. And Trent's also flown over to America to give a couple of talks over there and he's met Bob in person. And he has Bob's key. What Trent can do is he can say, well, okay, Alice, I mean, I know you've not met Bob personally, but I can vouch for him. I can say, hey, this is Bob's public key. He gave it to me personally. And when he actually flies over to America, he can say, okay, Bob, I've met Alice personally, this is her key. And he can sign that key with his keys. And that means that you can do that process even if you don't meet in person. So Alice could say, okay, you've got my key, can you sign a message and say, hey, this is my key and send it to Bob. And then Bob can trust, if provided he trusts Trent, which I'm sure he does, he can trust that key is actually Alice's. And that's the start of how you build up this way of trust, because obviously if Alice then needs to be introduced to our Bob's contacts, Bob can say, okay, well, I'm gonna sign the public key of my friend Craig and send it over to Alice. And now Alice can trust, again, provide that she trusts Bob, but Craig is Craig. So the question is, can you trust a web of trust? Well, yes, this is exactly how the entire public key infrastructure works at the moment. When you go onto a website, it presents you with an SSL certificate which says, depending on how much they paid for their certificate, it might say that it's a particular company or it might just say it belongs to a particular domain. And that certificate will come with a signature from a key issuing authority, like Let's Encrypt, or one of the ones you have to pay for. And what they will do is they will do some sort of test to make sure that the person is either who they say they are or that they have control over that domain. Let's Encrypt does this automatically. Gives you a challenge. So if you own the domain, cryptography.com, you can set up a challenge, put a particular file on your web server. Let's Encrypt will go and verify that automatically and it'll issue you an SSL certificate which it signs with its key and says, yes, I have verified that this public key belongs to cryptography.com. When a user then goes in their browser and loads that certificate up, their browser is preloaded with keys from some of the major certificate authorities and they can verify the signature from the certificate authority that's issued that key and say, yes, okay, that SSL certificate is trustworthy, it does belong to that website, we can trust it. And that's exactly how everything works. So yeah, you really do need to trust this web of trust. Okay, so next topic we're gonna move on to is a slightly different one. Let's go over and look at hash functions. So hash functions are a really, really important part of modern day cryptography. The main use is for protecting the integrity of data as part of a HMAX scheme or combined with a digital signature from a symmetric algorithm. But another use of hash functions is to derive encryption keys from user provided passwords. You take a password from a user and you pass it through the SHA-266 algorithm lots and lots of times. You can derive a strong random-ish encryption key which you can then use to encrypt some data. That's how a lot of the password protected zip files and things like that, they'll do that. They derive a key using a hash function from the password you provide. They don't actually use the password as an encryption key. We're gonna take a look at what a hash function actually needs to do. An ideal hash function has a few properties. The first of which is it should be quick and easy to compute a hash for any given piece of data. If I give you a file, it shouldn't take you months and months of computational activity to compute its hash. It should be really fast. It should be really quick. You need to do it a lot and you need to use it for verification. The one exception to this, of course, is if you're using hash functions for protecting passwords, they need to be really slow because you don't want people to be able to just brute force the hash. But for most users, for verifying data, you need to be quick. It should also be really difficult to compute a piece of data that hashes to a given value. For most functions, the fastest way of doing it is by brute force. If you want to have a SHA-256 hash that spells out something funny in your Git commit, you're gonna have to sit there and brute force different commit messages over and over and over again until you actually get the hash that you want. There are actually some tools out there that'll actually tweak your Git commit messages to give you a prefix on your commit hashes. They're quite fun to play with. But it's really difficult to do. You've got to brute force. You've got to change things over and over and over again and that's much more computationally intensive than just computing the hash once. And this is actually the property of a hash function which makes them useful for the proof of work function which is using modern cryptocurrencies. Down to a bit of that later. Another property that is important for a hash function to have is it should be very unlikely that two different messages will have the same hash. If I take a piece of text and I add a full stop at the end, it should hash to something completely different to the original piece of text. There should be a lot of change. It shouldn't be obvious. It shouldn't be easy to predict what the hash is gonna be if I change a piece of the text. There was a bit of an issue with MD5 and that cryptographers worked out how you could set up a piece of data so that you could compute two pieces of data which hash to the same value. This was quite bad because it meant that you could forge the signatures on documents. So you remember the SSL certificates that we have that are trusted? What the researchers managed to do was create a certificate signing request and send it off to a certificate authority. Certificate authority went, okay, yep, fine. We'll sign that, we'll say it belongs to you. We verified it. But they had computed upfront another document which hashed the same value and they had the same MD5 hash as the certificate they had submitted which meant they switched the two over and they got themselves a certificate which was actually trusted not just to verify their own website but to verify any website which obviously is quite a bad vulnerability. So they could pretend to be any website in the world and your browser would trust them. That's kind of why we don't use MD5 anymore. Yeah. So we're gonna take a look at not MD5 because that's broken and horrible and you shouldn't be using it. We're gonna look at SHA2 which is probably one of the most common hash algorithms at the moment and probably the one you're being using most for these kind of things. The SHA2 family is a whole group of algorithms which they're at the core, they're identical but they vary small details such as the size of the data that's being worked on in one go. The starting constants of the hash function and the length of the output. So you have SHA256 which gives you 256 bit output. You can have SHA512 which gives you 512 output and there are a few other ways you can configure it where you get like a SHA256 slash 512 which is the first 256 bits of a SHA512 output and there's all the various combinations that you can use depending on what you need for your use case. So SHA256 works on lots of data of 512 bits and that extends up to 1,024 bits when you move up to SHA512. So before hashing any message, we need to do a bit of preparation on that message because it has to work on blocks of exactly 512 or 1024 bits. So what we do is we take the piece of data that you want to hash and we append a single one bit to the data. This is sort of a marker. We then pad the data out with zeros until the total length of the piece of data that you want to hash is 64 bits less than the next multiple of 512 up. And then finally, a 64 bit integer representing the length of the data as a whole is appended. So then you've got a piece of data that is exactly a multiple of 512 or 1024 bits long. Let's wait and just take this photo. The next thing that we need to do is we split that message up into the 512 bit or 1024 bit blocks that we need to work on. And then there's a preparation phase which expands that data out to 248 bits. Now it does this by taking the original data, shifting it by a set amount, and then X storing it back with the original block and appending it. So you sort of get four copies where you sort of shifted and rotated and X stored it together. And then it goes into a function that looks a bit like this, maybe looks a bit complicated, but it's actually quite simple. It's called a compression function and it works individually on each block of data one at a time. You have these eight registers at the top which are the first time you're, the first block of the hash, it initializes them to some set constants. Now these are sort of like magic, nothing on my sleeve numbers which are generated from various mathematical constants. And they're designed to make sure that there's no accusation that the hash has been deliberately sort of tampered with by a third party and to make sure that it's actually secure. Subsequent blocks, those ones are initialized with the output of the previous block. Then we take our 248 bit expanded state and we iterate this function. So we've got those registers. We apply these XOR functions down the side. We mix in one 64 bit word, sorry, 32 bit word, 64, 32 bit words in the 248 bit. So we mix that in through XOR, mix these things through, shift them all right by one and that drops into the A. This state then becomes the starting state. For the next 32 bits and you keep on going, you iterate through, do that entirely for one block and then you move on to the next block. You keep on going, keep on going, iterating this function over and over and over again until you've done all the blocks of data in your function and then the resulting eight registers there becomes your 256 bit output hash. That's sort of how it iterates over and over. This function is really, really hard to sort of run in reverse because it deliberately mashes up and loses data in these sort of functions at the side here, which is what makes the hash function secure. Now, obviously once we've got a hash function, there's a lot of things we can do with it, just verifying data. But there's also some interesting data structures that we can build using cryptographic hash functions. One of these is known as a Merkle tree or a hash tree. You may be familiar with these structures as popular version control software like Git and some file sharing programs, actually like BitTorrent and things like that, use them for verifying data. They're quite useful for this subsektive because what you essentially do is you build a hash and it's kind of structured like a, one of the options is you can structure it like a binary tree. And each node in the tree is labeled with the hash of its child nodes. And so how it works, if you wanna verify a huge file, let's say you've got a big video file, let's say the video of this talk, stop on YouTube and you wanna distribute it using some sort of distributed file sharing program like BitTorrent. What BitTorrent will do is in order to make sure that what you're downloading is correct when you've got it, it will split the file up into loads of chunks at the bottom here. It'll take a hash of each one of those chunks, okay? And you've got like, on here we've got four chunks, four hashes, we'll split the video into four parts of hash to each one of them. We then take a hash of those two hashes appended together and we do the same on this side, so we've got those and then we've got this hash at the top here, which is the hash of the two two leaves below that, so we'll see that. So you've got this whole tree of hashes. Now that means that if you start downloading a chunk of the video file, this one, of someone off the back there, and there's someone goes wrong in transmission, you've not quite got all the bits in the right order. The hash will fail and you've got this, the hash that'll fail that and you don't have to download the whole video before you work out that something's wrong with it. So you can just throw away this chunk and redownload it instead of having to redownload the whole file. So it's quite useful and you actually tell which bit of the file is corrupted and you only have to download a really small extra chunk of it. Obviously, this structure's really good for a static piece of data, a video, for example, that's not gonna change, but it's not really useful if you're constantly changing the data because whenever you change a piece of data here, you've got to recompute this hash, this hash, and this hash. So every time you change a bit of data, you've got to compute loads of hashes all the way at the top. So another way we can structure a Merkle tree is a bit like this, it's kind of more a linked list type hash tree. And what we do here is we take the first piece, our sort of list, and we hash the data and that becomes the hash that we use for the first chunk. The second chunk, we take a hash of the data and a hash of the previous block. Now this is a very similar structure to how Git works when you commit something. It takes the hash of the parent commits and the hash of the commit message and the files you've committed, hashes that all together and that becomes a commit hash for your new commit. Apparently, you can also use this structure as the basis for a currency. I mean, I'm not expecting many people in the room to have heard of this, but how many of you've heard of Bitcoin? A few people, anyone got any? Yeah, one or two, okay, cool. So Bitcoin takes that concept of a hash chain quite a bit further to create what's known as a blockchain and it uses this blockchain to publicly store data about transactions between Bitcoin addresses, Bitcoin users. So, I mean, there was a talk on blockchain so I'm only doing a little bit on this, but going to what a blockchain is, it's basically a Merkle tree. The basis of any blockchain is going to be a Merkle tree. It, one of the other properties, there is no central authority. So there is no one person that can say that's a valid data item, that isn't. There's no sort of authority that owns the data structure. Anyone in the world can run a node and they can participate in the blockchain, they can validate the data and they can add data to it. Multiple forks of a blockchain may exist at one time. It may be possible that several different people have different views of what the current state of the blockchain is. And that means that we also need to have some sort of consensus algorithm to determine which fork is the one that we want to accept. Bitcoin's consensus algorithm is generally the deepest tree, the longest string, the highest block, is generally the one that's accepted. So if you've got two forks that you're comparing and one's got one more blocking than the other, you take that one and continue working with that one. Other systems use different consensus algorithms, but there's no talk on that, so. And the consensus algorithm must only require data which is contained within the blockchain. So there shouldn't be any private or secret data that you need to be able to run that consensus algorithm to make sure that all those blocks are valid. All the data should already be present on the chain itself. So briefly have a look at how Bitcoin, and actually this is fairly similar to how Git works as well. But Bitcoin works, it's a data structure built for transactions. So ultimately a transaction is a simple level. Somebody's got some Bitcoin and they've signed, signed a message essentially, that says I transfer three of my bitcoins to this address. And they've signed that with an elliptic curve key from the start, made a signature, and they've committed that as a sort of block. Okay, now when that's submitted to the network, it will sort of validate that, yes, you do actually have three bitcoins to give someone, and if they have that transaction will be accepted. It'll then be appended to a block of transactions. Once you've got a bunch of transactions in a block, they have a sort of a block header which contains a hash of all the data, a hash of the previous block, and some smaller information like the time, and a random string. In order to mine a Bitcoin, in order to actually generate a valid block, what you have to do is you have to change that random number over and over, and try and find a hash, remember I was talking about this earlier, how it's quite hard to do, that begins with a certain number of zeros based on the difficulty value of the network at the time, which is computed relative to the number of people participating in the network. More people participating, the harder it gets. Bitcoin is designed to try and make sure that one block is mined roughly every 10 minutes, and so it varies that difficulty, how many zeros you have to have at the front of your hash before it'll be accepted as a valid block. Once you've found a random value that actually hashes to something with enough zeros at the front, you can publish that block out to the network and say, hey, I found a block. And as a reward, you get a few Bitcoin yourself. That's exactly how the network works. So, yeah. Some of the question that kind of comes up, which is kind of a bit of an interesting abstract one is, why do Bitcoins actually have value? It's a question that's been asked to me mostly by people, my friends, who are not very technical, they're like, well, why is this craze behind Bitcoin? Why do people want them so much? And for a while I was having to answer this question and say, well, I don't really know. I don't really understand why they have bit value myself. So for this talk, I actually did a bit of research and had a look into the history of currencies, which is quite interesting if you want to go ahead and do a bit of research yourself. But essentially, we started off with the 10 pound note in your pocket. That was literally an IOU. It was, you could take that to the Bank of England and they would exchange it for 10 pounds worth of gold. So it was backed by a precious material that was rare and that actually gold is quite a useful material to have around, we use it for making nice jewelry, we use it for like circuit board placing, things like that. So it was backed by the presence of a valuable resource. More recently, governments moved away from that and they sort of said, well, storing loads of gold to back our currency is a little bit inefficient, whereas we could just say, well, we're gonna back it by guarantee. So we're gonna guarantee that pounds are worth pounds. And this is strengthened by the fact that if you've got a tax bill in the UK, you have to pay it using pound coins. Well, pound sterling. So it has legal weight because the government backs it. Bitcoin has kind of neither of these. It's not backed by a precious resource. It's not backed by a trusted authority. So it's kind of trying to rebuild the idea of the scarcity of a mineral by making the coins themselves scarce, but they themselves do not have any intrinsic value. So the value attributed to them is really only based on the fact that people who have them think they're worth something, which to me is quite worrying. I don't know about anyone else, but yeah, that's kind of the answer that I came up with to this question is that they have value because people think they have value. That's about it. So one of the final questions I propose with this talk would answer is, should you use a blockchain for a given problem? And the answer I'm gonna give you for most of your cases is probably not. A blockchain, a public blockchain comes into its own when you need to be able to reach a consensus on current state without some central authority. In most cases, if you're building a system as a company, you will be that central authority. Okay, you will be the trusted party that is allowed to write to your data store. So you probably don't need to use a blockchain for that. What you can do, if you need some sort of guarantees on sort of auditability and things like that, there are a few solutions you can do which are nearly a blockchain, but not quite, which are a little bit less computationally intensive. One of the examples you could do is, if you wanna verify that your data hasn't been tampered with, you could put it into a Merkle tree, either using a streaming structure like Git or using a block tree for static data. And you could periodically take the hash of your latest piece of data that you've inserted and you could publish that publicly somewhere to a blockchain like Bitcoin. So you don't need to run your own. You can just publish that hash into a public bit ledger and you've verified that every piece of data behind that can't be tampered with very easily. That's one option you could sort of go with. Another option, if you've got lots of people that you want a bit of right, what you could do is you could have a similar structure, data structure of the Merkle tree and you could say each block of data to be committed to this tree has to be signed by a key. So you've got four or five parties that are contributing to this chain. You can give each one of them a private key and you can say to all the parties only trust blocks which have been signed by one of these five keys. Okay, so you don't need to go to the whole effort to build an approved work function. You can just use regular signatures to build a sort of a web of trust effectively on top of your data structure. Okay, well, that was the sort of the last last kind of question in this talk. So I hope everyone's enjoyed the talk. Is anyone got any questions? Got one at the back there? So you mentioned the web of trust. In your opinion is let's encrypt breaking this web of trust? There's been quite a few stories about where it's been used because it's free to verify dodgy sites. I don't think it is, no. What let's encrypt does, I think it's the fact that, I think the problem actually wasn't let's encrypt, it was what was there before. So a lot of companies built up a business around the idea that they could verify identity on the internet and say that this website belongs to PayPal or this website belongs to some company. And let's encrypt doesn't do that. But people have sort of come to believe that having that padlock there means that it's verified that it's a company. Whereas what it really is, is it verifies that you are talking to the server that is responsible for that domain and no one's tampered with your connection. That's all it really signifies. So let's encrypt has really just highlighted a problem with the existing business models of certificate authorities. What's that, that is your question? Yeah, but in thank you. Anyone else? Any other questions? Well, I'm down here. Have to wait for the mic. I have a question. Regarding usually all the cryptographic technologies, they get outdated one after another. What is your view about the current technologies? When will they get outdated and what would be next? So I think one of the biggest things that sort of seems to be coming but not quite yet is quantum stuff, which that makes current crypto systems quite vulnerable. What a quantum computer can do is you can compute a function. How do I explain this very simply? So in a regular computer you have bits, they're either one or zero. That's how it works. Right at the very bottom level you've got binary. Now quantum computers work on qubits, which can be both one and zero at the same time. It takes a bit of getting the head around but what you can therefore do is you can compute every value of a function in one go. And the idea of how economy works, it changes the probability such that the values that you put in come out to be the right value. And it sort of breaks down the quantum function and creates the answer in that way. Now what that does for something like AS is you can actually create a quantum function which you can brute force AS much more efficiently than just trying every key that you would do on a normal computer. But it turns out that that only actually reduces the complexity from sort of, say you've encrypted something with AS with a 256 bit key. If you had a quantum computer right now that could break AS, it would only bring it down to the level of security of AS 128. Where it actually hits home, what's really difficult with the quantum computer is all the elliptic curve stuff. There are far more efficient algorithms for doing that on quantum computers. And so there's actually quite a few bits of research happening now on to create algorithms which are actually resistant to quantum computers as well as regular computers. If you're interested in that, there's quite a few things around. I could probably give you a few people on Twitter to follow who sort of post things about it. I could see me afterwards, but yeah. So next steps are sort of looking at the sort of post quantum cryptographic landscape, really. Because at some point, someone's gonna create one that works probably. And at which point everyone's gonna be madly scrambling to use something that's not breakable. Thank you. Just like, I'm just wondering like between the web server and the database, right? The communication is not encrypted, right? How we can increase the communication between web server and the database? So let's go back to really implementation details rather than the actual algorithms. But you can, it's between your web server and database, you can set up an SSL connection between them quite easily. MySQL supports SSL logins. Like let's say 3306, MySQL will use, right? When we try to connect from the application server to the MySQL, right? It's not encrypted itself. If you try to encrypt the things, right? It won't work. Let's think about the PSP kind of things, right? When PSP tried to connect it, it tried to connect on any port, right? But that's not encrypted. You can set MySQL up onto SSL. Person you want to talk to, David Stokes, who's hanging around in the exhibit area. If you go and talk to him, he's one of MySQL's like DevRel's, and he'll probably be able to help you get your MySQL set up with an encrypted connection. All right, thank you. More over there? Thanks. Do you ever see there being like a progression on the web of trust? So if like, you know, if I need to trust someone on the other side of the world, do you ever see there being a solution for ensuring like, you know, the original key exchange is not tampered with? Because it seems like that would be the main thing to attack rather than not the algorithms themselves. But at the very beginning, do you ever see a solution for that? It's quite difficult to resolve that sort of initial, I mean, for a long while, cryptography, we didn't have asymmetric cryptography at all. And I mean, you had like German U-boats with books full of today's encryption keys and you'd have British commandos storming them and stealing them. So for a long while, we didn't actually have a solution to that problem. So I think we've only just touched the tip of what's potentially possible. So hopefully there will be a better solution to come. All right, thanks. Any other questions? I think that's it. Okay, well, I'll just finish. If you want to follow me on Twitter, I'm at give up already. I've got GitHub there with a few different bits and pieces on there. And my blog, which I believe the slides for this talk are up on there, they will be very soon if they're not already. And all the slides for my other talks are up there. You've probably also noticed, I sort of run PHP Auxer. If anyone's interested in coming, the event is on the 13th of April this year, so about two months time. And we've got a few. Last time I checked, there were about 15 early bird tickets left. If you use the discount code PHP UK 2019, you'll get a further six pounds off that price. So that's quite cool. And if anybody wants an elephant, I'm selling them. So if you want to come see me later, you can buy an elephant. They're really cool. Thanks for watching. I'll see you guys next time. Bye.