<i>36C3 preroll music</i>

Herald: Now for the next talk, he has
worked for six years in the field of

cryptography for the uni Karlsruhe - Oots.
<i>Applause</i>

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 –
<i>applause</i> 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.

<i>applause</i>

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!

<i>applause</i>

<i>36c3 postroll music</i>

Subtitles created by c3subtitles.de
in the year 2020. Join, and help us!