WEBVTT

1
00:00:00.150 --> 00:00:01.530
In this lesson,

2
00:00:01.530 --> 00:00:06.390
we will learn about Symmetric Cryptography Considerations.

3
00:00:06.390 --> 00:00:09.030
Symmetric cryptography considerations

4
00:00:09.030 --> 00:00:13.530
include resource considerations, as well as comparing

5
00:00:13.530 --> 00:00:18.240
centralized versus decentralized key management techniques.

6
00:00:18.240 --> 00:00:21.870
Big picture symmetric cryptography considerations

7
00:00:21.870 --> 00:00:25.470
involve evaluating the efficiency, security,

8
00:00:25.470 --> 00:00:29.610
and practicality of using symmetric encryption.

9
00:00:29.610 --> 00:00:32.820
One important cryptographic consideration

10
00:00:32.820 --> 00:00:35.550
is the amount of resources that are needed

11
00:00:35.550 --> 00:00:37.560
to apply the encryption.

12
00:00:37.560 --> 00:00:39.690
Another important consideration

13
00:00:39.690 --> 00:00:44.070
is the management of centralized and decentralized keys.

14
00:00:44.070 --> 00:00:48.210
Centralized key management involves a single entity

15
00:00:48.210 --> 00:00:51.060
controlling all the encryption keys.

16
00:00:51.060 --> 00:00:54.480
Decentralized key management distributes control

17
00:00:54.480 --> 00:00:57.750
of the keys across multiple entities.

18
00:00:57.750 --> 00:01:01.410
Let's learn more about resource considerations,

19
00:01:01.410 --> 00:01:05.880
and centralized versus decentralized key management.

20
00:01:05.880 --> 00:01:09.630
First, we have resource considerations.

21
00:01:09.630 --> 00:01:12.120
Resource considerations are critical

22
00:01:12.120 --> 00:01:15.060
when evaluating symmetric cryptography

23
00:01:15.060 --> 00:01:19.320
because resource use directly impacts performance,

24
00:01:19.320 --> 00:01:23.310
efficiency, and the feasibility of encryption.

25
00:01:23.310 --> 00:01:28.110
Computational power, memory usage, hardware acceleration,

26
00:01:28.110 --> 00:01:32.100
and power consumption are key factors that influence

27
00:01:32.100 --> 00:01:35.040
the choice of encryption algorithms

28
00:01:35.040 --> 00:01:38.100
based on resource considerations.

29
00:01:38.100 --> 00:01:42.300
Computational demand refers to the processing power

30
00:01:42.300 --> 00:01:45.600
required for encryption and decryption,

31
00:01:45.600 --> 00:01:47.550
which can be a bottleneck

32
00:01:47.550 --> 00:01:51.600
in resource-constrained environments like mobile devices

33
00:01:51.600 --> 00:01:55.320
and internet of things (IoT) sensors.

34
00:01:55.320 --> 00:01:58.950
Memory usage, which includes storing keys,

35
00:01:58.950 --> 00:02:02.640
initialization vectors, and intermediate data,

36
00:02:02.640 --> 00:02:05.910
can also strain low memory devices,

37
00:02:05.910 --> 00:02:10.260
particularly with algorithms that use large block sizes

38
00:02:10.260 --> 00:02:13.080
or multiple encryption rounds.

39
00:02:13.080 --> 00:02:17.490
Hardware acceleration, often available in modern processors,

40
00:02:17.490 --> 00:02:20.250
significantly boost the performance

41
00:02:20.250 --> 00:02:22.950
of resource intensive algorithms

42
00:02:22.950 --> 00:02:26.580
like the advanced encryption standard (AES),

43
00:02:26.580 --> 00:02:29.910
making them faster and more efficient.

44
00:02:29.910 --> 00:02:34.140
However, in the absence of such hardware support,

45
00:02:34.140 --> 00:02:36.360
algorithms like 3DES,

46
00:02:36.360 --> 00:02:38.640
or the triple data encryption standard,

47
00:02:38.640 --> 00:02:41.580
can become slow and resource heavy,

48
00:02:41.580 --> 00:02:45.090
especially in software only environments.

49
00:02:45.090 --> 00:02:48.840
Power consumption is another critical resource,

50
00:02:48.840 --> 00:02:52.110
especially for battery operated devices

51
00:02:52.110 --> 00:02:56.010
where encryption algorithms with extensive computations

52
00:02:56.010 --> 00:02:58.200
can drain power quickly.

53
00:02:58.200 --> 00:03:01.500
Lightweight algorithms, like Chacha20,

54
00:03:01.500 --> 00:03:06.180
are optimized to minimize processing and power usage,

55
00:03:06.180 --> 00:03:08.670
making them ideal for devices

56
00:03:08.670 --> 00:03:11.940
where maintaining battery life is crucial.

57
00:03:11.940 --> 00:03:15.660
Overall, AES is generally efficient

58
00:03:15.660 --> 00:03:18.720
with hardware acceleration, but can become

59
00:03:18.720 --> 00:03:22.320
resource intensive with larger key sizes.

60
00:03:22.320 --> 00:03:25.230
DES is light on resources,

61
00:03:25.230 --> 00:03:28.920
but insecure due to its short key length.

62
00:03:28.920 --> 00:03:32.250
3DES is resource heavy

63
00:03:32.250 --> 00:03:36.060
because it applies DES three times per block,

64
00:03:36.060 --> 00:03:40.620
consuming significant CPU and memory resources.

65
00:03:40.620 --> 00:03:44.310
Blowfish is fast and low on memory,

66
00:03:44.310 --> 00:03:46.650
but uses a smaller block size,

67
00:03:46.650 --> 00:03:49.230
which can pose security risks.

68
00:03:49.230 --> 00:03:52.200
Twofish offers more security,

69
00:03:52.200 --> 00:03:54.930
but at a higher computational cost.

70
00:03:54.930 --> 00:03:58.950
RC4 is very light on resources,

71
00:03:58.950 --> 00:04:02.136
but is outdated and insecure.

72
00:04:02.136 --> 00:04:07.136
ChaCha20 balances strong security with low resource demands,

73
00:04:07.650 --> 00:04:12.090
making it suitable for modern low-power environments.

74
00:04:12.090 --> 00:04:16.830
Balancing resource requirements with security needs is hard.

75
00:04:16.830 --> 00:04:19.650
But it ensures symmetric encryption

76
00:04:19.650 --> 00:04:22.710
is effective across diverse platforms,

77
00:04:22.710 --> 00:04:26.970
from high-end performance servers to embedded systems.

78
00:04:26.970 --> 00:04:31.260
So symmetric cryptography is widely used

79
00:04:31.260 --> 00:04:33.210
because of its efficiency

80
00:04:33.210 --> 00:04:36.690
and overall low resource requirements.

81
00:04:36.690 --> 00:04:41.580
However, one of the main challenges of symmetric encryption

82
00:04:41.580 --> 00:04:44.820
is managing the encryption keys securely.

83
00:04:44.820 --> 00:04:48.270
Meaning that one of the biggest disadvantages

84
00:04:48.270 --> 00:04:51.240
of symmetric encryption is the need

85
00:04:51.240 --> 00:04:56.160
to distribute the symmetric key securely between all parties

86
00:04:56.160 --> 00:04:59.310
who need to encrypt and decrypt the data.

87
00:04:59.310 --> 00:05:04.080
During distribution, if the key falls into the wrong hands,

88
00:05:04.080 --> 00:05:08.670
the entire security of the system is compromised.

89
00:05:08.670 --> 00:05:11.610
Second, let's talk about centralized

90
00:05:11.610 --> 00:05:14.430
versus decentralized key management.

91
00:05:14.430 --> 00:05:17.100
Assuming secure key distribution,

92
00:05:17.100 --> 00:05:19.020
in centralized key management,

93
00:05:19.020 --> 00:05:23.430
a single entity controls all the encryption keys.

94
00:05:23.430 --> 00:05:27.540
This approach simplifies the key management process,

95
00:05:27.540 --> 00:05:29.310
making it easier to manage

96
00:05:29.310 --> 00:05:32.790
and update keys from one location.

97
00:05:32.790 --> 00:05:36.270
For example, in a large organization,

98
00:05:36.270 --> 00:05:39.480
having a centralized key management system

99
00:05:39.480 --> 00:05:43.320
allows IT administrators to control access

100
00:05:43.320 --> 00:05:46.920
to keys efficiently, ensuring that employees

101
00:05:46.920 --> 00:05:51.120
have the necessary keys to access sensitive data

102
00:05:51.120 --> 00:05:55.530
without the need for individual management of each key.

103
00:05:55.530 --> 00:05:59.850
However, centralized key management also creates

104
00:05:59.850 --> 00:06:02.130
a single point of failure.

105
00:06:02.130 --> 00:06:06.000
If the central key management system is breached or fails,

106
00:06:06.000 --> 00:06:08.340
all of the keys could be compromised,

107
00:06:08.340 --> 00:06:12.000
exposing the entire organization's data.

108
00:06:12.000 --> 00:06:14.820
Assuming secure key distribution again,

109
00:06:14.820 --> 00:06:18.330
decentralized key management distributes control

110
00:06:18.330 --> 00:06:21.990
of encryption keys across multiple entities.

111
00:06:21.990 --> 00:06:25.890
This approach enhances security because no single point

112
00:06:25.890 --> 00:06:30.660
of failure exists, making it more resilient against attack.

113
00:06:30.660 --> 00:06:34.080
Decentralized key management is often used

114
00:06:34.080 --> 00:06:38.250
in complex environments like multi-cloud setups,

115
00:06:38.250 --> 00:06:42.720
where keys are managed separately by each cloud provider.

116
00:06:42.720 --> 00:06:46.980
This setup ensures that no single provider

117
00:06:46.980 --> 00:06:49.530
has control over all keys,

118
00:06:49.530 --> 00:06:52.110
adding an extra layer of security.

119
00:06:52.110 --> 00:06:56.100
However, the trade-off is increased complexity.

120
00:06:56.100 --> 00:07:00.030
Managing keys across multiple locations or entities

121
00:07:00.030 --> 00:07:03.990
requires more coordination, making it harder to implement

122
00:07:03.990 --> 00:07:08.250
and maintain compared to the centralized approach.

123
00:07:08.250 --> 00:07:11.370
Choosing between centralized and decentralized

124
00:07:11.370 --> 00:07:14.490
key management depends on the specific needs

125
00:07:14.490 --> 00:07:17.100
and risks of the environment.

126
00:07:17.100 --> 00:07:20.490
While centralized management offers simplicity

127
00:07:20.490 --> 00:07:25.020
and ease of use, it requires robust security measures

128
00:07:25.020 --> 00:07:27.570
to protect the key repository.

129
00:07:27.570 --> 00:07:31.530
Decentralized management offers stronger security

130
00:07:31.530 --> 00:07:34.770
through distribution, but comes with the challenges

131
00:07:34.770 --> 00:07:39.720
of managing keys across various platforms or departments.

132
00:07:39.720 --> 00:07:43.380
Understanding these trade-offs helps organizations

133
00:07:43.380 --> 00:07:46.170
select the best key management strategy

134
00:07:46.170 --> 00:07:49.590
to compliment their symmetric encryption methods,

135
00:07:49.590 --> 00:07:52.890
balancing security with practicality.

136
00:07:52.890 --> 00:07:56.940
But what about that secure key distribution?

137
00:07:56.940 --> 00:08:00.330
Well, symmetric encryption can't solve that problem

138
00:08:00.330 --> 00:08:01.530
all on its own.

139
00:08:01.530 --> 00:08:05.850
So we will discuss asymmetric encryption algorithms

140
00:08:05.850 --> 00:08:09.840
that can solve this problem, as well as other use cases

141
00:08:09.840 --> 00:08:13.140
for asymmetric encryption in another lesson.

142
00:08:13.140 --> 00:08:17.100
So remember, symmetric cryptography

143
00:08:17.100 --> 00:08:19.560
involves using the same key

144
00:08:19.560 --> 00:08:22.740
for both encryption and decryption.

145
00:08:22.740 --> 00:08:25.710
Making it efficient, but also requiring

146
00:08:25.710 --> 00:08:29.940
careful consideration of resources and key management.

147
00:08:29.940 --> 00:08:32.790
Resource considerations are crucial

148
00:08:32.790 --> 00:08:36.420
because they affect the performance and practicality

149
00:08:36.420 --> 00:08:40.620
of encryption with factors like computational power,

150
00:08:40.620 --> 00:08:43.770
memory usage, hardware acceleration,

151
00:08:43.770 --> 00:08:46.980
and power consumption, playing key roles

152
00:08:46.980 --> 00:08:49.260
in the algorithm selection.

153
00:08:49.260 --> 00:08:52.800
Distributing the symmetric encryption key securely

154
00:08:52.800 --> 00:08:57.360
is also a major challenge, as a compromised key

155
00:08:57.360 --> 00:09:01.080
can undermine the entire security system.

156
00:09:01.080 --> 00:09:04.170
Key management can be either centralized,

157
00:09:04.170 --> 00:09:07.920
where one entity controls all keys for simplicity,

158
00:09:07.920 --> 00:09:10.740
but risks being a single point of failure.

159
00:09:10.740 --> 00:09:14.160
Or decentralized, where keys are distributed

160
00:09:14.160 --> 00:09:17.640
across multiple entities to enhance security,

161
00:09:17.640 --> 00:09:20.010
but increase complexity.

162
00:09:20.010 --> 00:09:23.370
Balancing these factors, resource requirements,

163
00:09:23.370 --> 00:09:27.480
secure key distribution, and the choice between centralized

164
00:09:27.480 --> 00:09:29.460
and decentralized key management,

165
00:09:29.460 --> 00:09:32.340
is essential for effectively implementing

166
00:09:32.340 --> 00:09:36.183
symmetric cryptography in an enterprise environment.