*36C3 preroll music*
Herald: Now for the next talk, he has worked for six years in the field of
cryptography for the uni Karlsruhe - Oots. *Applause*
Oots: OK, 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 it's 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 pwning, so exploiting all kinds of memory, corruption, bugs and programs.
Okay. This is a picture of my parents' cat. Just because every talk should have
pictures of cats in them. And this is – *applause* 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 is some ... 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 we have 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 cipher text. And then Alice sends the cipher text 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 Auguste Kerckhoffs
formulated a couple of principles that ciphers used for military applications
should adhere to, and one of these. And one of these requirements became well-
known as Kerckhoffs 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 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. OK, 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. OK, 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 phonebook 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. Okay, 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. Okay, so if we used this 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 GB
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. Okay, and the first problem here, an
attacker might change the message which actually leads me to the second part of my
talk, which is authentication. So on my talk checklist, let's mark encryption as
done. Okay, 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. OK. So, for example,
or one example where something like authentication was needed is when Alice,
um, 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 so 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 to... 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.
Okay? 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. OK. 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. OK,
but here. OK. 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 a MAC for short.
OK. But in both of these scenarios, whether we have two distinct keys or just
one key, we still have the problem of key distribution. OK. So imagine if in the
segment a 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.
And so if the attacker is sending his own public key, his only… 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. OK, so again,
we have this problem of key distribution, which is that the verification key must be
known to Bob in advance. OK. And this leads me to my next... 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 sender 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
the 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 a
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. OK. 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. Okay. 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
authority's 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.
OK so he could create a fake certificate, which says that the certification
authority has checked that the attackers 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 is a number of incidents that have
happened with certification authorities. So one famous example is the "Diginotar"
case where in fact a certification authority named Diginotar was hacked and
the attackers 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. OK, so this is not just a theoretical problem. This
has, in fact, happened before. OK, 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 cipher text
over to Bob. And then she will use a copy of the cipher text and compute a message
authentication code from it using the second key that she has. And then, Bob, as
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. OK, 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. OK, so another thing I wanted to talk about is called hybrid
encryption. And this is the 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 cipher text
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, an eavesdropper 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. OK.
So 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 MACs 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 e-mails. So, for example, when you're
sending an email from, say, Alice wants to send an email to Bob, then the e-mail is
usually not sent directly. But Alice sends the message to her own email server and
then Alice's e-mail server will forward this email to Bob's e-mail server. And
when Bob goes online and checks his e-mails, the e-mail 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 e-mail 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
e-mail server also uses a secure connection to forward this e-mail to Bob's
server. OK. 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 and some decryption and verification going
on on the receiving side. OK, so if Alice wants to send an e-mail to Bob, then Alice
will build up a secure connection and send the email over it. And this will involve
encrypting the e-mail and authenticating the e-mail. And Alice's server will
decrypt the e-mail and verify that this has not been changed. And then Alice's
server will forward the e-mail 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 e-mail is sent or is downloaded by Bob
from his server. However, in this case so even though the message is encrypted every
time it is sent over a network, it is known in plain text by Alice's server and
Bob's server. Right. Because Alice is sending the message. So she is 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 e-mail 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, right? So the e-mail is encrypted two times. One
time was with Bob's key and a 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 e-mail. And then the process repeats,
the already encrypted message is encrypted a second time and decrypted again at Bob's
server and then it is when it is downloaded by Bob it is encrypted again
and decrypted again. And then finally, Bob, who has the secret key, 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. OK, so with that, I would like to wrap up.
Sorry. So I would like to wrap up. So here's 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 are maybe
not really pre-shared keys, but key distribution has to happen beforehand. And
one way to make this problem of key distribution simpler is with certificates.
So certificates confirm that a 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 in the sense that with transport encryption, all the
intermediaries can still read the e-mail or the message being sent. However, with
end to end encryption, they cannot. And with that, I'd like to close and that 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. I will try to
keep that email address open for one or two years.
*applause*
Herald: Thank you for your talk. And now we would come to the question part, 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. We have a question on microphone two, please.
Mic 2: Thanks for your good talk, and 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? Oots: 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 number of encryption
schemes which just work by changing a couple of bits. Okay. 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 were encrypting, you use the
encryption scheme to figure out which bits must be flipped. So change from zero to
one or from one to zero and you just apply this bit change to the message that is
being sent and then the receiver can just undo this change to recover that 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 in 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 that the decryption simply
does not fail. It just maybe outputs the wrong message.
Herald: OK. Next question from microphone six, please.
Mic 6: You stated that encryption does not cover metadata. Are there any thoughts
about that? Oots: Any thoughts?
Mic 6: Yeah. Any solution for maybe encrypting metadata? I don't know.
Oots: 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 end 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, but
it does not, so it knows that the message you're sending is that most as long as the
cipher texts you're sending. But it doesn't 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.
Mic 6: Thank you
Herald: Okay, then I believe we had a question from the Internet.
Internet: Yes, uh, the Internet is asking, can you say anything about the additional
power consumption of the encryption layers on a global scale?
Oots: Sadly, I think I can not. 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 cycles to decrypt. I don't know. Sixteen 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.
Herald: Next question. Microphone two, please.
Mic 2: 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? Oots: 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, it will 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.
Herald: Then a question from microphone three.
Mic 3: I was in a talk about elliptic curve cryptography, and I'm wondering
where it is would we apply now in your example or in your process you showed us.
Oots: Um, let me maybe just go to another slide. Um. So typically encryption is
applied or elliptic curves are applied within these encryption and decryption
boxes. Okay. 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.
Herold: OK. Microphone one, please. Mic 1: 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? The
encryption competition for those devices? Oots: There is some research going on on
encryption schemes that are particularly lightweight, so 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 they security wise, they do not offer the
same guarantees as the ones that you use if you have the resources for it.
Herald: On microphone two, please. Mic 2: Yeah. Hi. You mentioned the
enormous power that certificate authorities have in the picture of
certification and authentication. I was wondering if there I mean, what are the
possible solution or the proposed solution at the moment? What is the state of the
art on solving that problem? Oots: So one solution that is currently
being pushed is called certificate transparency. And that works by basically
creating a public 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 dot com or if you are
Google and you see someone entering Google's 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 are
expected to check if the certificate is actually contained in one of the public
log files. Does that answer the question? Mic 2: Yes. But how does appending a
certificate would work? So, for example, making sure the certificate is recognized
Alice as legitimate. Oots: OK. 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.
Mic 2: So it is the certificate authority that also pushes the certificate to the
log? Oots: That's how it's expected to work.
Yes. Mic 2: OK. Thank you.
Oots: You're welcome. Herold: Then we have one more question
from the Internet. 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?
Oots: I guess that depends. So with PGP, the common model is that there is not a or
there is 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 e-mails. And
each of these e-mails, each of these users should authenticate the public keys of
their peers. OK? So when you want to communicate with someone who you do not
already know, but who's maybe a friend of 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 a
certificate for his friend. Herald: Are there more questions from the
Internet? One more? Yes, please. Internet: I don't know if it's a question
regarding your talk, really, but someone wants to know. Would you recommend
startTLS and SSL/TLS in e-mail? Oots: 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 as is a better way to do it than with startTLS.
Herold: I believe that what is it, was it for questions? Please have a last round of
applause for Oots!
*applause*
*36c3 postroll music*
Subtitles created by c3subtitles.de in the year 2020. Join, and help us!