WEBVTT - This file was automatically generated by VIMEO

1
00:00:00.300 --> 00:00:02.800
 Okay, so now we'll talk about hybrid cryptography.

2
00:00:04.200 --> 00:00:07.600
 So we've talked about how symmetric cryptography has speed but also

3
00:00:07.600 --> 00:00:08.600
 has a number of faults.

4
00:00:09.300 --> 00:00:12.300
 And then we talked about how asymmetric cryptography solved a

5
00:00:12.300 --> 00:00:14.300
 lot of those problems, but it's slow.

6
00:00:15.400 --> 00:00:18.500
 So ultimately what I want is the speed of symmetric and

7
00:00:18.500 --> 00:00:20.100
 all the other service of asymmetric.

8
00:00:21.200 --> 00:00:24.500
 So in this section, we'll combine them into hybrid cryptography to

9
00:00:24.500 --> 00:00:25.600
 get the best of both worlds.

10
00:00:28.700 --> 00:00:31.600
 Okay, again, what we like to achieve is privacy

11
00:00:31.600 --> 00:00:35.000
 authenticity Integrity non repudiation

12
00:00:34.800 --> 00:00:37.400
 and speed we want it all.

13
00:00:38.800 --> 00:00:41.300
 Now in my mind the best way to see this is what

14
00:00:41.300 --> 00:00:42.100
 I have on this slide.

15
00:00:43.200 --> 00:00:45.300
 But let me draw it out for you so you can follow along.

16
00:00:46.800 --> 00:00:49.200
 I will be honest with you. I'm not the best artist on the

17
00:00:49.200 --> 00:00:52.200
 planet. So I use PowerPoint to draw and even that

18
00:00:52.200 --> 00:00:54.700
 is not the greatest. So bear with me.

19
00:00:56.300 --> 00:00:57.500
 So first, I have my client.

20
00:00:58.300 --> 00:01:01.200
 This is the computer that is going to want to connect and send information.

21
00:01:02.200 --> 00:01:05.000
 We'll use this scenario with SSL and TLS.

22
00:01:06.300 --> 00:01:08.200
 We also have the web server for Bank of America.

23
00:01:09.700 --> 00:01:12.300
 My client wants to have a secure connection to the Bank of America.

24
00:01:13.700 --> 00:01:17.400
 To have secure connection it would use the protocol https.

25
00:01:19.400 --> 00:01:22.200
 The client is going to send a command specifying the

26
00:01:22.200 --> 00:01:25.700
 protocol https and that says let's have

27
00:01:25.700 --> 00:01:26.300
 a secure connection.

28
00:01:27.700 --> 00:01:30.300
 And the bank server is going to say okay, and it

29
00:01:30.300 --> 00:01:32.300
 knows that the client wants the server's public key.

30
00:01:33.300 --> 00:01:35.900
 So the bank server sends the public key to the client.

31
00:01:37.700 --> 00:01:40.300
 So what we're looking at so far is asymmetric cryptography.

32
00:01:41.100 --> 00:01:41.900
 But here's the problem.

33
00:01:43.500 --> 00:01:46.600
 In addition to the fact that asymmetric cryptography is slow with

34
00:01:46.600 --> 00:01:49.600
 the banks public key only the client can send encrypted

35
00:01:49.600 --> 00:01:50.200
 messages to the bank.

36
00:01:51.300 --> 00:01:54.500
 The client doesn't have a public key to send to the bank set. The

37
00:01:54.500 --> 00:01:56.900
 bank can send encrypted messages back to the client.

38
00:01:58.200 --> 00:01:59.900
 Many people don't have public keys.

39
00:02:00.700 --> 00:02:03.400
 So this asymmetric cryptography by itself won't work

40
00:02:03.400 --> 00:02:04.200
 for the situation.

41
00:02:06.400 --> 00:02:08.800
 So the third step is where these things get interesting.

42
00:02:09.900 --> 00:02:12.600
 In the third step the client generates a symmetric

43
00:02:12.600 --> 00:02:13.200
 session key.

44
00:02:14.600 --> 00:02:17.300
 Now remember with the symmetric session key

45
00:02:17.300 --> 00:02:20.100
 the client generated the key and the client knows what

46
00:02:20.100 --> 00:02:20.400
 it is.

47
00:02:21.200 --> 00:02:24.200
 But the trick is at the bank needs the key so that a

48
00:02:24.200 --> 00:02:25.500
 secure session can be installed.

49
00:02:26.500 --> 00:02:29.300
 Is there anything the client has that can be used to encrypt the

50
00:02:29.300 --> 00:02:31.600
 session key set. Only the bank kindercrypt it.

51
00:02:32.400 --> 00:02:34.600
 Yes, it's the banks public key.

52
00:02:36.400 --> 00:02:39.100
 For the client encrypts the sessions key with the

53
00:02:39.100 --> 00:02:40.100
 banks public key.

54
00:02:42.300 --> 00:02:45.600
 So in the end we've exchanged a symmetric session key securely

55
00:02:45.600 --> 00:02:48.400
 so that way we can communicate with symmetric cryptography.

56
00:02:49.300 --> 00:02:52.200
 Because both parties know the symmetric key that is

57
00:02:52.200 --> 00:02:55.200
 going to be used to encrypt data for the bank server and also for the

58
00:02:55.200 --> 00:02:55.500
 client.

59
00:02:58.100 --> 00:03:01.200
 It took a little bit of back and forth, but there is not an easy

60
00:03:01.200 --> 00:03:02.800
 way to distribute a symmetric key.

61
00:03:03.900 --> 00:03:06.500
 So we used asymmetric key exchange and then

62
00:03:06.500 --> 00:03:08.300
 we had symmetric data Exchange.

63
00:03:10.400 --> 00:03:14.000
 Now if on the test they ask is SSL or TLS symmetric

64
00:03:13.200 --> 00:03:14.600
 or asymmetric?

65
00:03:15.300 --> 00:03:17.000
 Well, the best answer is that it's hybrid.

66
00:03:18.200 --> 00:03:21.100
 But they may not let you choose that answer. So if you have to

67
00:03:21.100 --> 00:03:24.100
 choose between symmetric and asymmetric then call it

68
00:03:24.100 --> 00:03:24.700
 asymmetric.

69
00:03:25.500 --> 00:03:28.600
 That's because we start with the process with the public key, which is

70
00:03:28.600 --> 00:03:29.900
 asymmetric cryptography.

71
00:03:31.300 --> 00:03:33.900
 They could ask what type of cryptography SSL use.

72
00:03:34.800 --> 00:03:35.800
 And that's asymmetric.

73
00:03:37.200 --> 00:03:40.300
 If they ask what type of cryptography SSL uses to encrypt data

74
00:03:40.300 --> 00:03:42.600
 in that case, it's symmetric.

75
00:03:43.700 --> 00:03:46.500
 The key exchange for ssls asymmetric. The

76
00:03:46.500 --> 00:03:48.200
 data exchange is symmetric.