 for six years in the field of cryptography for the Uni Karlsruhe, Oats. Okay, so thanks for the introduction and welcome to my talk. As our Herald just said, I've been working in the area of cryptography for the better part of the last six years. And I noticed that many people today have kind of a mental image of what cryptography is and what encryption is. But sometimes this mental image does not really coincide with what is actually going on. So I wanted to give an introductory talk to cryptography that is available to a broad audience, so to an audience that does not have any prior exposure to cryptography and maybe even to an audience that does not have a background in maths or computer science. So as I said before, this talk is specifically aimed at a non-technical audience, even though at 36C3 we probably have a fairly technical audience. And this is a foundation's talk. So I will not be speaking about fancy research or cutting edge results. I will be talking about the plain basics. Okay, so apart from working in cryptography, I enjoy doing applied cryptography, number theory and ponings, so exploiting all kinds of memory corruption bugs in programs. Okay, this is a picture of my parents' cats, just because every talk should have pictures of cats in them. And this is... Thanks. So this is my checklist for this talk. The first item, I think we already did that. And so for the remainder of the talk, I want to explain what encryption is, what it does and what it does not do. I want to explain authentication, which fixes a problem that encryption does not solve. I want to explain certificates because they help a lot with both encryption and authentication. And in the end, I want to explain a little how the things that I'm going to introduce work together and can be combined to build more useful things. Okay, so let's start with the first point here. I would like to explain encryption. So encryption is basically a solution to a problem, so let's talk about the problem before we get to the solution. The problem here is, or one of the classical problems is that two parties want to communicate, so we cryptographers commonly call them Alice and Bob, and Alice wants to send a message to Bob. So in this case, it's just a very stupid message, just a simple hello, but cryptography has been used in diplomacy and military for hundreds of years, so imagine that this message is something more critical. And the problem we want to solve is that there might be an eavesdropper who is wanting to listen in on the connection and read the message, read the content that is being sent from Alice to Bob. And what some people think, how cryptography works is something like the following, which is kind of close to the real thing but not really, is that Alice applies some kind of encryption procedure to her plain text message to produce some random, unintelligible gibberish, which we call the ciphertext. And then Alice sends the ciphertext to Bob, and Bob has the decryption procedure, knows how to decrypt, so to invert the encryption procedure and recover the plain text message. And now the point that some people get wrong is some people think that the knowledge how to decrypt is actually secret, but that is not true today. So in 1883, a person named August Kalkovs formulated a couple of principles that ciphers used for military applications should adhere to. And one of these requirements became well-known as Kalkov's principle, and it reads, a cipher should not require secrecy, and it should not be a problem if the cipher falls into enemy hands. So rephrasing this a little, the cipher that you are using should be secure enough that you can even tell your enemy or the attacker how the encryption process is working and how the decryption process is working without harming the security of the encryption. Or to rephrase this yet another time, if the cipher you are using is so insecure that you cannot tell anyone how it works, then maybe you shouldn't be using it in the first place. So let's get back to this image. So now if the attacker knows how to decrypt the message, then obviously this very simple scheme does not yield anything useful. And so what people did is people introduced a key to this image. So now the encryption procedure and the decryption procedure use a key, which goes into the computation that is going on. So Alice does some kind of computation based on the message and the key to produce the cipher text, and Bob, who has the same key, can invert this encryption operation and recover the plain text. However, as long as the key is only known to Alice and Bob, but not to the attacker, the attacker cannot use the decryption procedure. So one general word here. I will not go into the details of how these boxes operate. So within these boxes which represent computations, there is some math or computer science going on, and I would like to not explain how these things operate internally in order to keep this talk available to a broad audience. Okay, so a problem that we have here is that Alice and Bob have to agree on the key in advance. So Alice cannot simply send over the key to Bob because if she did, then the attacker, who is eavesdropping on the connection, learns the key as well as the message and then the attacker could just decrypt the same as Bob. Okay, so this does not work. This is a terrible attempt. So for quite some years, actually until the 70s and 80s of the last century, people were only using this scheme and this is what we call symmetric encryption because we could just flip the image around and Bob could be sending a message to Alice instead because encryption and decryption uses the same key. And if there is symmetric encryption, you can guess there is something else which is called asymmetric encryption and there is, for asymmetric encryption, there is a pair of keys. One of them is used for encryption and one of them is used for decryption. And now if we have an asymmetric encryption scheme, we can do something like the following. So Bob generates a pair of these keys, one for encryption and one for decryption, and he keeps the decryption key to himself. This is why the decryption key is called the secret key. However, Bob can publish the encryption key for everyone to see. So for example, it could be put in a kind of public registry like a phone book or whatever. And now Bob can send his public key to Alice and an eavesdropper who is listening in on the connection will learn the public key, but that's not a problem because the key is public anyway. And now after we have done this, Alice can use Bob's encryption key to encrypt her message and send that over to Bob. And now Bob can decrypt the message with his secret decryption key. However, the eavesdropper here cannot simply decrypt the message because even though the eavesdropper has the encryption key, it does not have the decryption key and thus the eavesdropper cannot decrypt. However, this solution is still kind of risky. There is still a problem with this and it is we still have to make sure the keys are distributed in advance. So if we used the simple scheme where Bob is sending his public key to Alice, then there is a problem if the attacker is not simply passively eavesdropping on the connection but is willing to actively interfere with the connection. So for example, the eavesdropper might intercept the public key that Bob is sending to Alice and replace it with his or her own public key. And then Alice would think that the key she received belongs to Bob and use this key to encrypt her message to Bob and then suddenly the attacker can read the message again. So at this point, let's summarize about encryption. So encryption conceals the content of data and this is pretty much what it does and pretty much the only thing that it does. In particular, it does not conceal the fact that there is communication going on. So an eavesdropper who is listening in on the connection obviously can see Alice sending a message to Bob and thus the eavesdropper knows there is communication going on between Alice and Bob. And this alone could be quite dangerous for Alice and Bob. So imagine if Alice was working for an intelligence agency and Bob was a journalist and the attacker sees Alice sending lots of documents to Bob then this might be a strong indication that Alice is a whistleblower and Alice could be put into jail. So something more that is not concealed by encryption is the amount of data that is being exchanged. So if Alice is sending just a very short message to Bob then the eavesdropper can guess that the message that is being transferred is not a 20 gigabytes file or something. So all this kind of metadata is something that encryption does not conceal. And there is a couple of more problems with encryption. One of them is that the attacker might change the message. Protecting from changes to the message is not the job of encryption. Another problem is that keys must be exchanged in advance which I already talked about. And there's more problems. So for example, an attacker might simply record a message when it is sent and later just replay this message to Bob. Or an attacker might go ahead and block a message altogether so intercept the message and throw it into the trash to make sure it never arrives at Bob's site. And the first problem here, an attacker might change the message will actually lead me to the second part of my talk which is authentication. So on my talk checklist let's mark encryption as done. So now what is authentication? Authentication enables the detection of changes to data. It does not prevent changes from happening. It only enables the recipient to detect the changes after they have happened. Okay. So for example, one example where something like authentication was needed is when Bob was sending his public key to Alice but this is by far not the only scenario where authentication is needed. So imagine if Alice is running a charitable organization so for example she's saving refugees from drowning in the Mediterranean Sea and Bob wants to donate to Alice to help her do that then Alice has to send her bank account number to Bob that Bob can make the donation. And notice that in this scenario the message that Alice is sending to Bob her bank account number is nothing that is secret it does not have to be encrypted because this information is public knowledge. However, we do want to make sure that the message that arrives at Bob is indeed the correct bank account number. So to prevent something like this from happening where a criminal might intercept the message and replace the bank account number so Bob would send his money to the criminal's bank account instead of Alice's. And one way to realize authentication is again by having a pair of keys one of them is used for authentication and one of them is used for verification so checking if a message has been changed or not and the authentication key must be kept secret thus it is called the secret key whereas the verification key can be made public and it is called the public key. And now if you have a setup like this then Alice can go ahead and take the message that she wants to send to Bob and apply some computation to it together with the secret key, the authentication key to produce something that we call a signature or a digital signature. And then Alice sends this signature over to Bob along with her bank account number and Bob will take the signature that he receives and the bank account number he receives and apply some kind of computation to them and this computation will determine if the bank account number has been changed or is in fact original. So if the attacker changes the bank account number then Bob will be able to detect this change by checking the signature and this holds even if the attacker does not only change the bank account number but also the signature. So these things are designed in a way which hopefully makes it impossible for any attacker to come up with a valid signature for anything else than the original message. So the only thing that Bob will the only way that Bob will accept the signature is if the attacker does not in fact change the bank account number and in this case it is safe for Bob to transfer the money. So here is a different solution to this problem and it's actually pretty much the same except that now we have just a single key which is used for both authentication and verification and in this case things simply have a different name they work in exactly the same way except that the signature is called a message authentication code or MAC for short. But in both of these scenarios whether we have two distinct keys or just one key we still have the problem of key distribution. Imagine if in the scenario with two keys Alice was sending her public key to Bob then we would have the same attack as before namely the attacker could just go ahead and change the key that Alice is sending to Bob and exchange it for his own key. So if the attacker is sending his own public key his own verification key to Bob then obviously the attacker can create a valid signature for his forged bank account number and Bob would accept this. So again we have this problem of key distribution which is that the verification key must be known to Bob in advance. And this leads me to the next section of my talk so let's mark authentication as done and go on with certificates. So a certificate is a document that confirms that a specific public key belongs to a specific entity for example a person or an organization. And if we want to use certificates let's just go back to the scenario we had before so Alice wants to send her bank account number her public key and a signature for her bank account number to Bob and an attacker might change the public key and the bank account number and the signature and now if we add certificates into this we need to add something that we call a certificate authority and this is a trusted third party which will create certificates which confirm the association between a person and a public key. So before Alice is sending a message to Bob she will walk up to the certificate authority and say hey certificate authority this is my public key I'm Alice please give me a certificate and then the certification authority will check that Alice is indeed Alice and that Alice indeed owns this public key and if Alice passes these checks then the certification authority will create a certificate and hand that to Alice and this certificate is just a document which says that the certification authority has verified that the silvery key here on the slides belongs to Alice. And now once Alice has the certificate she can just send her public key to Bob together with the certificate and then Bob if he knows the certificate authority's public key can check that the certificate is indeed correct so it was indeed created by the certificate authority and if he trusts the certificate authority he will know that the silvery key is in fact Alice's and then afterwards Bob will be convinced that the silvery key is Alice's and he can check the message that Alice is sending to Bob and make sure it has not been changed. Okay so we're not completely free from the key distribution problem yet however because still Bob has to know the public key of the certification authority in advance so Bob does not need to know Alice's public key in advance but he needs to know the public key of the certification authority in advance and in practice there's not just a single certification authority but there's a whole bunch of them and certification authorities can even create certificates for other certification authorities and so on. So now Bob does not have to know all the public keys of everyone he's communicating with but he only has to know the public keys of a couple of certification authorities. Okay so let's summarize about certificates so as I said before certificates confirm that a specific public key belongs to a specific entity like a person or an organization but we're still not completely free from the key distribution problem because people have to know the certificate authorities public keys and another problem here is that this scheme gives an enormous amount of power to a certification authority so if an attacker can compromise a certification authority then he could force the certification authority to create fake certificates connecting fake keys to real identities so he could create a fake certificate which says that the certification authority has checked that the attacker's public key belongs to Alice and fixing this problem about the certification authorities power is something that cryptographers are still working on so that's still a problem today and in fact this problem is not just theoretical there's a number of incidents that have happened with certification authorities so one famous example is the Digi-NOTAR case where in fact a certification authority named Digi-NOTAR was hacked and the attacker has created a fake certificate for a Google.com domain or one of the other Google domains I don't exactly remember and then these certificates showed up being used in Iran so this is not just a theoretical problem this has in fact happened before so this concludes what I wanted to say about certificates so let's move on and see how these things can be put together to build more complex but also more useful tools so one of the tools I want to introduce is called authenticated encryption and it's basically a combination of encryption and authentication so for some reason people use this phrase mostly in the symmetric case where there is one key for encryption and decryption and one key for authentication and for verification but you could pretty much recreate the same scheme in an asymmetric fashion and that is also being done in practice in this case people just don't call it authenticated encryption so one way to build authenticated encryption is so if Alice wants to send a message to Bob then she will encrypt the message using the encryption key and send the ciphertext over to Bob and then she will use a copy of the ciphertext and compute a message authentication code from it using the second key that she has and then Alice is going to send over that message authentication code to Bob too and now Bob can decrypt the message using the key he has and additionally Bob can check if this message has been changed or whether it is original by using the verification procedure so again this kind of authentication does not prevent changes from happening but Bob can check whether a change has happened and in fact this kind of authenticated encryption can actually boost the security of the encryption scheme so another thing I wanted to talk about is called hybrid encryption and this is a combination of symmetric encryption and asymmetric encryption and the reason why this is interesting is that asymmetric encryption is usually quite slow compared to symmetric encryption so if you wanted to send a very long message to Bob and you only had a public key encryption scheme so an asymmetric encryption scheme then it would take a very long time to encrypt the message and to decrypt the message so however you can combine asymmetric encryption and symmetric encryption in a way that makes the encryption process faster and the way you do this is so if Alice wants to send a message to Bob Alice first generates a new key for the symmetric encryption scheme and Alice will encrypt her message with this key and send the ciphertext over to Bob and afterwards Alice will take the symmetric key that she has just generated and encrypt this key with Bob's public key and then that is sent over to Bob as well and now Bob can decrypt the symmetric key using his secret decryption key the kind of golden one here on the slides to recover the symmetric key and afterwards Bob can use the freshly recovered symmetric key to decrypt the actual message however a neistropper listening in on the connection cannot decrypt the message because it does not have the symmetric key and it cannot decrypt the symmetric key because it does not have Bob's secret decryption key you can continue to build on these kind of things and what you end up with is something called transport layer security or TLS for short and transport layer security is a network protocol that combines much of the things that I've introduced so far so it combines encryption either symmetric or hybrid and it combines it with authentication so max and signatures and certificates and all the other things and it adds in a couple of more things to detect replays of messages so if an attacker was to simply replay a message recorded earlier this is something that TLS can detect and TLS can also detect if a message has been suppressed by the attacker so within a connection so what TLS does is it kind of establishes a secure connection between two entities so say Alice and Bob over an insecure network which is controlled by the attacker and one application where TLS is commonly used is for sending emails so for example when you're sending an email from say Alice wants to send an email to Bob then the email is usually not sent directly but Alice sends the message to her own email server and then Alice's email server will forward this email to Bob's email server and when Bob goes online and checks his emails the email will be downloaded to his device like his phone or desktop computer or whatever device Bob is using and while Alice can make sure that when she's uploading her message, her email to her own server that this connection is secure just by encrypting the message so essentially using TLS and all the things that involves like encrypting the message and authenticating the message and so on however Alice cannot check if her own email server also uses a secure connection to forward this email to Bob's server okay so let us take a more detailed look here so each of these green locks signifies a secure connection this means that when a message is sent then or each time a message is sent over a secure connection there is some encryption and authentication going on on the sender side so if Alice wants to send an email to Bob then Alice will build up a secure connection and send the email over it and this will involve encrypting the email and authenticating the email and Alice's server will decrypt the email and verify that it has not been changed and then Alice's server will forward the email to Bob's server which involves again encrypting it and authenticating it and Bob's server will decrypt and verify it and then again the same process repeats when the email is sent or is downloaded by Bob from his server however in this case so even though the message is encrypted every time it has sent over network it is known in plain text by Alice's server and by Alice's server and by Alice's server and by Alice's server and by Alice's server and by Alice's server and by Alice's server and by Alice's server and by Alice's server and Bob's server because Alice is sending the message so she's encrypting it and Alice's server is decrypting it so Alice's server can read the message in plain text and the same goes for Bob's server and this is what we call transport encryption because the email is encrypted every time it is being sent over network and a concept opposed to this is what we call end-to-end encryption where Alice before sending the message Alice encrypts it but not with a key that is known to her server but directly with Bob's public key and she might even sign it with her own secret authentication key and then Alice sends this already encrypted message over a secure channel to her own server which involves encrypting the message again and authenticating it again and then Alice's server will decrypt the message and verify that it has not been changed however the server cannot remove the second layer of encryption so the email is encrypted two times one time with Bob's key and the second time so that the server can decrypt it and now the server can remove the second encryption but the first one is still there so Alice's server cannot read the email and then the process repeats the already encrypted message is encrypted a second time and decrypt it again at Bob's server and then it is when it is downloaded by Bob it is encrypted again and decrypt it again and then Bob who has the secret the secret decryption key can remove the inner layer of encryption and so Bob can read the message however the servers in between cannot read the message just because it is still encrypted with Bob's public key okay so with that I would like to wrap up sorry so I would like to wrap up so here are a couple of take home messages so the first one is encryption conceals the content of data and that's pretty much all it does it does not conceal the metadata and it does not prevent the message that is being sent from being changed that is the job of authentication authentication enables the detection of changes to data and both for encryption and for authentication you need to have pre-shared keys or maybe not really pre-shared keys but key distribution has to happen beforehand and one way to make this problem simple of key distribution simpler is with certificates so certificates confirm that the specific public key is owned by a specific entity and if you have all these things encryption and authentication and certificates you can build a network protocol which takes care of securely transmitting a message from one place to another and you can apply that to get transport encryption but transport encryption is inferior to end-to-end encryption and with transport encryption all the intermediaries can still read the email or the message being sent however with end-to-end encryption they cannot and with that I'd like to close and I will be happy to answer your questions if there are any questions which you cannot ask today you can send me an email at this email address on the slides and I will keep that email address open for one or two years for your talk and now we would come to the question parts if you have any question you can come up to microphones in the middle of the rows are there any questions from the internet we have plenty of time if anyone comes up with a question you're invited ah we have a question on microphone too please thanks for your good talk I would like to know how can you change a message that was properly decrypted without the other receiving part noticing that the decryption doesn't work anymore that depends on the encryption scheme that you're using but for quite a number of encryption schemes changing the message is actually quite simple so there is a really large encryption scheme which just work by changing a couple of bits so the message is made up of bits and your encryption scheme gives you a way to determine which of the bits to change and which not to change so when you're encrypting you use the encryption scheme to figure out which bits must be flipped from 1 to 0 and you just apply this bit change to the message that is being sent and then the receiver can just undo this this change to recover the original message whereas an attacker who does not know which bits have been flipped cannot however so still the attacker can just flip a couple of the bits and in this case so say the bit has been flipped by Alice and it is being flipped another time by the attacker so the bit is at its original value again and then Bob who knows how to decrypt will flip another time so it's changed again and thus the message has been changed and there's a couple of things you can do with this kind of with this kind of changes to the messages so the decryption simply does not fail it just maybe outputs the wrong message ok next question from microphone 6 please you stated that encryption does not cover metadata are there any thoughts about that any thoughts any solution for maybe encrypting metadata don't know so much of this is pretty hard to come by so I mean for emails there is the idea of also encrypting the subject which is usually not encrypted however so if you want to hide the length of the message what you can do is simply pad the message so just random garbage at the end of it to kind of hide how long it is exactly so the attacker will still have an upper bound on your message length so it knows that the message you're sending is at most as long as the refer text you're sending but it does know maybe it's shorter so if you want to hide your identity while communicating you should be going for something like Tor where you're not connecting directly to the person you want to communicate with but via a couple of intermediaries in a way that none of the intermediaries know both you and the final recipient Thank you. Okay, then I believe we had a question from the internet. Yes, the internet is asking can you say anything about the additional power consumption of the encryption layers on a global scale? Sadly I think I cannot so I do not exactly know how much power consumption is caused by the encryption however so in terms of computation at least symmetric encryption is quite cheap in the sense that it takes a couple of processor circuits to decrypt, I don't know 16 blocks or something so you can usually decrypt hundreds of megabytes per second with a processor at least with a modern one so I don't know any numbers but I mean you can guess that if everyone in the first world countries is using encryption then in the sum there is a pretty large amount of energy going into it Next question, microphone 2 please You mentioned a couple of times that an attacker might be able to replay a message I haven't really understood if I'm an attacker how does this benefit me that I am able to do that So imagine if Alice is sending an order to her bank to transfer some money and every time the bank is receiving such an order to initiate the bank transfer then as an attacker that would be pretty cool to exploit because you once eavesdrop on Alice sending such an order to the bank and then later on you can just repeat the same order to the bank and more money will be sent so if you were the recipient that would be pretty cool and you could just deplete Alice's bank account Then from microphone 3 I was in the talk about elliptic curves and cryptography and I'm wondering where this would be applied now in your example or in your process you showed us Let me maybe just go to another slide So typically encryption is applied or elliptic curves are applied within these encryption and decryption boxes so there is a lot of mathematics going on in these computations which I did not explain because I wanted to keep this talk accessible to a broad audience but one way to realize such an encryption procedure is by using elliptic curves within these boxes Microphone 1 please Another limitation I could think of or how to overcome this is devices like IoT devices that have low power and limited processing capability so how do you adapt this complex encryption-decryption computation for these devices There is some research going on on encryption schemes that are particularly lightweight particularly suited for resource constrained devices but as far as I know pretty much all of them have some weaknesses that came out of them so security-wise they do not offer the same guarantees as the ones that you use if you have the resources for it On microphone 2 please You mentioned the enormous power that certificate authorities have in the picture of certificate and authentication I was wondering if what are the possible solutions or the proposed solutions at the moment what is the state of the art on solving that problem So one solution that is currently being pushed is called certificate transparency and that works by basically creating or lots of public log files where each certificate that is ever created must be added to the log file and so if you're google.com or if you're google and you see someone entering google certificate into the log file and you know that you didn't ask for the certificate then you know that there is a fake certificate out there and so whenever you get a certificate you're expected to check if the certificate is actually contained in one of the public log files Does that answer the question? Yes but how does appending a certificate work So for example making sure that a certificate is recognized as legitimate Okay so the idea is whenever you get a certificate it will be put in a log file and everyone who gets the certificate is expected to check that the log file is actually there So is the certificate also pushes the certificate to the log? That's how it's expected to work Okay thank you You're welcome Then we have one more question from the internet The internet wants to know can we or where can we get an authentication for a PGP key and how to apply it on a key afterwards Is there a possibility somehow? I guess that depends so with PGP the common model is that there is not there's not a central certification authority or a bunch of them but so you have kind of a social graph of people who know each other and exchange emails and each of these emails each of these users should authenticate the public keys of their peers Okay so when you want to communicate with someone who you do not already know but who's maybe a friend of yours then hopefully your friend will have authenticated the public key of his friend and if you trust your friend you can then check that your friend in fact has created a kind of certificate for his friend Are there more questions from the internet? One more? Yes please I don't know if it's a question regarding your talk really but someone wants to know would you recommend start the TLS or SSL TLS in email? So as far as I'm concerned I would always opt for using encryption on the outermost layer so first building a secure connection to your email server and then doing SMTP or whatever over that connection so I think directly establishing the connection in a secure manner is a better way to do it than with start TLS I believe that was it for questions please have a last round of applause for Oats