Privacy for the Internet
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 170 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/50851 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
TelecommunicationInternetworkingCognitionCorrespondence (mathematics)Right angleInformation privacyTheoryEncryptionSymmetric matrixPasswordMiniDiscHash functionData integrityVorwärtsfehlerkorrekturInformation privacyPasswordComa BerenicesTheoryComputer scienceFocus (optics)Web serviceArithmetic meanWebsiteSymmetric-key algorithmGoogolTwitterCellular automatonEncryptionVideo gameDesign by contractCASE <Informatik>Goodness of fitUniverse (mathematics)Hash functionPoint (geometry)Power (physics)Right angleDeclarative programmingKey (cryptography)MathematicsBitFacebookCommunications protocolDirection (geometry)TelecommunicationInformationDifferent (Kate Ryan album)View (database)Expert systemState of matterEmailINTEGRALCoefficient of determinationHydraulic jumpNichtlineares GleichungssystemChaos (cosmogony)AlgorithmWeb pageWordTable (information)HoaxExtension (kinesiology)NeuroinformatikReading (process)EstimatorNumberCryptographyProof theoryMultilaterationServer (computing)Rule of inferenceService-oriented architectureElectronic mailing listFunctional (mathematics)Group actionComputer animation
09:34
GoogolWeb pageInformation privacyInterface (computing)TelecommunicationCommunications protocolComputer iconElectronic data interchangeSteady state (chemistry)Web browserSuite (music)EncryptionDecision support systemCore dumpRSA (algorithm)Range (statistics)Key (cryptography)Infinite conjugacy class propertyComputer wormMenu (computing)Drum memoryPerfect groupServer (computing)Client (computing)CASE <Informatik>Formal languageLink (knot theory)EmailSimultaneous localization and mappingAugmented realityMedianTransport Layer SecurityInformation securityCommunications protocolMaxima and minimaServer (computing)Revision controlWeb browserKey (cryptography)MathematicsTelecommunicationComputer configurationWeb 2.0Transport Layer SecurityCASE <Informatik>Perfect groupEncryptionInternetworkingOrder (biology)Connected spaceBitDefault (computer science)AlgorithmSet (mathematics)WebsiteInformation privacyInformation securityPhysical lawRootEmailMereologyClient (computing)Design by contractWrapper (data mining)Web serviceShared memoryComputer programmingIP addressRule of inferenceArmArchaeological field surveyRight angleElectronic mailing listForcing (mathematics)SubsetProduct (business)Greatest elementRepetitionState of matterMultiplication signVideoconferencingTerm (mathematics)Goodness of fitIdeal (ethics)GoogolSound effectComputer animation
19:07
Communications protocolTransport Layer SecurityInformation securityRevision controlMaxima and minimaTelecommunicationEncryptionSuite (music)Computer iconEwe languageGamma functionConvex hullPointer (computer programming)Library (computing)outputElectric currentEmailIdentity managementKey (cryptography)SubsetMultiplication signDifferent (Kate Ryan album)EncryptionServer (computing)Public-key cryptographyComputer configurationWebsiteGraph coloringBitPoint (geometry)Computer iconTelecommunicationWeb pageBit rateInformation privacyBoolean algebraRule of inferenceConnected spaceGreen's functionEmailCommunications protocolReading (process)Information securityLaptopPhysical lawCodeError messageStandard deviationRepetitionDesign by contractWeb serviceResultantDigital mediaDigital electronicsPressureArrow of timeValidity (statistics)MetadataSoftware testingMusical ensembleRoundness (object)Message passingFundamental theorem of algebraSet (mathematics)Range (statistics)System callRight angleComputer animation
28:41
EmailEncryptionTelecommunicationSign (mathematics)Repository (publishing)Pairwise comparisonKey (cryptography)Power (physics)Statement (computer science)Public-key cryptographyHash functionGame controllerPasswordCASE <Informatik>Server (computing)EncryptionWeb 2.0Random number generationCommunications protocolWeb serviceWebsiteEmailAddress spaceTelecommunicationMathematicsRule of inferenceMessage passingBitMoore's lawMetropolitan area networkKeyboard shortcutDefault (computer science)Proof theoryValidity (statistics)Online helpNumberAlgorithmVariety (linguistics)Right angleIdeal (ethics)System callHoaxInformation privacyBuildingSet (mathematics)State of matterElectric generatorDirection (geometry)Computer iconComputer animation
38:14
Key (cryptography)EmailRepresentation (politics)Address spaceRule of inferenceTelecommunicationControl flowFiber bundleRSA (algorithm)Information securityCommunications protocolFormal grammarExchange ServerPlastikkarteAndroid (robot)Computer configurationEncryptionDefault (computer science)Shared memoryConfiguration spacePersonal digital assistantOvalDynamic random-access memoryColor managementExecution unitEmailEncryptionAddress spaceMessage passingWeb browserException handlingEndliche ModelltheorieBitGame controllerKey (cryptography)Integrated development environmentMoment (mathematics)AdditionComputer configurationComputer programmingPublic key certificateMultiplicationSign (mathematics)SoftwareSet (mathematics)Projective planeWeb serviceLimit (category theory)Process (computing)FamilyContent (media)Line (geometry)Video gameSystem callPublic-key cryptographyMultiplication signTelecommunicationArmNumbering schemeInformation privacyDifferent (Kate Ryan album)Cycle (graph theory)MathematicsValidity (statistics)ResultantCASE <Informatik>Metropolitan area networkRevision controlOntologyDrop (liquid)Personal digital assistantSmartphoneRule of inferenceGoodness of fitWeb 2.0Real numberRSA (algorithm)Standard deviationPasswordBuildingComputer animation
47:48
MomentumInclusion mapGamma functionQuantumRatsche <Physik>MIDIGame theoryInformationMereologyCountingMessage passingSymbol tableRule of inferenceTouchscreenInformation privacyEmailCASE <Informatik>Interface (computing)Key (cryptography)Reading (process)Content (media)Multiplication signMetadataSlide ruleSmartphoneWeb 2.0BuildingEncryptionSign (mathematics)Asynchronous Transfer ModeComputer virusDifferent (Kate Ryan album)Revision controlComputer configurationDefault (computer science)Set (mathematics)Software testingRight anglePublic-key cryptographyWeb serviceLine (geometry)Digital rights managementElectronic mailing listMetropolitan area networkWater vaporCryptographyTerm (mathematics)SpeciesMeasurementInternetworkingPasswordArmRootMeta elementGreatest elementWeb crawlerBitComputer animation
57:21
Android (robot)PlastikkarteTelecommunicationOpen setRule of inferenceComputing platformInterface (computing)Server (computing)EmailLaptopCommunications protocolRevision controlPhysical systemPublic-key cryptographyStandard deviationOnline helpEncryptionKey (cryptography)AlgorithmCartesian coordinate systemEmailTelecommunicationSmartphonePasswordFamilySign (mathematics)Interface (computing)Software developerGoodness of fitDefault (computer science)Android (robot)Open setChainFormal grammarComputing platformComputer configurationWindowFeedbackGoogolWebsiteMathematicsCryptographyInformation privacyBootingMiniDisc2 (number)Office suiteMetropolitan area networkComputer animation
Transcript: English(auto-generated)
00:02
Okay, I think we can start. Hello, everybody. Welcome. This talk is an experiment for me. I'm now 50 years old, and I have a strong background in computer science
00:21
with some main focus on service-oriented architecture and C++. Last year, I was really fed up, because I learned that, besides that, I know that when I'm sending e-mails, that there's some danger that people read it,
00:43
that in practice, the reality is a lot worse. Or to say it with other words by Tim Pridloff, one guy at the Chaos Computer Club conference in Germany last year, we woke up out of a nightmare to find the reality was even worse.
01:05
And we had assumed a couple of things before, but we didn't know how much privacy is an issue or non-privacy is an issue in this world.
01:20
So I'm fed up, but I don't want to give up, because you can, of course, argue, well, Secret Services and other people who care for breaking privacy for maybe some good reasons, they can do everything. So you have no chance to win this fight.
01:42
So I want to contribute and help that at least this fight becomes more complicated. I'm still learning. It's a new topic for me to some extent. And this talk has the idea of both. I'm telling you what I understood so far, what I learned,
02:03
and how I contribute and maybe if you are willing to help to make this world a little bit better from my point of view to contribute. So let's start. I don't want to discuss the whole issue from whether it makes sense or not, but just let me state one thing.
02:24
There was in 1948 the Universal Declaration of Human Rights by Roosevelt and others signed. And one of the articles explicitly said privacy is an issue. And now we have challenges for that.
02:42
As I said, there might be for good reasons, but at least in Germany, as we learned that the Chancellor's mobile phone was investigated by the NSA by the U.S., that was probably a proof
03:04
that they don't assume that our Chancellor is a terrorist. So there are other things behind. And for these other things, I think that's important for a couple of reasons, not just for my privacy, but also for privacy in companies and also to protect bothersome people.
03:25
So there's one reason you might, even if you don't have something to hide, you might care about privacy, which is we have to make privacy a general usage because otherwise those people who encrypt are immediately people
03:45
who are in focus. So we have to protect those who need privacy. So that might be also a reason to help in this area. Okay, so if you are interested, read this article by Martin Fowler,
04:02
which you might have heard about why this is an issue. So far so for the motivation. So let's jump into details. Before I go into what I learned just for me I can do, and it's a very practical thing, it's not bringing the whole issue on table
04:21
and discuss every detail and everything we could do. Let me at least introduce some theory about encryption, which is needed here. We have in principle three ways of encryption, which is symmetric encryption, so we agree on a password, and so we both have to know the password,
04:41
or we use that when we store data on a file, I use a password and then I read it again, I use the same password. So there are encryption algorithms for that. And then we have the asymmetric encryption, which is pretty important, as you will see later on, for email and other stuff, where encryption uses a different password than decryption.
05:02
This is safer but less convenient. And then we have hashing, which is for signing data so that protecting the integrity of data, so ensuring that this data was not modified. So with this short introduction of theory, let me show you one important thing,
05:22
and that is if you sign or if you encrypt, that doesn't mean your data is protected, because it all depends on how good encryption algorithms are. It depends on how good hash functions are.
05:40
And you see here on this list from some guys, but it's a common agreement in principle which encryption and hashing functions are broken. Broken means, for example, that we know that secret services can read them alive while they are in transit.
06:00
So, for example, RC4 is broken. If you use SSL in a browser, RC4 is one of the valid protocols. So if you have the impression the communication with the server is safe, it might simply not be the case. We come to that later.
06:20
And similar for hash functions and other algorithms. So be careful. We have to use better encryption. We especially learned that secret services like the NSA try to rule new encryption algorithms so that they have a backdoor inside. And, in fact, what happens right now,
06:41
the encryption, the cryptographic experts in the world are now trying to find new algorithms with the explicit request that this algorithm is not allowed to come from the NSA so that we are sure that, or that we hope we can be sure
07:01
that there is no backdoor inside with the algorithm itself. Just to give you some numbers, NSA has 1,000 experts only caring for decryption of encrypted data, only mathematicians, et cetera.
07:22
The whole manpower of trying to investigate in privacy and breaking privacy is the amount of population of all people in Norway. It's the same number of people involved.
07:41
So we have something, well, some people who have at least a lot of resources and manpower. The good news is mathematics is our friend. So if there's no backdoor, encryption helps us,
08:01
but we need large enough keys and we need valid algorithms. So, therefore, for example, we currently recommend to use at least keys with 4,096 bits, for example, and not less. And mathematics is our friend. The more bits we have,
08:21
as it is a logarithmic course, the lot more power is needed to decrypt something. So the more bits we have, the more mathematics is our friend. So that's theory, and that's just also practical information about theory.
08:43
So now let's start. The first thing I can do is, well, or I should say is, privacy is not only about secret services. Privacy is about data I want to hide, data I want to avoid that other people have and use it,
09:02
or even other companies. And as you know, one company or a couple of companies are now collecting data, which is fine. My daughter is happy to use Facebook, et cetera. So I even use Google. However, I'm not so happy that Google is able to see which topics I'm searching for.
09:23
So one first thing I can recommend you is, if you want to Google without letting Google to find out who Googled what, use Startpage. Startpage.com, it's a website. They have a contract with Google. It's not an illegal or inofficial search.
09:42
It's just a wrapper you can use. And if you search here for just some term, this search is redirected to Google, but without your IP address, which also has some drawbacks. I mean, you don't get personal answers that are ideal for your personal benefits.
10:03
Yeah, because they don't know that you are searching. So it's always some good and bad things, and you have yourself to decide. But in any other sense, it's as good, as fast. I use it now a lot. And this is, by the way, one example where more privacy doesn't cost us any convenience
10:23
or any inconvenience. So that's good. That's the easy recommendation. So let's talk about browsing in general. As I said already, in principle, it's possible in browsers to enable encrypted communication.
10:42
Encrypted communication means not that nobody can track who is communicating with which browser, but it's at least hidden what we exchange as data. To use approaches where even it's not possible to see who is communicating with which site,
11:02
you need other approaches like Tor, et cetera, which I don't handle here in this talk. For me, it's good enough right now to think a little bit about when I have a connection with my bank. I want to ensure that this data can't be read by any other company or any other agency.
11:23
So as I said before, of course, you should use SSL, which means HTTPS. But the problem is some of the algorithms are broken. So how can we deal with that? Well, you have to configure your browser.
11:42
And as usual, it's always very easy to configure browsers in the world of Mozilla, so Thunderbird and Mozilla Firefox, and it's probably more an effort in other browsers. So I give you some examples how to configure Mozilla here better.
12:01
And before I do that, this is a website where you can find out which encryption protocols your browser accepts and would accept and in which order with which priority. So we don't have to understand here everything about that. I will talk a little bit about some of the issues here.
12:22
But you see these are close to 30 different protocols we use to exchange data in an SSL communication. So some of them are broken, some are not. So if you look here around, maybe you see something like RC4 somewhere,
12:41
just at the bottom, RC4. I told you RC4 is broken. So the good news here is it's on the bottom here, so it's the least thing we try out. There's also other RC4 in the middle. Yeah, probably there are a couple of them, yeah. So this is something with every browser you use,
13:01
if you go to this website, that will tell you what you prefer and in which preference. So and then let's do something about that. So let me tell you one story and one additional fact, which is private, a perfect forward secrecy, PFS. PFS is very, very, very important for you
13:23
because there's one important thing. Beside the quality of the algorithm you use, there might be another problem. And the other problem is that all connections to a server use the same keys, the same keys to encrypt data.
13:42
So guess somebody has broken that key, thus due to one communication, then all the communication is open. And if they video dated all the past communication on their servers, they can even read all the communication from the past,
14:02
thus when they got the key. This is, by the way, what happened with Lavabit. You might have heard about this case where they closed an email website and they used one central key for all communication. And it might not be the case that just you say,
14:21
well, somebody stole the key or got the key from somewhere or so ever. It's also an issue, well, there are roots in this world and there are good reasons that by law people are forced to give out keys. So if there is a terrorist, I'm still interested that we track this data.
14:42
But this should not mean that they track all the data with all communication in future and parts of all people connecting to that site. And to avoid that, you need PFS, because PFS creates an individual key with every communication between each server and each client.
15:03
So once, for example, by law you are forced to hand out the key for a certain person who connects to a certain server. With PFS, this does not mean that any other communication is public or open to the public. If you don't use PFS, handing out the key or losing the key to somebody else
15:25
means everything is open in the communication with this server. So PFS is something you should really care and look for. So what can I do? I said that. So in Concrete, I can, for example, in my different browsers,
15:44
set up and disable some of the protocols. The easiest thing to do that is in Mozilla Firefox. It's also possible in Explorer with a little bit more tricky stuff and other browsers probably also.
16:03
Here you see how I can do it with a browser. I select just all the SSL3. Look at the left. I select all the SSL3 exchange options, and then I disable all those where RC4 is mentioned.
16:21
So by this, I disable encrypted communication or SSL or HTTPS connections using RC4. What else have I done here? Here on the top right, there's a security TLS version minimum.
16:42
This is a minimum exchange protocol we use. The default is zero, and there are better values. So the best value is three. But unfortunately, if you disable some of these values and the servers don't offer better algorithms,
17:04
you are not able to connect any longer to your server. So that means by raising this value, it's more likely that you can't do any more bank account
17:21
online handling or whatsoever. So that you have to find out. And by the way, what I do is I use, as a default server, I use Firefox Mozilla. And then if I can't connect due to my settings, I use Internet Explorer. But then I know that this is an unsecure communication also,
17:44
although HTTPS is signaled there. So here are the recommendations I can give so far. So disable all the settings with RC4. Use so-called TLS 1.2. But this is the minimum version three.
18:01
So if that doesn't work, use as a minimum TLS version two or one, et cetera. By the way, in Germany at least, we now have by government officially recommended to support some of the better protocols. For example, if you connect to servers by the government,
18:21
you are forced that these servers support TLS 1.2. This is probably not the case in every country and not in the business world. But that's something, for example, you should ask your bank
18:41
or if you are programming in a bank, change your servers. Often it's just an option in your Apache web server just to do that. It might. One reason not to turn the better encryption off might be resources because the better the encryption algorithm is, the more resources you need on the server.
19:00
So there might be a price when you're running servers with better encryption. Okay. And PFS, which I said is handle out individual keys for each connection, you should enable only those SSL3 protocols using DHE or ECDHE.
19:24
So when I do that, I have really a couple of problems to connect to other websites. So it's still limited supported, but we hope in one or two years if we have enough pressure and if you send just enough emails complaining, I can't connect anymore to your so-called secure server
19:42
that you tell about that this will change. So here with my settings, I reduced only to accept PFS servers and then I still have a couple of different options to choose from, but as I said, a server has to offer this protocol.
20:03
If not, I get something like this. This is unfortunately a German message, but you can see in the middle, the error code, the FELA code is SSL error, no cipher overlap. So we have no overlapping protocol which we both agree on to support.
20:22
And if you want to understand more details about this and inspect websites better, I recommend Calomel. Calomel is an add-on for Mozilla SSL validation. They create, on the upper left, they create a colored icon
20:42
and this icon signals how secure an SSL connection is you are using. If it's red, then it's really worse or bad. If it's blue, it's okay. Green is perfect. So what I opened there is you can then click on it and then see the details. So without clicking on it, you don't see this big picture with all the details.
21:02
You just see your ordinary website, but just the icon there on the left. And as you can see here, for example, on the left side, this is a start page with this new upcoming email server with encryption support by those who also run...
21:24
No, this is a start page I just mentioned, sorry. And you see that when I sent my request to them, we, for example, support PFS, which gives us 20 of 20 points for the rating of this color of this icon.
21:43
So they change from time to time what is necessary to be green to get 100%. As you see, this website is rated as 88%. Half a year ago, it was 100%, I guess. So you always have to fix according to new findings, new standards,
22:01
and whatever we found out as maybe even we found out as being broken. So here on the right side, that's one bank in Germany. Is it still working before? Yeah, okay. That's one bank in Germany. That's a Volkswagen bank, German car. They also have a bank. Any car vendor now has a bank.
22:23
And as you see, they are not that perfect with support. So they have 34%. And you see they have no PFS, for example. They're in the middle, PFS, no, zero of 20 points, which means if somebody by law gets a key to validate the connection
22:45
between any customer of this bank with this bank, with this key, they can inspect all my data I exchanged with this bank in future and in the past if they just streamed my communication in the past but they couldn't read it.
23:01
So therefore, maybe we should change the bank. But it's not so easy to find banks which do it all right, but we need pressure for that. Okay, so far for browsing, now let's look to eMates. With eMates, we have a similar problem which is in principle we can encrypt data,
23:24
but we can't easily encrypt metadata, which is who am I sending data or eMates to? If you need that, then it's even more complicated. In practice, there's no protocol working and established
23:41
where we can just use a private communication where nobody can track that we communicated. So if that's your problem, I don't have a standard answer for that. But if not, if it's only that, yes, they can know that I have a discussion with my tax lawyer
24:02
or that I have exchanging eMates with my doctor for medical reasons. Yeah, they can do that, but they shouldn't know that I talk about abortion here without me allowing that. So that's something we can solve.
24:22
And to solve that, there's a very famous approach which is PGP. There are other approaches. And before I go into details and list some of the issues involved there, let me please allow to explain PGP and in principle asynchronous encryption by an example
24:45
because that's usually the easiest way even my mother understands these slides. Well, she at least claims to. Okay, so what is a trick? The trick is, that's Nico on the right,
25:00
and I want to make eMate exchange secure. The first thing I have to learn is it's one thing we have to do on both sides. So one thing I can arrange is that people can send me eMates without anybody else reading these eMates.
25:21
But I can't do anything with this protocol to sending encrypted eMates to other people. So they have to prepare for that. So I have to prepare keys, and these keys are asymmetric keys. And there are two keys in fact, or in practice there are even more.
25:42
For the simplicity, assume that there are only two keys. And these two keys are used. One is to encrypt data, and one is to decrypt data. And you can only decrypt data encrypted with this key and the other way around.
26:04
So the point is now, I created these two keys. And the fundamental first rule is nobody gets my decryption key, which is also called my private key. So with this, I can read the data.
26:20
With the other key, I can only encrypt the data, which means with this key, I can organize that only Nick who can read this data, if I have the private key, or only the owner of the private key can encrypt this data. And there's nothing wrong with giving this key to other people or to the public,
26:43
or putting on the website or whatsoever, because nobody can violate privacy with this key. They can only encrypt data which nobody can read except me. But I, to make sure that only I can read it, I need the private key at home or in my laptop or whatsoever.
27:02
We come to that. Okay, so that's something I have to prepare. With this preparation, I am able to receive encrypted emails. So now somebody wants to send me an email. Okay, here's the yellow guy or orange guy.
27:21
The orange guy wants to send me Hello Nico as a test mail. Okay, so what do they have to do? They encrypt the data with the mailer. To encrypt this data, they use the public key. However, this guy got this key. I might have given it on a USB stick.
27:41
I might have put it on my website. I might put it on a central server where public keys are available. I might have written him a letter with 4,096 bytes, and they have to copy them. That's all possible. It's still possible to copy 4,096 bytes. It's a little bit boring, but it is.
28:02
So this is the result, and you see there, well, a little bit as a smaller icon, there is Hello Nico encrypted by this key. And then you send the key to me. And so what I do then,
28:24
then I use the private key to decrypt the data, and suddenly I see Hello Nico again. So that's the deal. So if I want to send an answer, if I want to send an answer to this guy,
28:40
he first has to do the same to create a private and public key pair. Somehow I have to know about his public key, and then I can encrypt the answer with his public key, send back, encrypt the data, the email, and then he can decrypt the data.
29:02
The good thing with this is we don't have to exchange any passwords with other people can catch because I don't send anything to the public or via any communication channel which is not public because I have the key. But the drawbacks, of course, is we both have to be prepared
29:22
to exchange data this way. Or, on the other hand, I can even receive emails from people not being able to read encrypted keys by using this technology just when I prepare everything. So that's the principle.
29:42
There's at least, well, as I said, first of all, one important thing here is that people not just using a huge amount of computer power can just try out all the possible keys. So two to the power of what is the size of my key
30:02
combinations to decrypt the data. So but two to the power of 4,096 is a very huge number. And so we are pretty sure that it will be stable for the next 20 years or more. We thought in the past that 256 bytes for a key would be fine,
30:25
but we now know that it's broken. But the common recommendation for people who say you want to be safe in your infrastructure for the next couple of years, so not just two or three, but 10 or so is 4,096 bytes is fine.
30:48
So that's the first thing. The other thing is there are still some problems. So one thing is we use random number generators. And one common trick by secret services
31:01
is to violate random number generators so that you only create only a thousand random numbers instead of the whole variety of two to the power of 32 or 64. So then you screw up not the algorithm, but the way the algorithm is used combined with random numbers.
31:21
And that might also lead to some problems. So it's not only that, but this is the most important step. This is the basics to be safe. Okay, so but the other thing that might happen is that the following happens. It's a so-called man in the middle approach where we have the following.
31:41
Guess the orange guy want to send me an email and he doesn't know my public key. So he needs it from somewhere. So I can give it to him personally. The other thing is he looks at my website or he looks at a public server,
32:01
but there's a fake key, faked by whoever knows. So in the communication by retrieving the public key, somebody gives him a different key. And with this different key, they encrypt the data, but they use the wrong key.
32:20
So somebody in the middle might then have the key that was used for encryption and then use my public key to send the data in a way that I read it so that I have the impression I got this message from the original sender so that I don't say it's getting lost or I can't read it.
32:41
I can still read it, but there was a change in encryption in the middle. So this is man in the middle attacks. And to prevent from that, we have to, well, we can do a couple of things. The safest approach is I hand over my public key
33:01
to each person personally. I go to you, and I give it to you, and you know that's Nico, and we are fine. The other thing is each key, even if it has 4,096 bytes, has a so-called footprint, which is just a hash value of it, which is a unique value of the last,
33:24
I don't know, 32 bytes or so. So I send this key around, and then by phone, we communicate, we know our voice so that not my voice is fake somehow, and then we agree that the footprint is right
33:41
so the last 32 bits are matched, so then we know it's fine. And then we can use other approaches. One approach is I trust places where I can officially publish keys. So this is, by the way, the S-MIME approach,
34:02
which is another encryption technology better supported by most of the mailers. The problem is that these servers, the S-MIME servers, are controlled, well, are located in the United States.
34:23
So, hmm, well, just theoretically, just in case the NSA wants to get access to these servers, they can do, and with the Patriot Act of the States, it's even not allowed by those who are running these servers
34:40
to tell me that there might be some secret service looking at these keys and faking keys. So we have some examples, and we are pretty sure in the community that the S-MIME approach is broken for privacy. So it might still, you can still use it
35:00
if you compare the keys yourself. That's fine, and the whole technique is there. But if you just want to use keys from public servers, then S-MIME is the risk. A known risk now. So the other approach is PGP approach, and the PGP guys thought different about that.
35:21
They said it's always a risk if I create some protocol where there is central control because then there's a central ability to corrupt this control. And the idea here is, in principle, that they build a so-called web of trust.
35:41
And that means there's no central server. Well, there are central servers, but these central servers only hold the keys, but there's a protocol inside the keys that is used in a way that people have to confirm that this key is valid. So I can download from the server the key,
36:03
and inside the key there might be a statement that my girlfriend signed this key or that a company I trust signed this key. Of course, it's, again, difficult if I trust the wrong people, but the principle is either I signed the key
36:23
or somebody I trust signed the key. By the way, enough people I trust signed the key. And if you sign a key there with this protocol, you can say, I am absolutely sure that this is the key for this person. So using your ID, personal ID,
36:40
or you know that person and we agree this is my key. Or you can say, well, yeah, I think it is this person, but I'm not absolutely sure. So then there are some rules inside which say, for example, if either I trust or if there are three other people
37:00
that confirm that they are sure that this is the right person, and this is the right key for this person, then we accept this key as valid. So this is the general idea. The general idea is that we build a web of trust where if I can't myself find out whether I can trust this key,
37:21
I can find out with the help of other peoples I trust indirectly. You can configure how much indirections are allowed. You can configure how much proofs by trusted people you need, but the defaults are usually fine.
37:41
So it depends how much it is likely that other people screw up, trustness by keys, et cetera. So that's inbuilt in PGP, and that gives PGP a lot more power because it can't be screwed up in a central server by just one person or one company.
38:06
So having said that, let me say something about keys. Well, first of all, you can, in a key, represent more than one email address. Also, a key belongs to a revocation certificate.
38:20
So with your key, you get some way to revoke this key, which you should always create when you create a key, so that keys can have the following state, valid, invalid, expired, revoked, disabled. So another thing a key has is an expiry date, and you can also personally disable a key in your own environment.
38:43
A key also has a passphrase, and you can change this passphrase. You can change expiry dates and add an additional email address. So the usual thing you should do is if you create a key, create it, please, with 4,096 bits RSA algorithm.
39:03
Please create a passphrase. Please create an expiry date, something like three or five years, so that if you just forgot the whole issue because privacy is no longer an issue, it's just a hype now, and in five years or in two years, we all forgot that until we have the next problem.
39:23
So then this key is not valid for centuries. And you should please beware that although a key can be used by multiple email addresses, the life cycle of these email addresses should be the same. So it's not a good idea to have one key
39:42
for your job email address and your private email address, because when you change jobs, this key might be invalid, but you still need it for private reasons. So therefore, please make sure that you have different keys for different life cycles. You can still change the email address in your private life
40:01
or in your business life, but you should separate these keys for these areas. And as I said before, never give up control of the private key. It's no problem to give up control of the public keys, and you can also give up control of the revocation keys.
40:22
There's no secure penalty there, because the worst thing that can happen is that somebody revokes the key. But still with the private key, you can read the email, so it's just an inconvenience. So the only thing you really have to care about is the private key. That's the important thing. Don't give it to anybody or anywhere.
40:42
Well, but we come to that. Some other comments. PGP has two flavors. Inline PGP, that's an ad hoc PGP standard, or it's a non-standard, it works. And we have a PGP MIME standard for emails, and the problem with the MIME standard is not supported
41:01
as well as inline PGP. As inline PGP is ad hoc, you might have especially problems if you have attachments in emails, et cetera. Then, unfortunately, we still have interoperability issues. This technique is 25 years old.
41:22
But still, we have limited support for PGP MIME. Inline PGP serves pretty well, but has some limits. So we have very well support with Sander Burt, called an e-mail add-on. I'm currently a contributor to this add-on. To make it more convenient, we come to that.
41:42
And for Apple, there's GPG tools. Both are not supported by the vendors. It's third-party projects for add-ons by private companies, or private interest people. We have restricted support for Outlook smartphones
42:00
and web mailers like Yahoo, et cetera. There is some solution. Here are some hints about where you can look at. The real problem is vendors don't care about PGP. I don't know a buy. Maybe it's not worth it. It's not worth the effort. Maybe there is some secret governance buy for American companies
42:25
because all these companies are American, not to support this standard. We don't know. We simply don't know. And then the quality of the support can be very different. Ideally, in this world, it should be the following.
42:40
As PGP is not common or mature, you will exchange data with people who don't have PGP support. But you might want to exchange data who have PGP support. Though the obvious, easiest solution is the following. If I have the key for all my recipients, automatically I encrypt it and send it encrypted.
43:03
That's the best support where you don't have to do anything when sending emails. This is not implemented in all the browsers. Sometimes you have to explicitly enable encryption. You can then sometimes add rules when for this guy it should be encrypted, for this guy not, et cetera.
43:21
So there's different convenience and different inconvenience there. In the worst case, if there's almost none support, you have to copy and paste the content of your email to an encryption program and copy it based off the encryption back or to read it, you decrypt this with another tool
43:44
and then you copy, paste it better. After that, you can read it. That's always possible, but that's very inconvenient, of course. Please help. So, last minutes, I want to show you some examples. I have 50 more minutes.
44:00
I am contributor of Enigmail, so I want to show you some examples how this works. So, I hope I don't give you too much privacy of my email communications. This is not a special account, but I disabled hopefully enough. So, this is Thunderbird, and here you see,
44:23
well, I'm switching to an email, and in this email, yeah, as I haven't put in my passphrase and it's the first time I read this email today or how long this passphrase is valid, I have to put my passphrase.
44:52
So, there it is. So, the formerly unreadable content now becomes readable. You see here, there's a green sign saying that this is a decrypted message
45:02
and that this is a signed message so that the sender also authorizes him. I didn't have a demo for that, how it works, but besides sending the email encrypted, if I want to make sure that it comes from the right person, I can also sign it with my keys.
45:21
So, and I can read it and handle it. I can reply to it, et cetera. To do that, I have to install the tool, the add-on. I have then to start a wizard, which also asks me to create a key pair if I don't have it,
45:40
and I have to provide some preferences. Here you can see the major preferences we have. Well, we have two major preference tabs. The first one is they tell me where they found the underlying encryption software, which is a program called GPG GNU PGP.
46:02
And so, I can use it. I can install it separately or you can install it with the Enigmail add-on. And then here you see that I say my passphrase is idle for 40 minutes. So, after 30 minutes, I'm asked again for passwords when I want to read the emails again.
46:21
And then I have some sending options. This is, by the way, not the current version you can download as the official add-on. This is a nightly build. It will become in four or six weeks the official version. So, one thing I added was this automatic encryption,
46:40
automatic encryption if I send emails, which is not there before. So, I tried to add some more convenience here. So, we will see in a moment. So, here is when sending emails, use convenient encryption settings. And as you can see here, the convenient encryption settings automatically reply encrypted.
47:01
If you got to reply to an encrypted message, they automatically sign. If you want to reply to a signed message, they accept all keys. So, we don't use the trust model. I just introduced yet. We say, oh, it's good enough. It's still better than sending postcards.
47:22
But, of course, if this man in the middle danger is a real danger for you, you should not select this option and then automatically send encrypted if possible and don't confirm before sending. Well, I will confirm. So, I use my manual settings.
47:42
There are a couple of more options, as you can see if I add on the export settings. But these are the main settings. Okay. So, now let's answer this email. So, I have two screens here. So, this opens my reply message.
48:04
So, here on the bottom right, there you see two symbols. These two symbols say the message will not be signed and the message will not be encrypted. So, hmm, but I have auto-encryption.
48:22
So, let's select somebody I have a key from, which is my colleague, Jutta Eckstein. So, you see, even now, while this person is selected in this menu, on the bottom right you see a plus sign there in the key, which means, in principle,
48:43
my general preference was not to encrypt, but with the plus sign it will be encrypted. So, let's do that. I can also go here and enforce encryption or false signing and I have, for example, the ability to change some defaults.
49:04
For example, here are my defaults for this account in Thunderbirds. So, in general, sign all messages or encrypt all messages. Finally, sign automatic messages when they are encrypted or when they are not encrypted, et cetera. So, I could now send, for example, by explicitly clicking no.
49:24
Yes, I also want to sign it, but no, in this case, although I have the key, I don't want to encrypt it. So, just hitting this button does that. I do it back here. So, I have now here false sign and encryption
49:43
just because I have the key. Yeah, so that's it. Hello. She's currently in Budapest, I think, so hello to Budapest at another conference. So, that's it. Oh, this is privacy videotaped, huh?
50:02
Too bad. Okay. We sign it about the date when I send this. Okay, so, ah, I send it. Well, here's later. Send on later. So, I now request for sending the email for my passphrase,
50:25
and that's it. Here you see a final confirmation, which is us, and here you see the encrypted message, which will go out over the internet, and, yeah, nobody can read this message unless they have this private key.
50:41
So, yeah, because I'm not online right now, they are sent later, and though I have the option to save this message now, and there's also final information which keys I use. Yes, the subject is not encrypted. The subject is only the content of the email.
51:03
So, what we still know is who is the sender, who is the receiver, what was the subject. Yeah, so the metadata of emails is still known. That's what I said. So, what else? I want to say or show you.
51:23
Yes. No.
51:40
Ah, yeah. I have only one receiver here, which counts. I have another receiver, which is BCC. BCC has the idea that other recipients don't see
52:01
that there's another guy reading and getting this email. Now, if I would encrypt for this guy, the information that this was encrypted for this guy will be part of the message. So, therefore, BCC is a special case. BCC doesn't count, and there will be warnings if I BCC not to myself.
52:22
It doesn't count here because I sent it to myself, but if I send BCC to others, there will be a warning. Do you know that this means that people can see that you can violate BCC? Because what happens here, what you see here is the following. This is encrypted.
52:41
Part of this encryption is the information which key was used by whom. You can disable that, but, yeah, usually don't do that. So the better approach is don't use BCC. Just BCC as a separate mail to others. And, as I said, a mailer should warn about this danger.
53:02
And, by the way, and you can send to multiple people just because this question also arrives again and again. So does it mean that with every additional receiver, the message size grows by the same amount? No, it doesn't. Because the trick is internally the email uses a temporary password,
53:23
a temporary key, and only to read this key, that's encrypted for all the receivers. So the step is for each receiver has the ability, a special key, to encrypt the key to read the data. So, therefore, it doesn't grow.
53:40
The whole message doesn't grow for every new recipient. So when I have multiple recipients, as I said, the message will be encrypted by a temporary key, and for each recipient there will be the information encrypted
54:04
for this key, for each recipient. So it will grow a little bit, but just some bytes. So we can see that. We can see it here. So if I break it up to show you some other examples,
54:22
I have some test accounts here. Let's send it to somebody where I have a rule where I say when I send it to this guy, I want to have it encrypted, and then I send it to another guy, and there I have the rule never encrypted to this one.
54:42
And you see here, for example, that internally I have a violation of the rules. The rules are there. Usually, you don't need rules if there is this auto-encryption mode, but as I said, this auto-encryption mode is new and will be new in Enigma 1.7. It's only in the nightly builds, or in four weeks it will be there,
55:01
before you needed rules, and with rules it was more likely that you get some conflicts, etc. So then I could raise this conflict by hitting here and say, well, I don't want to encrypt, or yes, I want to encrypt in this case. And if I don't have a receiver,
55:20
so let's take a new receiver, take Jim Hook, I don't know why this name comes to my mind, I don't know anybody of that, from the email.de, and I want to send this to this guy. This guy is not known, so I get an interactive dialogue,
55:43
and in this interactive dialogue, they try to find this receiver, because it might be that this is a different name of somebody I know. Let's not show you too much of all my keys.
56:00
So if I send this email to somebody where I have another key, I can select it easily here. But if I don't know this guy, I go here, download missing keys, oh yeah, I'm offline right now, and then I got a dialogue to look at the public servers, do I have this key,
56:21
and then I can use it, and then it's part of my key list, key management, and then the next time it will be automatically encrypted when I send to them. So it's pretty convenient to add new recipients, and yeah, it's not all, but this is a major interface we use right now,
56:41
or we will use with the next version or with the current nightly build. So let's see. Three more minutes. Any more questions here?
57:03
Oh yeah, yeah. How about email on web and smartphones and webmailers, et cetera? Yes, that's a question, and so let's get back to my slides.
57:22
Ah, here's also one recommendation which I didn't mention yet, which is that when signing emails, it might be that you use by default SHA-1 with the broken hashing algorithm. So you would have to set up some setups,
57:42
for example, on the Windows system and maybe on other systems to use a better algorithm for signing. So unfortunately, the defaults are not that good. I have to double check with these guys. Yeah, so this is also one thing. So let's see on the other examples.
58:05
He, no. Where is it? So the, yeah. The best support we have, as I said, for Thunderbird and Apple,
58:20
Apple Mail, Outlook and smartphones, it gets more complicated, Android see open key changes, some GPT tools support for iPhone, and for webmailers, look at the website Mailvelop. You will find it if you search for that. That's an interface that wraps Google and Yahoo, et cetera,
58:44
so that you can use it. They are all not that convenient. So unless you fix that in the next days, I hope so. So let me summarize. PGP can be used, but can be inconvenient.
59:04
The best support we have currently with Apple and Thunderbird, that will change. I know, for example, the development guy of open key chain with the Android add-on for PGP,
59:23
and there he, for example, got sponsored by Google, three guys for three months to fix some of the stuff. So there is some support by also American companies to improve the situation. Let me also say in general,
59:42
the amount of people that are behind some of these inventions is incredibly small. There's only one guy maintaining the underlying general tool, GPG, which almost all use, and...
01:00:00
where I contribute, I thought, oh, there will be 10 or 100 people. No, I was the second contributor. I became the second contributor of this beast. So, yeah, it's incredible how few support we have there. And if you are really keen on helping, come to me or go to the website and offer your help.
01:00:23
We need it. We need it desperately. OK, then some open issues. As I said, the further goal is to support on all platforms PGP MIME so that we have a standardized formal email protocol also on smartphones, et cetera.
01:00:42
However, there will be one problem. To read the email, you need the private keys on all devices. So, well, a smartphone is very smart in these days, but that means something that for the private key, well, if you lose your smartphone, that might be an issue then.
01:01:00
And as I said, you can revoke keys so that no longer people send you the emails, but for the old emails, if somebody has that key, they can read that. So you have to be careful. Well, he can read it if they have the passphrase. So there's also a password. There's one reason why you have to use a password together with a key.
01:01:24
So if somebody gets the key, they still have a problem to read it. So there are still some issues to solve. And then one issue I should also mention, if you receive encrypted emails and the question is when you decrypt it and you save then the email
01:01:44
or you leave your browser, is the encrypted, the decrypted, or the former encrypted email saved on your disk? So that has an impact because, for example, if you save and store your emails after receiving them,
01:02:02
always encrypted, you have a problem to search in email contents, which was one of the most often feedback I got from people who wanted Switzerland. So I can no longer search in emails. Yes, you can. But that's also a lack of the mailers that they support an option to say,
01:02:23
well, let's store the decrypted version in our folder because the major problem we want to solve now is communication, people who violate privacy at routers, et cetera, so on communication channels. But of course, there are also applications where you want to say,
01:02:40
when I save the email, it should still be decrypted. For example, if you have to hide something for your family or for others who can have access to your email account. Decide yourself whether it's worth it. I hope this was some insight. I hope also you saw that if you at least use some mailers,
01:03:03
it's not that difficult as you saw. My major goal is to make it that convenient that all people use it because it's not more convenient than without encryption. So that would be the goal, but it's a long path to there. So please help us, and thank you very much.