WEBVTT

00:00.000 --> 00:02.310
>> Hello. Now,

00:02.310 --> 00:05.085
we'll look closer at
asymmetric cryptography.

00:05.085 --> 00:07.875
As we talked about
symmetric cryptography,

00:07.875 --> 00:10.270
we said there are three
main faults with it.

00:10.270 --> 00:12.390
Out-of-band key-exchange.

00:12.390 --> 00:14.310
You've got to figure out
some way to exchange

00:14.310 --> 00:17.340
the keys and doesn't scale well,

00:17.340 --> 00:19.895
and it doesn't give us
authenticity or integrity,

00:19.895 --> 00:22.050
and if it doesn't give
us either of those,

00:22.050 --> 00:23.130
you know it doesn't give us

00:23.130 --> 00:25.080
non-repudiation because that is

00:25.080 --> 00:28.890
a combination of
authenticity and integrity.

00:28.890 --> 00:31.290
We need to solve
those problems and

00:31.290 --> 00:33.660
still be able to have
secure cryptography.

00:33.660 --> 00:35.510
We have asymmetric cryptography

00:35.510 --> 00:37.709
>> to solve those problems.

00:38.229 --> 00:41.465
>> Now, with asymmetric
cryptography,

00:41.465 --> 00:43.460
every user has a key pair.

00:43.460 --> 00:46.805
Every user gets two
keys and only two keys.

00:46.805 --> 00:50.330
Right off the bat, you solve
the scalability problem.

00:50.330 --> 00:52.700
Everybody doesn't have
to have a unique key

00:52.700 --> 00:55.255
for everyone the way they
want to communicate with.

00:55.255 --> 00:58.170
Each person just has two
keys that they need to worry

00:58.170 --> 01:01.540
about and those two keys
make up a key pair.

01:01.540 --> 01:03.320
The key pairs each contain

01:03.320 --> 01:06.390
one public key and
one private-key.

01:06.880 --> 01:09.170
Captain obvious is going to

01:09.170 --> 01:10.490
tell you that the public key is

01:10.490 --> 01:13.655
available to anybody who
wants it and shared freely.

01:13.655 --> 01:16.010
There's nothing sensitive
on a public key.

01:16.010 --> 01:17.990
Now, captain obvious will also

01:17.990 --> 01:20.060
tell you that a private
key is private.

01:20.060 --> 01:21.920
It only belongs to
its owner and is

01:21.920 --> 01:24.465
tightly bound to that
person's identity.

01:24.465 --> 01:27.770
If your private keys compromise
and someone can read

01:27.770 --> 01:29.120
your encrypted messages and

01:29.120 --> 01:31.175
signed documents as
if they were you.

01:31.175 --> 01:34.350
You must keep your
private key private.

01:34.660 --> 01:37.895
Now, the relationship
between the two keys

01:37.895 --> 01:40.715
is what makes asymmetric
cryptography work.

01:40.715 --> 01:43.010
Anything encrypted with one key

01:43.010 --> 01:44.915
can only be decrypted
by the other.

01:44.915 --> 01:47.330
For example, if something

01:47.330 --> 01:48.965
is encrypted with
your public key,

01:48.965 --> 01:51.515
it can only be decrypted
with your private key.

01:51.515 --> 01:53.420
Similarly, if something is

01:53.420 --> 01:54.770
encrypted with your private key,

01:54.770 --> 01:57.155
it can only be decrypted
by your public key,

01:57.155 --> 02:00.140
so it's not mathematical
relationship between

02:00.140 --> 02:01.520
the two keys that is in

02:01.520 --> 02:04.620
the magic in asymmetric
cryptography.

02:05.090 --> 02:08.705
We already said this solves
the problem of scalability,

02:08.705 --> 02:12.630
but this also solves the
problem of key exchange.

02:12.820 --> 02:15.440
Now, I will use your public key

02:15.440 --> 02:17.180
to encrypt a message for you.

02:17.180 --> 02:19.100
The only thing that
will decrypt a message

02:19.100 --> 02:21.515
encrypted with your public
key is your private key,

02:21.515 --> 02:23.245
which only you have.

02:23.245 --> 02:25.340
You've just gotten
privacy by using

02:25.340 --> 02:27.680
the receiver's public key as

02:27.680 --> 02:29.180
the sender encrypt the message

02:29.180 --> 02:30.815
for you with your public key,

02:30.815 --> 02:34.110
and only your private
key can decrypt it.

02:34.330 --> 02:36.890
Now, I've been talking
about this like I

02:36.890 --> 02:38.900
actually ask you for
your public key,

02:38.900 --> 02:40.970
but actually, my application

02:40.970 --> 02:43.450
asks your application
for the public key.

02:43.450 --> 02:45.500
For example, let's say that

02:45.500 --> 02:47.555
I'm sending an e-mail
message to you.

02:47.555 --> 02:50.659
Well, usually what
happens is your network

02:50.659 --> 02:51.740
administrator is
going to incorporate

02:51.740 --> 02:53.964
>> public keys into
the mail server.

02:53.964 --> 02:57.140
>> When I open a message for
you and I click the checkbox,

02:57.140 --> 02:58.565
that's just encrypts it.

02:58.565 --> 03:00.260
What is actually happening is

03:00.260 --> 03:01.940
my email application is pulling

03:01.940 --> 03:04.160
your name out of the
global address list

03:04.160 --> 03:06.065
along with your public key.

03:06.065 --> 03:08.135
When you receive it on your end,

03:08.135 --> 03:09.710
your e-mail application uses

03:09.710 --> 03:11.765
your private key to decrypt it.

03:11.765 --> 03:14.945
Or it could be a web
client and a web browser.

03:14.945 --> 03:17.810
A web client wants to make
a secure connection to

03:17.810 --> 03:19.190
a web server and

03:19.190 --> 03:21.455
that web browser
requests the public key,

03:21.455 --> 03:24.565
and then the web
server provides it.

03:24.565 --> 03:27.020
Again, we're not discriminating

03:27.020 --> 03:28.625
about who gets our public key.

03:28.625 --> 03:30.635
We shared that
widely and freely,

03:30.635 --> 03:31.910
because that's how people get

03:31.910 --> 03:33.725
information to us privately.

03:33.725 --> 03:35.510
Privacy will always come through

03:35.510 --> 03:37.710
>> a receiver's public key.