And so, boring slide about me. I, nowadays, today, mostly work as, mostly work as an C++ evangelist for my own platform, meeting C++,

the biggest C++ conference in Europe, which I do organize since 2012. I've been involved with C++ since 98. I've learned some years at Vodafone, and since 2007, I used to work as a freelancer in C++.

And regarding this talk, I'd like to start with a short disclaimer. I'm not an expert in encryption, I guess there's probably no experts in description anyways. And this is an overview, and I'm going to cover crypto++, botan, and libsodium in this talk.

And yeah, last fall, I was looking at the options in doing encryption in C++, and what I found out is there are several choices which you can use for encryption on C++, but all of those choices

are kind of difficult often to set up, or it's you basically, you have to do a lot of research to know what you want to use or what you exactly want to implement. So basically, the implementations we have on C++ currently, they enable you to do encryption

on the right way if you do it correctly, but they also enable you to do it in the wrong way, and you can do a lot of errors in the setup, or use the wrong source for randomness, for example, or anything else. And so I thought, well, that's an interesting topic, and as we live now in a more and more

security-aware area, then I thought it's probably well-versed into looking into it and maybe preparing a talk about it, so to motivate me and to really, you know, keep doing the work on encryption there.

I also want to stress that this is a talk about using encryption, not implementing it. Of course, you can implement your own very secret algorithm of encryption, but unless you're really knowing what you're doing and you're having the balls to open source it and to prove that it's mathematically correct,

you shouldn't do that. You shouldn't, you know, try to do an easy encryption. There are tools which offer you strong encryption, and you should use strong encryption, and there's a lot of libraries which have been tested. And also, as we learned yesterday with a keynote,

you and your data are basically the product of today. And as a software developer, you should be aware that you are a special target for services, but also for everything else, which makes money on a legal or illegal way on our platforms.

This includes, like, botnets, et cetera. Interesting data, which could be stolen from your machines, just like emails, which is usually sold in bulk. Passwords and logins are things which are very, very precious. And of course, when your machines get broken,

then there will be an automated lookup for that, okay? And also very interesting, hardware resources are today also an issue. So if the machine, the server, or the IoT device if it gets hacked, it probably will be used

for either Bitcoin mining, if it has enough power to do that, or it will be used to be part of DDoS attacks. So even your smart home, which, you know, has like very, very basic hardware

and not a lot of power, will be able to be useful to those people, so, but that's actually a different topic, you know, and yesterday's keynote has already set the focus on that, and I expect to hear this evening a bit more about it. And there was a very, very good talk

about IoT connected devices and security at the Q-Dev days last year in Germany, and I have linked that in the slides. And also what you should think about is that a possible attacker, which breaks into your application or into your data, which is not encrypted or is encrypted,

he lives always in the future. It's not like that you, you know, commit code and you immediately get attacked. No, the attacker will always be in the future. And maybe it's in two years, maybe it's in four years. And as we know that with time passes by, technology advances, we get faster in technology, we get faster in hardware, so that if you're planning to use encryption today,

you have to use it in a way that it is still secure like in 10 years or 20 years. It depends on the data you encrypt. If it's just messages which are flowing in real time through your processes, then maybe it doesn't matter if it gets cracked in 10 years, but if it's important personal data

or other things which you encrypt, you should take care of having a really strong encryption that still probably is not able to be broken in 10 years. And I wanted to start with a very short update

on encryption. There's a lot of different words and phrases. So symmetric encryption is when you have only one password and it's used for the, basically the key alters your plain data

in some kind of an algorithm, like for example this AES algorithm. This is very popular to do, and there's, but there's also another encryption method which is asymmetric, which uses usually two keys, a public key and a private key,

and the best known algorithm for that currently or the most known algorithm for that is RSA, but also there is some cryptography with it in this area implemented. So those are the two most used algorithm types

for encryption today. And also a short word on cipher modes. There is a lot of algorithms which are block ciphers which just operate on a constant block of data and encrypt this part of your data

and then they take the next block of data. And there's also another type of algorithm which is called a stream cipher, which generates a key as a stream, as a constant stream, and then encrypts with this key your input data as a stream.

And also a short word about HTTPS. I know that I've heard it personally in a project that some people think that HTTPS is encryption, and HTTPS of course does encrypt your connection and the downside of it is just the transport which is encrypted. So if you put important data over HTTPS over the internet,

you always should try to encrypt it first and then send it over HTTPS because there's a lot of known attacks against HTTPS and for example, for UDP it doesn't work at all.

Which brings me short to the topic of passwords. Passwords and private keys are basically the keys or the tools used to access our encrypted data and they need to be protected in a certain way. And so I didn't want to talk about encryption

without shortly mentioning a few slides about how you could or should handle passwords. First, if you just have some server which does authentication like a web application or something, you should never store your passwords as plain text or as a single hash.

Today, the most common way to store passwords in that way for authentication is to hash them with a password in a salt and it's also very common to not only hash them once but to hash them several times. And there's also some algorithms to do that and some hash algorithms which are especially used for that

and you probably want, in that case, you want a slow hash algorithm, not a fast hash algorithm. But that leaves us with in our programs is one problem because we have logins to databases, to some web platforms,

maybe we wanna live tweet our results and we have some secrets which we want to share with Twitter over OAuth. And we kind of, it's probably common today that we just put them in a config file and don't encrypt them. But if we actually want to encrypt also this data,

how are we gonna encrypt that? Because at the end, we end up again with a private key or with a password, which we should encrypt again. So if you use a symmetric algorithm, you have a problem kind of where to store the key.

Every asymmetric method will probably give you a private key or something similar to a private key, which you again should encrypt because private keys are also something which is searched by botnets on your machine. So if you get broken into by a botnet, it's very, very common to search for private keys and to extract them.

So, and of course you could store it as plain text as an option. One option, for example, would be to have some kind of mutate algorithm, which mutates your plain text into your real password. There is on some OASIS APIs or daemons,

which you can install for this purpose. For example, PuTTY has a daemon to do this. And yeah, I'm still thinking generally on that problem, how the best solution in this field is. Which brings me to the main topic, to encryption and C++.

When you start reading into the libraries which do encryption and C++ or C, you'll very, very shortly find out that the lingua franca of encryption is basically everything runs on unsigned char. Even the C++ libraries, they don't like have some unsigned string or something. It's always an interface on an unsigned char.

Usually, a C-like interface, or in C it's like common, you have a pointer to the unsigned char array and the size. And that's actually in this case, the best interface. As mostly our data, our own data,

is not held in unsigned char. And if you would have, if you would choose a different interface, this interface mostly will force you to copy your data into an unsigned char buffer. But for performance reasons, we probably don't want to do that because we already have some buffer which you want to send over the network

or put on the drive. So in that case, it's actually the best interface to save performance. So you can basically, well, it's common to just do a cast on some other data and give it the size. And then the encryption runs on that in the memory.

And while I was doing my research, a short word on the C++ standard. The C++ standard does offer exactly nothing for encryption. So we have a random header in C++ 11. But you shouldn't use that for randomness

for encryption, okay? There's actually the lib C++ and the libstdc++, which under Linux have randomness, which theoretically would be good enough. But that would possibly expose you on other platforms. So if you had to run on exotic platforms

to possibly having either a broken randomness or no randomness at all, for example, if you're using W under Windows, it always gives you the same numbers. It always gives you the same numbers. So there's also, I think the same is for Boost. Boost has a bit of advance in that direction, but actually all libraries which I will present to you

have their own pooling for randomness and you should always use that instead of trying to figure out your own ways. And also Boost has no libraries about encryption.

There are some hashing algorithms in there, but that's it. And then short overview on crypto libraries. There's the cryptopp library, the botan library, and the libsodium, which actually is a fork of libsalt. And those I'm gonna present to you as an example.

Then there's also the openssl, which also is known as libcrypto. If you ever had to work with those APIs, you probably don't wanna do it again. There's for Qt, a library called qca. And that's based on Qt 4,

but it's also available for Qt 5. And how I saw in the last talk, actually encryption is also offered by Poco, but I haven't yet looked into that. And short view on the three libraries

which I would like to present to you. As you see, all of those libraries are based on C++03 or C. So the code is, in that case, it's nothing fancy, it's nothing new, it's not C++11, but that's actually, in that case, something with what we want. We want to have a mature library for encryption, not something, I don't know.

I haven't seen any libraries doing or implementing any interesting encryption algorithms for C++11 or 14. And yeah, the licenses are always interesting to see if you can introduce such a library to your organization. I think that CryptoPP and Botan,

this Boost license and BSD2 licenses are kind of equal and probably not really difficult to introduce to any organization. Then the libsodium is published under this license which is called ISC license.

That license actually is similar to MIT or BSD, but it's, in my opinion, a bit unusual and unknown. So if you have to get approval for libraries

in your organization, you might should do some research on the license and so you can present your management that it's actually an open source license, which is kind of the same thing as MIT license and BSD. And I've chosen to present you the AES algorithm

with the CryptoPP and Botan for RSA and the Cryptobox approach for libsodium because libsodium is in the difference to the other two libraries actually based on this Cryptobox approach, but more to this later.

Which brings me to AES, the Advanced Encryption Standard. It's a block cipher, it's symmetric, it's widely used, it's I think the most known algorithm for encryption. It operates on modes, which is one of the difficulties with IIS that you really have to know what modes to use

and that even in the examples of the libraries I saw sometimes some modes are used which are okay, nothing really bad, but you might want to use a newer mode. And that's also something that you're gonna see is AES needs to be initialized with the random data.

And yeah, so first I think I should give you an overview on the modes and some details on them. There is a mode called ECB, Electronic Codebook, which is actually the only mode you should really,

really avoid. If you use that mode, your data is basically crackable within seconds today. And then there's other modes like CBC, OFB, and there's two newer modes, AIX and GCM modes, which are the only two modes which actually give you

authentication and your encryption. But let's just have an overview on all those modes. So as mentioned, ECB, this is a picture of a penguin. I think you all know that picture and the original. This is the same picture encrypted in ECB. So ECB is not really meant for encryption and sometimes it's still used in code,

not really written well for encryption. So you shouldn't use it. And it's just here as an example that it exists. Then there's another mode called cipher block chaining, which is thought to be secure, like every other mode I will present to you now

is actually considered to be secure. The problem with CBC is that it does not have any parallel encryption and most of the other modes which we will see do not offer either parallel and or decryption, though often we have like parallel decryption.

And the hardest thing against this mode is actually that there are known attacks, especially malleability, which I probably have to explain to you. Malleability means that if I get your encrypted text, I'm able to attack you in the encrypted mode.

I'm able to switch bits or bytes in your mode and you will not be able to register that. So if I know your message format, it would be as an attacker possible or in a position to change numbers in it or to insert certain data into your processes. So for example, if you have a bank transfer,

I probably would be able to alter the amount which is in that transfer. So CBC is a mode which is well known, but especially with the malleability, I think it's for today outdated. The OFB mode is one of the modes

which actually runs AES in a stream cipher mode. It uses a key stream, which is computable in advance, which again makes it for certain applications interesting. There are also fast hardware implementations. And on my research, I found that some people would understand more of this,

say that the security model is questionable, which especially is if you have a misconfiguration and the key stream cycles are too short, then again, you have an encryption implementation which you're using, which is not actually doing what you want and your encryption is again, attackable on that point.

So then there's a cipher feedback mode, which is basically doing what CBC is doing just in the other way. It has a small footprint. It offers, again, parallel decryption. It's not very well known. It's not very common I found on a site, but actually in the example you find

on the website for crypto PP, that is the mode which is used in the example. Then there's the counter mode, which is a mode that's supposed to be secure. I couldn't find anything negative about it yet, but it's also basically the root mode,

which the newer modes note use. And it offers as the only old mode, the parallel NN decryption, though it's for processes when you really want to use the many core age with an encryption, then the counter mode is actually a big advantage for you.

But of course, as I told you, the two newer modes and the big advantage of those two modes is that they add authentication to the encryption, which is actually a big thing if you're transferring data over the net, and some people probably put encrypted data

on a database or on the drive. Authentication will tell you if your text got altered between your encrypting and your decrypting. And this is the only two modes, the EIX and the GCM modes, which are newer, I think,

the older one is back from 2003, though it's not like brand new. And so if you use EIX, you should try to go for a EIX or GCM. Depends a little bit on exactly what you want to do. You have to do some research on those modes.

Counter mode is also very good, and CBC is the obvious. I mean, we're not always able to choose the modes which we want to use. Sometimes you just have to implement what a server or other interfaces give you. Then this thing with initialization.

Every time you use IES, you have to supply it an initialization vector, which is an unsigned char array of 16 bytes. This must be random and not sort of random. 16 bytes, that would be an MD5 hash.

That's a bad idea. Don't do it. This can be public, and actually it's quite common to send it with the encrypted data or to store it with the encrypted data. You shouldn't reuse it, so it's not something which you generate once at startup and then use the same initialization vector

over and over and over again. And as I said, usually all libraries provide you with facilities to generate this random data, and you should definitely use those facilities for generating, for example, the 16 bytes for the initialization vector.

And of course, you can think about something like pooling that generates a lot of data in advance, and then you just set and just always generating 16 bytes when you need it. And this brings us to the first example.

So the keys in IS are usually 16 or 32 bytes, and today you probably should go for 32. And as you see there, crypto++ offers a class called auto-seated random pool, and both C++ libraries are very, very object-oriented,

and crypto++ is even modeled after a similar library in Java. Then they also have, again, a class to store this key, which is another important thing.

It's not always the best thing to store your keys and other things than just in plain text in the memory. Some libraries offer types for that, and one of the problems, for example, is that after your usage, you should always make sure that this data gets set to zero again, like each byte that you don't have

like keys leaking in your memory, which are still there after your process is doing something else so that attackers cannot read your keys out of the memory that easy. And then, yeah, just byte is in this case just a type there for unsigned char, and also we just generate the byte block for this.

Then we have just a short message and this time it's just a char. We take the length of it, and then the encryption. In cryptopp, we have this mode,

which is actually a template, and is then with an AS type feed, and that declares a class called encryption, which is enclosed in this template. And this just instantiated with a key

and the key size again, and IV. So as you see, there is often places where the interfaces of cryptopp, but also botan are very C-like, and it's, in my opinion, a little annoying that they don't like, we already have a key object, and actually we should be able to use it there.

And then you just call process data as a plain text, and after this call, your plain text area will be encrypted. And after we have sent it somewhere else over the wire, of course we want to decrypt it.

Just to save some space, I made a type def here for the CFP mode, and then we instantiate the decryption type, and again, we just call process data and we're done. So in this case, quite easy to implement and quite easy to run, but if you want to use AES in your own code,

you probably want to wrap that, not just have to write that all the time. And a short overview on AES. Cryptopp uses, just use randomness as IV and key.

Also, important thing I want to point out that the key is not a password, so to try to generate a password interface for AES, which basically puts your password on 16 or 32 bytes, is actually a bad idea because human keys are not really, or human readable keys are not very random.

And so there are algorithms which can turn some input into a key, but actually you should, in that case, if you can, prefer randomness. And yeah, regarding the modes, select the right one for your use cases can differ.

It also depends on how much performance on your platform is available if you're running on an embedded platform. For example, you might want to use what is in the hardware already implemented. You should prefer the newer modes, which also offer authentication, and also a known issue with some algorithms in the block cipher area is padding attacks

that if you add certain paddings in the byte area, you can avoid those attacks and their implementations. But for example, the Cryptopp example does not use it. Which brings me now to the second algorithm.

RSA is an asymmetric cipher. You generate two keys, again, from some random source usually. And the one is the public key, which you share with everybody else who short encrypt the message to you.

And the private key is a key which you don't want to share with anybody. So you should definitely think about where you want to store your private keys on your system, how to secure them, and how to make sure that they're not getting leaked. And also, it's probably a bad idea if you put the private key in memory

or in your application if you compile it hard. And some companies have done that, like Sony. And once this key gets leaked, because also keys could theoretically be calculated, and if you don't have enough randomness in your key, your key probably could leak through that if you're running a bigger platform like the PS4.

So you definitely should also, if you're having a lot of devices in the field, you should definitely think about methods to exchange a private key if it's broken or somehow penetrated or something. And as I said, the public keys for encryption

and the private key is something you should keep safe. And as an example, I will show you Botan. Botan has a namespace, crypto PP2. And yeah, the namespace in this case is just Botan.

But very, very, very important, actually, Botan has this type called library initializer which sets up some things in the background for the library. And you always have to create an instance of this type before you use Botan. And in my opinion, you have to use it. You have to create per thread one instance.

I'm not sure if it's like a single internally, but I think per thread that will use your encryption, you should have one instance. It can throw so that when it fails to initialize the library correctly, it will throw. And yeah, it should handle that or just let the application die.

That's your choice. And as Botan and crypto PP are both collection of algorithms for encryption. So they don't give you a lot of help with encryption. They're just giving you the algorithms and to correctly use them is still your job. And if you're making errors with it,

it's kind of like the C++ philosophy for encryption. If you want to shoot yourself in the foot, you can do that with those libraries. But of course, my question when I started to implement RSA with the OpenSSL piece a few years ago,

my first question was like, where do I get this random key from? And Botan actually has a nice class called RSA private key, which you give the random number generator from Botan and how many bits this key should have. And it will then just give you a private key. And this private key again has a method called public key,

which will give you the public key. And in the example of Concrete, we see in this case just a short SDD string and which brings probably the attention

to the bit number here. And that's actually, it's like the example which is on the website and it's, in my opinion, a bit outdated. In my opinion, private key, which you newly generate today should be 4,069, no, 96 bytes.

And, oh no, bits, not bits, bytes. And if you can go higher, it's probably a good idea. It depends a bit on the performance and how much you want to spend on encryption. But I think a key of 1024 is not enough today,

except that your data is like super unimportant. Then you can probably do that if encryption and speed is important for your performance. And yeah, so there's some sanitization and coding for those keys.

So you just have to call those functions and you receive, again, a string, which now contains the encoded public key and the encoded private key. Then this gets stored in a data source memory, which is a class which kind of handles the memory for you and also takes care of,

it's kind of like a smart pointer, but for data it takes care that the data which you put in it actually gets deleted when it runs out of scope. So it's kind of like a guard. So that, for example, some important data which you want to protect in the memory is really deleted.

And not only deleted, but also put to zero or changed in the data format that not your keys are still in memory when the process ends or something like that. And then, again, of course, when we want to use those keys,

we have to load them again back into some class which actually is able to do the encryption with it. So there's not only an encoding function, there's also a loading function, which in that case gives us a public RSA key and a private RSA key.

And as we can see, that's all like pointer-based. So as those libraries are all kind of a little bit old in the C++ area, their style is a bit outdated and you definitely have to see if you have any memory leaks, et cetera, in there.

So you have to make sure that your data actually is handled correctly in that case. And then I modified the example here and put auto in, otherwise it wouldn't fit on the slide. We're doing a dynamic cast to actually get the type which we want to later then, again,

wire a function to get the correct algorithm. And this is the next step. After we have done the dynamic cast so that we have the encryption and the decryption keys in the correct format, then we have to still tell it what kind of algorithm we want to use.

And after that is set up, then finally we are able to encrypt something. So in this case, they choose not to encrypt the same, basically they use now a buffer for the message and the encryption function

gives you back a class called secure vector. So again, some class which takes care of your encrypted memory. So, and again, we have like the C-like interface giving the message, the size of the message and the random number generator.

And if we want to have the plain text again, then we have from the decryption object to call the decrypt, give us the cipher text and the size and brings me to the crypto box approach,

which is a bit different because as we see IS and RSA, to set it up is a bit tricky. You easily can use like modes which are not the best for your use case.

And often we just have the use case that we just want to have good encryption, just encrypt something and put it on the data or put it over the network and decrypt it on the other side. And so actually as an interface, the interfaces which we have today for encryption,

the Scripto PP and C++ and Botan are kind of poor, kind of poorly designed as it's still a lot of work left for the programmer and the Scripto box approach goes a different way. It's just, it just tries to handle the encryption as a black box doing everything for us for encryption

and does not have anything to do with implementation details, et cetera. It's nothing which you have to tell it and just exposes like an easy interface, which in a dream would look like that. It's not that easy.

And the libsodium is basically based on this approach also because it's a necessary piece and a few other pieces are too complicated to work with for most programmers. So basically a crypto box gives you a decrypt and encrypt function, which you give the key and the buffer

and that would be like the easiest interface and the actual interface looks similar, but a bit different, we'll see that. The crypto box approach is offered also by Botan. Botan has an implementation which is based on the certain cipher,

which is a block cipher. And if I remember correctly, it was back then also proposed for the standardization as AES, but different algorithm made the race, but it's actually viewed as kind of secure. The libsodium offers different crypto boxes.

So you actually have a choice in that case and Botan does not give you a choice. And libsodium offers you crypto boxes in a symmetric and asymmetric way. So if you have an application where it makes sense to exchange private public keys,

then libsodium gives you crypto boxes also for that. And if you want to just have a symmetric encryption in your crypto box, then that is also available. And the example which I'm going to show you is based on the symmetric one.

And also, again, a few words on libsodium. Libsodium is a fork of libNACL. Its goal is to make encryption accessible and easier accessible. The C library, as I already mentioned, there are C++ wrappers which you can find on GitHub,

but I have yet not found a good one. So you might want to think about doing your own wrappers of the things you need or just use a C library. And also, just like Botan, it needs to have an initialization and this function called sodium init. But there's no free function or something

that you have to call to shut it down. So it's just, you have to make sure in the code where you use encryption that the sodium init function is called once. And again, I think this is per thread. And in the example, as this is a C library,

they use defines everywhere, at least in their examples. So this is just for this example. One thing we see that the biggest disadvantage of the cryptobox approach is that the extra messages

is longer because we need a box and this box comes out for free. That's data which we need to store, which is the keys, et cetera. Not, but just the cryptobox has a certain size which is specified and defined here. And we have to add that to the message length.

So this will, like in a block cipher, you would be able to just, you also would have to append to 16 bytes. In this case, it's a bit longer, if I remember correctly. And then the cryptobox for libsodium in this example needs a nonce, a key, and a cipher text.

And again, crypto PP has defines for the length of the nonce and the key, which you easily can use there. And if you actually wanted to write a wrapper, that would be something easy, which is very easily wrapped. Then in the next step, you just generate the random data for the key and the nonce,

which is just a call to random bytes buffer, and call the actual secret box easy function, which gets the message and the key and the cipher text. And after that, the cipher text is encrypted. And if we want to decrypt the message somewhere else,

again, it's kind of easy. We just have to put in the decrypted text the message length. Then, yeah, call crypto secret box open easy and give it the decrypted and the plain text to get the plain text and the cipher text,

the cipher text length and also the key again. And also, again, this box, of course, comes with authentication. So if someone has, you know, done something with that message, you will be able to notice it.

And of course, it also would be kind of interesting, you know, what is this box made of or what actually is there in use. So for the encryption, that's a stream cipher. It's called XSALSA 20. It's a newer cipher and actually

supposed to be as safe as AES, but it's, in my opinion, as a stream cipher and it's, in this case, actually a good choice, but it's not clear. I mean, encryption is obvious, you know, it can be tomorrow that something is broken. So the asymmetric has a key exchange

with a curve 25, 51, nine. But that's basically the only difference. Encryption is, again, the XSALSA stream cipher and libsodium, basically there are some boxes which have other stream ciphers so that you actually have a choice to use different stream ciphers.

And final thoughts. Well, I think you really should think about it. You should encrypt critical data in your applications.

Botan and Cryptoplus Plus give you a very good support for algorithms, but there's still a lot of work left to implement the interfaces correctly that are usable in your team in a decent way. Cryptobox approach is easy and safe encryption like for everybody. The libsodium offers it in a symmetric and asymmetric way,

but it's a C library, so if you want to use it in C++, we probably still want to have some wrappers and that doesn't exist currently. So you probably have to write a few lines of X or C++ code to wrap it in a sane way for using in your applications. And yeah, Botan also offers a symmetric Cryptobox.

And this brings me to the last part of questions. Yes. One of the algorithms has this ad. The nonce block.

Yes, yes, yes, yes. Let me go back. Yes, here you see. You mean this nonce? The nonce is basically a sort, which I think is used in the authentication

that there's some sort of hash. And if you wouldn't use a sort, then this hash would be the key. And as they probably use a fast cipher, that would be a possible attack vector. So they have implemented a way

to prevent that, so that's a nonce. You can see that that way, yes. And of course, as you can see in this example,

you have the problem that you have to get the key and the nonce on the other side. So that's why for everything that goes over networks, public key cryptography is often better because you just can exchange your public keys and you're fine.

Any further questions? Yes. Are there patent issues with the EAX?

I'm not aware that there are any. But there could be, I mean, software patents are a problem for everybody in our field. So if you use any of those newer algorithms, then you probably should do some research in that area.

I have not yet looked for software patents in that area. Any more questions? Thank you for listening.