WEBVTT

1
00:00:00.000 --> 00:00:00.833
In this lesson,

2
00:00:00.833 --> 00:00:04.080
we will learn about Cryptographic Blockers.

3
00:00:04.080 --> 00:00:08.220
Cryptographic blockers are obstacles or limitations

4
00:00:08.220 --> 00:00:11.340
that hinder or delay the implementation

5
00:00:11.340 --> 00:00:15.060
and effectiveness of encryption techniques.

6
00:00:15.060 --> 00:00:17.880
Cryptographic blockers should be assessed

7
00:00:17.880 --> 00:00:21.810
with a discussion of performance versus security.

8
00:00:21.810 --> 00:00:25.530
Performance versus security refers to the trade off

9
00:00:25.530 --> 00:00:30.360
between the speed and efficiency of cryptographic processes

10
00:00:30.360 --> 00:00:33.540
and the level of security they provide.

11
00:00:33.540 --> 00:00:34.950
Let's learn more

12
00:00:34.950 --> 00:00:38.970
about cryptographic performance versus security.

13
00:00:38.970 --> 00:00:42.870
When considering cryptographic performance versus security,

14
00:00:42.870 --> 00:00:44.790
it's important to understand

15
00:00:44.790 --> 00:00:47.190
that the trade off involves choosing

16
00:00:47.190 --> 00:00:51.750
between the computational speed of cryptographic algorithms

17
00:00:51.750 --> 00:00:55.050
and the strength of the security they provide.

18
00:00:55.050 --> 00:00:57.330
Stronger encryption algorithms,

19
00:00:57.330 --> 00:00:59.850
such as those with longer key lengths,

20
00:00:59.850 --> 00:01:03.270
or more complex cryptographic functions

21
00:01:03.270 --> 00:01:05.280
offer higher security,

22
00:01:05.280 --> 00:01:09.480
but at the cost of increased computational overhead.

23
00:01:09.480 --> 00:01:14.160
This additional overhead can slow down processing times,

24
00:01:14.160 --> 00:01:17.820
impacting the efficiency of production systems

25
00:01:17.820 --> 00:01:21.690
that rely on these cryptographic operations.

26
00:01:21.690 --> 00:01:23.940
Take the advanced encryption standard

27
00:01:23.940 --> 00:01:28.940
with a 256-bit key, or AES-256, as an example.

28
00:01:30.480 --> 00:01:32.820
AES-256 is one of

29
00:01:32.820 --> 00:01:36.300
the most secure encryption standards available,

30
00:01:36.300 --> 00:01:38.160
using a long key length

31
00:01:38.160 --> 00:01:41.940
that makes it extremely resistant to brute force attacks.

32
00:01:41.940 --> 00:01:44.820
However, this level of security

33
00:01:44.820 --> 00:01:48.180
requires significant computational resources,

34
00:01:48.180 --> 00:01:52.560
as the algorithm performs multiple rounds of substitution,

35
00:01:52.560 --> 00:01:56.880
permutation, and mixing operations to encrypt the data.

36
00:01:56.880 --> 00:01:59.340
Each round increases security,

37
00:01:59.340 --> 00:02:03.870
but also adds processing time, which can be a bottleneck

38
00:02:03.870 --> 00:02:07.680
in systems that require rapid data processing,

39
00:02:07.680 --> 00:02:10.920
such as high-frequency trading platforms

40
00:02:10.920 --> 00:02:13.350
or large-scale services.

41
00:02:13.350 --> 00:02:18.350
In contrast, a simpler algorithm like AES-128

42
00:02:18.480 --> 00:02:22.980
offers faster performance due to fewer rounds of processing

43
00:02:22.980 --> 00:02:27.810
and a shorter key length, but it provides less security.

44
00:02:27.810 --> 00:02:32.580
So while AES-128 is still considered secure

45
00:02:32.580 --> 00:02:34.500
against most attacks,

46
00:02:34.500 --> 00:02:37.410
it does not offer the same level of protection

47
00:02:37.410 --> 00:02:40.980
against future threats, such as those posed

48
00:02:40.980 --> 00:02:43.710
by the advancements in quantum computing.

49
00:02:43.710 --> 00:02:48.710
So the decision between using AES-256 and AES-128

50
00:02:50.490 --> 00:02:53.490
often hinges on the required security level

51
00:02:53.490 --> 00:02:56.280
and acceptable performance impact,

52
00:02:56.280 --> 00:02:58.140
especially in environments

53
00:02:58.140 --> 00:03:01.290
where data confidentiality is critical,

54
00:03:01.290 --> 00:03:06.290
such as military communications or financial transactions.

55
00:03:06.420 --> 00:03:10.230
Another performance versus security consideration

56
00:03:10.230 --> 00:03:13.830
is the impact on latency and bandwidth.

57
00:03:13.830 --> 00:03:17.130
Algorithms that require heavy computation

58
00:03:17.130 --> 00:03:21.090
can introduce latency, slowing down the time it takes

59
00:03:21.090 --> 00:03:25.170
for data to be securely processed and transmitted.

60
00:03:25.170 --> 00:03:29.790
For example, transport layer security, or TLS,

61
00:03:29.790 --> 00:03:32.310
which is used to secure web traffic,

62
00:03:32.310 --> 00:03:35.940
can be configured with different cryptographic suites

63
00:03:35.940 --> 00:03:39.300
that balance performance and security.

64
00:03:39.300 --> 00:03:41.910
Using more secure configurations

65
00:03:41.910 --> 00:03:46.560
like those involving elliptic curve cryptography, or ECC,

66
00:03:46.560 --> 00:03:49.920
with longer key sizes enhances security,

67
00:03:49.920 --> 00:03:52.830
but can delay page loading times,

68
00:03:52.830 --> 00:03:55.590
impacting user experience.

69
00:03:55.590 --> 00:03:59.790
Organizations often mitigate these performance impacts

70
00:03:59.790 --> 00:04:02.460
by using hardware acceleration

71
00:04:02.460 --> 00:04:06.360
such as a dedicated cryptographic processor,

72
00:04:06.360 --> 00:04:10.380
or by offloading complex cryptographic tasks

73
00:04:10.380 --> 00:04:13.710
to specialized hardware security modules.

74
00:04:13.710 --> 00:04:17.070
These solutions can significantly improve

75
00:04:17.070 --> 00:04:20.250
the performance of strong encryption algorithms

76
00:04:20.250 --> 00:04:22.830
without sacrificing security,

77
00:04:22.830 --> 00:04:25.650
making it the best of both worlds,

78
00:04:25.650 --> 00:04:27.510
and making it feasible

79
00:04:27.510 --> 00:04:32.160
to use robust encryption in high-performance environments.

80
00:04:32.160 --> 00:04:34.380
Ultimately, the decision relies

81
00:04:34.380 --> 00:04:36.900
on matching the cryptographic strength

82
00:04:36.900 --> 00:04:39.270
to the acceptable level of risk,

83
00:04:39.270 --> 00:04:42.390
ensuring that performance remains acceptable,

84
00:04:42.390 --> 00:04:44.730
without compromising the integrity

85
00:04:44.730 --> 00:04:47.400
and confidentiality of data.

86
00:04:47.400 --> 00:04:50.070
For critical applications, the emphasis

87
00:04:50.070 --> 00:04:54.300
is usually on maintaining the highest possible security,

88
00:04:54.300 --> 00:04:57.810
even if it means investing in more powerful hardware

89
00:04:57.810 --> 00:05:01.230
or accepting slower processing times.

90
00:05:01.230 --> 00:05:04.800
So remember, cryptographic blockers

91
00:05:04.800 --> 00:05:08.250
are challenges that impact the implementation

92
00:05:08.250 --> 00:05:11.550
and effectiveness of encryption techniques,

93
00:05:11.550 --> 00:05:13.830
often involving a trade off

94
00:05:13.830 --> 00:05:16.950
between performance and security.

95
00:05:16.950 --> 00:05:20.280
Performance versus security is about balancing

96
00:05:20.280 --> 00:05:24.240
the speed and efficiency of cryptographic algorithms

97
00:05:24.240 --> 00:05:27.180
with the level of protection they provide.

98
00:05:27.180 --> 00:05:30.630
Stronger encryption offers higher security,

99
00:05:30.630 --> 00:05:34.020
but requires more computational resources,

100
00:05:34.020 --> 00:05:36.990
which can slow down processing times.

101
00:05:36.990 --> 00:05:40.620
This trade off is an important factor to consider

102
00:05:40.620 --> 00:05:42.270
when designing systems

103
00:05:42.270 --> 00:05:45.360
where the goal is to find the right balance,

104
00:05:45.360 --> 00:05:49.740
ensuring that encryption is robust enough to protect data

105
00:05:49.740 --> 00:05:51.300
without excessively

106
00:05:51.300 --> 00:05:55.443
and unnecessarily hindering system performance.