WEBVTT 00:00.000 --> 00:04.635 >> Now we'll talk about MAC, Message Authentication Codes. 00:04.635 --> 00:08.100 Now, earlier we talked about hashes and how hashes 00:08.100 --> 00:11.460 are only good for detecting unintentional modification. 00:11.460 --> 00:13.590 For example, when there's 00:13.590 --> 00:15.300 corruption because a packet is dropped 00:15.300 --> 00:16.890 while a message is being sent 00:16.890 --> 00:19.470 but there is no malicious intent. 00:19.470 --> 00:22.080 Then we talked about a digital signature that 00:22.080 --> 00:24.585 can detect malicious modification. 00:24.585 --> 00:27.840 In this case, not only is the file hashed, 00:27.840 --> 00:29.250 but the file is encrypted 00:29.250 --> 00:31.109 >> with the sender's private key. 00:31.109 --> 00:32.880 >> Only the sender can encrypt 00:32.880 --> 00:34.620 something with their private key. 00:34.620 --> 00:37.230 We get authenticity and integrity 00:37.230 --> 00:39.970 together, which is non-repudiation. 00:39.970 --> 00:42.070 A digital signature is great. 00:42.070 --> 00:43.430 But a digital signature 00:43.430 --> 00:45.454 >> requires something called a PKI, 00:45.454 --> 00:48.720 >> or Public Key Infrastructure. 00:49.370 --> 00:51.885 You don't have to know what that is yet. 00:51.885 --> 00:53.420 We'll go into it later. 00:53.420 --> 00:55.955 But anytime you hear the word infrastructure, 00:55.955 --> 00:58.205 you know it's going to have a lot of overhead. 00:58.205 --> 01:00.785 Infrastructure is going to take resources, 01:00.785 --> 01:03.125 money, time, and staff. 01:03.125 --> 01:05.360 It's going to be an ongoing effort to maintain 01:05.360 --> 01:08.550 it and you have to monitor and evaluate it. 01:08.770 --> 01:11.570 It's not easy to have a PKI 01:11.570 --> 01:14.060 and it's not good enough to just use a hash. 01:14.060 --> 01:15.260 What I'd really like is 01:15.260 --> 01:16.804 >> to have something in the middle. 01:16.804 --> 01:18.350 >> What if we had something that 01:18.350 --> 01:19.954 gives us reasonable insurance 01:19.954 --> 01:21.110 against intentional 01:21.110 --> 01:23.590 modification without all the overhead. 01:23.590 --> 01:26.130 That's exactly what MAC is. 01:26.130 --> 01:28.140 Now, you'll see the acronym MAC 01:28.140 --> 01:29.594 >> used for a lot of things. 01:29.594 --> 01:31.490 >> But in this case, what it stands 01:31.490 --> 01:34.115 for is a Message Authentication Code. 01:34.115 --> 01:38.190 You also hear the terms Hash MAC or HMAC. 01:39.050 --> 01:42.020 An HMAC requires that both parties agree 01:42.020 --> 01:44.480 on something. Often it's a password. 01:44.480 --> 01:46.340 Each party enters a password on 01:46.340 --> 01:49.510 their routers or whatever device that they're using. 01:49.510 --> 01:52.185 A key is created based on the password. 01:52.185 --> 01:54.665 As long as you both enter the same password, 01:54.665 --> 01:56.225 you have the same key. 01:56.225 --> 01:59.005 That's symmetric cryptography. 01:59.005 --> 02:02.120 What happens is that the message is [inaudible] 02:02.120 --> 02:04.700 with the secret number, the symmetric key, 02:04.700 --> 02:05.900 and then put through a hashing 02:05.900 --> 02:08.330 algorithm so that each block 02:08.330 --> 02:10.250 includes knowledge of the symmetric key 02:10.250 --> 02:12.650 and grants integrity from the message. 02:12.650 --> 02:16.370 Only those two parties should know the symmetric key. 02:16.370 --> 02:18.260 Then we get a reasonable degree of 02:18.260 --> 02:21.010 authenticity and begin integrity. 02:21.010 --> 02:24.410 Now, remember, you'll never get true authenticity with 02:24.410 --> 02:25.865 symmetric cryptography 02:25.865 --> 02:28.325 because two parties know the same key. 02:28.325 --> 02:30.200 Either party could be to blame 02:30.200 --> 02:32.045 if the information is leaked. 02:32.045 --> 02:33.560 However, you can have 02:33.560 --> 02:35.450 a reasonable understanding that if the key 02:35.450 --> 02:38.660 is only shared between two parties and the key is used, 02:38.660 --> 02:41.460 then one of the two parties used it. 02:41.780 --> 02:44.435 MAC is better than a hash, 02:44.435 --> 02:46.970 but not as elaborate as a digital signature, 02:46.970 --> 02:49.720 which requires so much infrastructure. 02:49.720 --> 02:53.720 A MAC is often used with applications or services. 02:53.720 --> 02:57.215 Don't forget, a MAC is a message plus 02:57.215 --> 02:58.820 a symmetric key shared between 02:58.820 --> 03:01.745 two parties that goes through a hashing algorithm. 03:01.745 --> 03:05.250 The resulting effect is a Hash MAC.