 this adventure of afternoon is that I can see the audience which is way more intimidating than in the dark. I get a 10 out of 10 from the speakers cards that's fine. But let's go serious. This was very serious. This was military great encryption about 2,000 years ago. First introduce myself I'm Lord Burke Blue. I'm also known as Mandel Moach which is also not my real name. I do weird things with computers. I work as a crypto and security architect at the moment. And now my screen is failing me. I'm not kidding. Yes. It's on off, on off, on off, on off. Good. I'm a hack 42 board member. It's the best hacker space where also a lot of devices fill. So that's totally fine. I'm a foyer freedom of information fanatic and I like to troll the government as hard as I can. And I like to talk about with interface and connections. All that is irrelevant because today I'm talking about cryptography. Cryptography is the secure communication in the presence of enemies that wants to know your information. It can be your friends. It can be government. It can be your provider. It can be an ad company. It can be anything. So you make your data unreadable for interceptors and you can also make verifiable documents so that nobody tampered with them or to both at the same time. Why do you want cryptography? It's very important. We all use it these days in your app browser. You only can see nowadays sites with a small log icon. So you can see less of the real bar. It's for privacy. Nobody gets any advisor and for security so that nobody else can impersonate you. Both are also false because revoking a signature, for example, is impossible. So it gives you less privacy and trusting only on cryptography to have a secure thing is very stupid. Don't do that. The basics. There's symmetrical encryption. You all know that if you encrypt the zip file, you have to also send a password to the other party that needs to decrypt and then zip the file. So both parties need to know the secret. You need to exchange it. It's a very fast way because it's easy, optimizable. But it's hard to keep the secret to secret. How do you send the secret for a zip file with the same email as some standards in some organizations do or do you send it via SMS or all those things? You have asymmetrical. It's public private keys. Your web server uses it for certificates. For example, TLS uses it every point in time and it's an easy way to not share secrets. Then there's the hashing. Hashing is a way to make checks from data. So you get a number that represents a checksum over the data. But if you have that number, you cannot reconstruct the data. It would be awesome if that would be possible in the world because then we had very small files, but it's not how it works. So if you have a large file, you end up with a small checksum and that's where you can identify the document with, but not reconstruct it. If you start to use cryptography, there's some basics. Do not invent your crypto yourself except for some people on this camp. Do not write your own crypto except for some people on this camp. But use libraries and well use software. And if you don't know what a well used library is and what the good software is, use lip sodium. I'll explain that later in this talk. About the hashing. It works one way. From data, you get a hash. If you change one bit, the output is different. In this example, there are three bit changed, the output is different. With symmetrical encryption, you can do a lot of things good. It can be very fast, but you need to use the right options. Because the left and the right image are the same image encrypted with AES, only a slightly other option. And in the right image, you can clearly see the ECB pinging. So the basic is don't use ECB. It's dangerous. And keeping the secret to secret is very hard because you have to share it. You have to maybe write it down, send it in as a message or text or signal message or it's in your memory, it's in your CPU. You have to type it in your keyboard or in program input in a configuration file. It's very hard to keep a secret to secret. It's one of the hardest things in computing. A symmetrical encryption is efficient. It's the best thing since sliced bread. It's about as slow as slicing bread. So breaking bread is way faster, but slicing bread is nicer. Also here it counts as keeping the key a secret is work, but it's way less work because you don't have to share it with the party, the other side. In this example, that's Alice. But how do you know who the other side is? If Alice sends the public key to Bob, how do you know it's the public key? You need to know that there's no man in the middle, so generally you use signatures for that, so you have a cryptographic signature. But also, still, this is slow, so normally you want to agree on the shared secret between Alice and Bob. They invented something very, very efficient for this. It's called Diffie Hellman, and it can be illustrated with just paint. This looks nicer on the white background, so go to Wikipedia and look it up yourself. It's easy to do on software. There are some standard functions for it, so don't write it yourself. And if you're at higher levels, you don't even have to think about it. You only need to write options, and I'll explain some of them later. For public-private keys, you have RSA and elliptic curve. RSA numbers look great, large, great. So 2048 bits, RSA looks very large, instead of a 128-bit EC key. However, as you can see here, an RSA key doesn't contain so many different options, because it only uses prime numbers, and there are not so many prime numbers in the first 1,024 bits or 2048 bits. So there's a table to compare both. Also, finding primes is hard. Yes, there's a list of primes, but you need to calculate primes every time, or you need to go to pre-computated lists. And the elliptic curve works with just getting some random data, not checking if it's prime, but only if it matches some easy metamethyl function, and if that's okay, it's a good number. So the chances of getting the right number instantly is easier. If you do this yourself, you generate once an RSA key in 4,096 bits, it's off again. Or if you generate an EC key on your computer, you can see the time difference, it's night and day. What is elliptic curve? It's new there. It's a nice metamethyl thing. I'm not going to explain it here, because it's a basic talk. It's used everywhere on the internet, your phones use it, your browsers use it, your email client uses it, everything uses it now. I wonder why the IPv6 didn't do this. It's smaller, it's faster than RSA, and there's some different curves. Most are from NIST, that's the American Institution for Standard. They have had some famous help from the NSA in the past. There are some others, like 25519, basically it's the best these days. Then Bernstein has a nice safe cryptos where you can check which properties of elliptic curves are good and what are bad. Of course his own is the best. I think he's right on that. Last time I had more pauses between all the slides. What you can do with crypto, there are four basic things. Encryption, decryption, so it's encrypting to send something to another party, decrypting to decrypt what you receive from the other party. You can sign and you can verify the signature. A public key is always calculated from a private key. This is not true in some metamethyl weird things, but normally if you have a private key, you can calculate a public key. If you cannot, somebody used the wrong settings. They're always a pair. Since it's a metamethyl, they're rivered from the private key. They're a pair. The other way around doesn't work. That's why if you have a public key, you cannot reconstruct a private key. That's a good thing. And it's generally safe to publish the public key. It also what happens on your web server, publish the public key from the web server and it uses the private key to talk to you. With symmetrical encryption and decryption, it's calculating with large numbers. So a number that consists of 128 bits or 256 bits is a large number. The only thing it can do is do calculations with this number to another number, the message, and it's repeated for every part of the message. So if you use AS128, it does 128 bits, then another part of the message is the same bits and again and again and again. With asymmetrical, it's starting to be boring, but it's calculating with large numbers and also it's limited to the size of the number and it's repeated as necessary for the rest. Decryption, asymmetrical, you calculate with the public key. The message is limited to the size of the number and repeat. Signing, that's different. Signing is also calculating with large numbers. You need a private key to make a signature. What normally happens with signing is you calculate a hash from the document you want to sign. It can be a message, it can be a page, it can be anything. And you encrypt the hash for the public key. So if you have the public key, you can decrypt the message and verify it. So with verifying, you take the public key, you calculate the hash from the document, you decrypt the hash you could send as the signature and once you do that, you compare the two hashes. That's a small thing. This is only valid for RSA. With EC, it works a little bit different, but you will get the message how signing and verifying works. To show some proof, I generated an RSA key 512 bits long. So that's insecure by default, so I can show it here anyway. This is a private key. It's written out on the right. What's in there, you see a modulus, you see the private exponent, a public exponent, a prime, another prime, and then some other calculated numbers. A public key. Yeah, that's what a public key looks like. You once might have seen it. It's encoded. If you go to this website, you can just paste the stuff that's in there and it shows you, hey, something in there, it's 512 bits, and that's the actual public key. After five days of camping, I got a little cough. Yeah. If you sign some data, so here I'm signing some data with that private key, you can check it because it gives out always the same output in this case, which is an unsafe default, so if you don't know what you're doing, then use lip sodium. So you get the signature, and for preference purposes, I also calculated, check some here again. Decrypting is, as I said, it's calculating with large numbers. So I load a public key. Once it's loaded, it has a number, which is the public key. It has an exponent we saw before. Then there's the signature. It's just copy-pasted, and then you do a power off function, and, hey, that's a large number. Now, if you convert that large number to hex, you see 0, 1, a lot of Fs, and then something 0, 0, 3, 0. Hey, when you look better, the hash is in there. So we decrypted the signed hash, and now we can compare it. For some reasons, you want to pet your string always to fill up as much of the message as possible, and you try to avoid 0, so Fs is avoiding all the 0s. You can use everything except 1 byte or 8 bits for this function with RSA. And then again, it's ASM1 encoded, so if you just copy-paste the previous string that came out of the decryption and cut off all the Fs that fill it up, then you get, hey, there's an octet string that's the one I highlighted before, and it's the same as the hash. But that's the power function. And yes, large calculating with large numbers powered, it's slow. Computers are efficient these days, but if you have a fast computer running very fast calculations, it's way faster than a fast computer running slow calculations. For verifying only one hash and one decryption it needed, so this is what, for signing a verifying is okay. If you need to encrypt large data, asymmetrical, so like you're downloading a few gigabytes movie or something like that over HTTPS, what happens is you encrypt the document with a symmetrical encryption, like AES or it's a well-known one, or some others. What happens is you generate a random password to encrypt the document. That happens, it's just a random function, so it's a long random piece of it. You encrypt the document with it, and that's a fast function. CPUs have extensions to speed it up. Once you have encrypted the document, you encrypt the random password for the other one's public key, and you include the encrypted password into the document. So on the other side, when somebody receives this document, they get a private key, decrypt the password, and then decrypt the document with this password. How do you do this? Use libraries. Don't do it yourself like I did. You see everything goes wrong. It uses repeatable functions. It uses 512 bits of keys. I got no warning. I was showing you all the warnings on the screen. What's wrong? No, OBSL doesn't care. Use the good libraries. Use the same default. With Libtodium you can use no wrong defaults. With OpenSSL you can use some functions, and if you use the right options, it's not using MD5 anymore, but SHA2 or something like that. What is Libtodium? I copy-pasted the wall correct marketing from them, and also they have support for a lot of programming languages. So you can communicate with other programming languages. As said, to keep your private key private is hard. Hardware can help you. You can use TPM, which is included in a lot of computers these days. You can use smart cards. You can use a UB key, S key, Nitro key, or you can use the real hardware security modules from big companies like Tils and Cy for UTIMACO. The best practice, when you're using hardware, even if it's smart card or some module in your phone or anything, let the hardware calculate the keys. So they generate a private key, and that private key is never leaving the hardware. It forever stays in this working prison for secret keys. You do the decryption with a shared key on the CPU. So if you have a large document, you're not sending the whole large document through the special piece of hardware, which is not as fast as your normal computer. And for very good standards, use Libtocurve RSA slow. Screen is dying. Again, I'm now on three. I cannot stand here today, so I'm leaving it. So the best practice is use Libtocurve because RSA is really, really slow. If you have to need some support for the hardware, OpenSSL has support for via Peky CS 11. Some a lot of other software have that. The sad thing is 25519, the Libtocurve is not supported on most of the hardware, but it's coming. I see it's coming, and it's slowly supported somewhere. Inside this working prison for private keys, they can never escape. So that's a good thing. So it can never be stolen. It can never escape. It can never be leaked. You always need the hardware to decrypt it, which is a bad thing. If your hardware mortgule breaks, you cannot decrypt it anymore. So if you do this for your backups, and this piece of hardware breaks, your backups are gone forever. So mostly you cannot backup keys from these hardware devices because they have to stay in there. If you want to do this, consult some expert for real-world applications, or just ask them, all right, internet forums. But always consult some people to help you out with this. Yes, crypto is secure, but never rely only on cryptography. As this hack with TPM shows it, there are sealed keys used with BitLocker. This is a hard drive encryption. So what happens is a sealed key is just some key that's encrypted with the TPM. But once you put it in the TPM, and you say, hey, decrypt this for me, and the TPM says, okay, here it goes, and you get the decrypted private key back. With the decrypted private key, if you can snoop that off, take it out of memory, you have access to the encrypted hard drive. So this hack showed with TPM, they could read it out from the message bus with the logic analyzer or something like that. It was a very clever hack. As I said with TLS, it's also, you have a lot of options, and I wanted to explain how to read such a cyber string. This was, I believe, from internet.nl, the first one for TLS 1.2. It's E-C-D-E-E-E-A, R-S-A-A-E-S in G-C-M and SHA384. Let me explain them. This one is elliptic curve, Divi Helman, so it's a Divi Helman, but for elliptic curves. And the extra E implements emferal, which means that for every session, it generates a new throw away private key and a public key, and then agree on a shared secret, and they throw the private key away immediately after that because they have to share a secret, and it's never recoverable anymore. So even if you sniff the data and you get the computer years later and you get the private key, it doesn't give you anything because there was a new private key used for this. In the end, you have a shared secret, so you then can use that for the symmetrical encryption. R-S-A, R-S-A is used for authentication certificates, for example, normally not so much used in TLS. This one is much used. It's using AS256 in Galois counter mode, G-C-M. It's a good mode. It works. And every data that's encrypted is encrypted with AS256, and it's encrypted with the shared secret. So both parties know the shared secret from the previous step with the Divi Helman, and it's being decrypted with the same shared secret. And to know that nobody's tampered with your data, you use SHA384. It's one of the SHA2s of different sizes for hashing. So you know the data has not changed by adversaries or by errors, or you can verify that you decrypted it correctly. If you want to use it, yeah, use elliptic curve. Get away from R-S-A. Use X25519 if it's possible, supported by your software, and else use the NIST-P256. If you use TLS, just use Poly3005 and SHA-CHR20 to get it there perfect. In a lot of other situations, if you need hashing, just use SHA22512. Yes, it's a large number, but computers they're not so difficult. And yeah, use AES or CHR20. And if you use AES, use it in the right mode. Not in ECB because then you get ping-wings. If you ever see one of these things, R-S-A smaller than 2048, run away or have somebody really explain why this is. If you see SHA1, MD5 or something else, don't accept it. That's triple, that's all those things. No encryption is for most things, not an option anymore. Even for a local database connection, use encryption always. If you see things like military grade encryption, then if they don't specify a year, run away, it might be just a CSER cipher. And it's also that if they specify military grade encryption, they normally don't explain what they're using. So you cannot verify it, you don't know it. As said, it's cryptography is not the ultimate solution for everything. XKCD has a nice, if I have a $5 wrench, I can hit him in the head and he will give the password. So the goodness of the encryption doesn't matter anymore. Sadly, XKCD is not finished yet or good. They have good new ones. It's impossible to revoke signatures. So once you sign the document, you cannot unsign it anymore. Revocation of documents and saying, hey, this was not my signature anymore. It's just a social construct. Do you believe the revocation or not? Because the public key is widely known because I said you can publish it. The signature is public because you send it with a document to prove that it's you. So there's some unintended consequences with this. Google uses DKIM to fight spam and you can verify it was really sent by Google and it's the right Google user and you can check a lot of things with that. But you can keep on checking this. There are some journalists that request Google to publish their private DKIM keys. I really support this ID. So please Google support your DKIM keys. I think it's only very hard for Google to do this. But in this society, I think we need to find a solution for this because these consequences can have grave consequences in the near or far future if we don't watch out. Sorry. Are there any questions? And if there are no questions, I provided you with an example question. Just one very important example question. You can run slowly. We have time. So is base 64 encryption? Yeah, depends on what documents read. No, it's not. If something is in base 64, it's just an encoding. You can just get it out as soon as you look at it. So if you write down base 64, a hacker can never get any data out of this. Then you're lying. So please government, learn very fast and don't do this ever again. Who authorized this talk? I think it was the chairman of the faced Teddy. So cool. Are there any more questions? Yes, there is a question. So imagine you're a Windows user who is following this talk and you want to go do this and send messages. Is there a good interface you can use? Yeah, you can use all those programming languages like dot net, visual basic, lip sodium, as a library for that. No, I mean a clickety click interface. It's called the web browser. You broke my Harold. I keep breaking everything with his sword. Audio broke, now the screen broke, now the Harold's broke. No questions anymore. Shall I close this? Yes, yes. Hello, I'm Neil Harold. I'd like to thank you all for this wonderful talk from Mendelmobach. I hope to see you again at the next talk whenever you're fit again to Harold. Thank you Nancy.