WEBVTT 00:00:00.000 --> 00:00:01.996 align:middle line:90% [SQUEAKING] 00:00:01.996 --> 00:00:03.992 align:middle line:90% [RUSTLING] 00:00:03.992 --> 00:00:05.988 align:middle line:90% [CLICKING] 00:00:05.988 --> 00:00:12.980 align:middle line:90% 00:00:12.980 --> 00:00:16.309 align:middle line:90% YAEL T. KALAI: Let's start. 00:00:16.309 --> 00:00:19.590 align:middle line:84% So first homework assignment is out. 00:00:19.590 --> 00:00:25.310 align:middle line:84% As I said, it's due right before Thanksgiving. 00:00:25.310 --> 00:00:28.790 align:middle line:84% If anybody needs an extension, just let me know. 00:00:28.790 --> 00:00:33.110 align:middle line:84% And the instructions are on the site. 00:00:33.110 --> 00:00:37.598 align:middle line:84% Essentially, each one should write like their own solution so 00:00:37.598 --> 00:00:38.640 align:middle line:90% make sure you understand. 00:00:38.640 --> 00:00:40.670 align:middle line:84% It's OK if you talk among one another 00:00:40.670 --> 00:00:42.060 align:middle line:90% as long as it's fruitful. 00:00:42.060 --> 00:00:44.450 align:middle line:84% And please type it up in LATAC and submit it 00:00:44.450 --> 00:00:45.420 align:middle line:90% through Gradescope. 00:00:45.420 --> 00:00:45.920 align:middle line:90% Questions? 00:00:45.920 --> 00:00:46.420 align:middle line:90% Yeah. 00:00:46.420 --> 00:00:49.790 align:middle line:84% AUDIENCE: Is there a Gradescope code for this class? 00:00:49.790 --> 00:00:52.520 align:middle line:84% In GradeScope, I thought you go into GradeScope online 00:00:52.520 --> 00:00:53.480 align:middle line:90% to do that. 00:00:53.480 --> 00:00:54.230 align:middle line:90% YAEL T. KALAI: Oh. 00:00:54.230 --> 00:00:58.820 align:middle line:90% 00:00:58.820 --> 00:01:01.925 align:middle line:84% Why can't you-- don't you use Gradescope for other classes? 00:01:01.925 --> 00:01:02.550 align:middle line:90% AUDIENCE: Yeah. 00:01:02.550 --> 00:01:04.580 align:middle line:90% But I'm mostly in this class. 00:01:04.580 --> 00:01:05.850 align:middle line:90% YAEL T. KALAI: Oh, no, it is. 00:01:05.850 --> 00:01:06.810 align:middle line:90% It is now. 00:01:06.810 --> 00:01:07.920 align:middle line:90% When did you check? 00:01:07.920 --> 00:01:08.462 align:middle line:90% AUDIENCE: Oh. 00:01:08.462 --> 00:01:09.780 align:middle line:90% It is like a while ago. 00:01:09.780 --> 00:01:11.040 align:middle line:90% YAEL T. KALAI: It's recently. 00:01:11.040 --> 00:01:11.600 align:middle line:90% Yeah. 00:01:11.600 --> 00:01:13.140 align:middle line:90% If there's issues, let me know. 00:01:13.140 --> 00:01:13.640 align:middle line:90% Yeah. 00:01:13.640 --> 00:01:15.470 align:middle line:90% This class is assigned. 00:01:15.470 --> 00:01:18.500 align:middle line:84% There is a GradeScope site for this. 00:01:18.500 --> 00:01:24.290 align:middle line:84% Any other questions before we start? 00:01:24.290 --> 00:01:26.180 align:middle line:90% OK. 00:01:26.180 --> 00:01:29.660 align:middle line:84% So just a quick recap, so last time 00:01:29.660 --> 00:01:32.970 align:middle line:84% we talked about the Kilian-Micali protocol. 00:01:32.970 --> 00:01:34.680 align:middle line:90% It's an interactive argument. 00:01:34.680 --> 00:01:37.550 align:middle line:84% It's a succinct, interactive argument 00:01:37.550 --> 00:01:42.950 align:middle line:84% which you can use to prove membership in any NP language. 00:01:42.950 --> 00:01:45.140 align:middle line:84% And if you recall, the idea was we 00:01:45.140 --> 00:01:48.930 align:middle line:84% started before that was kind of our entrance to cryptography. 00:01:48.930 --> 00:01:51.800 align:middle line:84% So we said the idea of the Kilian-Micali protocol 00:01:51.800 --> 00:01:55.460 align:middle line:84% is that you take any PCP, which is very, very large 00:01:55.460 --> 00:01:58.600 align:middle line:84% but very efficiently, if you just have RAM access to it, 00:01:58.600 --> 00:02:00.580 align:middle line:84% you can verify it very efficiently. 00:02:00.580 --> 00:02:03.330 align:middle line:84% And the idea is you take this very, very large PCP 00:02:03.330 --> 00:02:11.310 align:middle line:84% and you shrink it to digest it down using cryptography 00:02:11.310 --> 00:02:13.240 align:middle line:90% to this kind of succinct digest. 00:02:13.240 --> 00:02:16.100 align:middle line:84% This is done using hash function but, 00:02:16.100 --> 00:02:18.300 align:middle line:84% in particular, Merkle hash or hash 00:02:18.300 --> 00:02:22.060 align:middle line:84% function that are succinct but can be opened locally. 00:02:22.060 --> 00:02:24.540 align:middle line:84% So I'll recall what this is in a second. 00:02:24.540 --> 00:02:30.460 align:middle line:84% And once the prover sends over a squished form of the PCP, 00:02:30.460 --> 00:02:33.580 align:middle line:84% then the verifier now behaves like he's a PCP verifier. 00:02:33.580 --> 00:02:36.810 align:middle line:84% He tells the prover, open this PCP and the location 00:02:36.810 --> 00:02:40.420 align:middle line:84% that the PCP verifier would want to open. 00:02:40.420 --> 00:02:42.730 align:middle line:90% And he gets back the openings. 00:02:42.730 --> 00:02:48.460 align:middle line:84% So that's what the Kilian-Micali protocol is. 00:02:48.460 --> 00:02:51.390 align:middle line:90% But in order to-- 00:02:51.390 --> 00:02:54.030 align:middle line:84% when I said it squishes down and then there's 00:02:54.030 --> 00:02:56.970 align:middle line:84% opening, really, what we need is, A, 00:02:56.970 --> 00:02:58.900 align:middle line:90% we want to take a hash function. 00:02:58.900 --> 00:03:01.680 align:middle line:84% So if you remember, a hash function is-- 00:03:01.680 --> 00:03:04.320 align:middle line:84% consists of a key generation algorithm 00:03:04.320 --> 00:03:07.440 align:middle line:84% that generates a hash key and an eval algorithm that 00:03:07.440 --> 00:03:10.230 align:middle line:84% take a hash key and an input and generates a digest, 00:03:10.230 --> 00:03:12.960 align:middle line:90% or a hash value. 00:03:12.960 --> 00:03:19.270 align:middle line:84% Last time, we talked we-- showed how to get a hash value-- 00:03:19.270 --> 00:03:21.760 align:middle line:84% how to construct from the discrete log-- 00:03:21.760 --> 00:03:25.470 align:middle line:84% we showed how to construct a hash function 00:03:25.470 --> 00:03:27.600 align:middle line:90% from 2 lambda, 2 lambda. 00:03:27.600 --> 00:03:29.450 align:middle line:90% It takes two lambda bits. 00:03:29.450 --> 00:03:33.600 align:middle line:84% The lambda bits actually was z, p to the 2 lambda 00:03:33.600 --> 00:03:35.560 align:middle line:90% to zp to lambda. 00:03:35.560 --> 00:03:40.620 align:middle line:84% But anyway, one can encode it to have to be 0, 1 to the 2 lambda 00:03:40.620 --> 00:03:42.540 align:middle line:90% to 0, 1 to the lambda. 00:03:42.540 --> 00:03:46.750 align:middle line:84% But this is actually not enough for the Kilian-Micali protocol. 00:03:46.750 --> 00:03:49.830 align:middle line:84% What we actually need is a collision-resistant hash 00:03:49.830 --> 00:03:50.380 align:middle line:90% function. 00:03:50.380 --> 00:03:52.338 align:middle line:84% First, it needs to be much bigger because we're 00:03:52.338 --> 00:03:53.680 align:middle line:90% taking a gigantic PCP. 00:03:53.680 --> 00:03:56.610 align:middle line:84% We want to squish it way more than half. 00:03:56.610 --> 00:03:59.070 align:middle line:90% This takes-- make-- 00:03:59.070 --> 00:04:02.530 align:middle line:84% squishes the size-- reduces the size from 2 lambda to lambda. 00:04:02.530 --> 00:04:04.660 align:middle line:84% So it squishes it by a factor of 2. 00:04:04.660 --> 00:04:07.706 align:middle line:84% We actually want to squish it a much bigger factor. 00:04:07.706 --> 00:04:10.330 align:middle line:90% So we want to take eval-- 00:04:10.330 --> 00:04:12.690 align:middle line:84% what we use actually is an eval algorithm 00:04:12.690 --> 00:04:16.540 align:middle line:84% that takes strings of size 2 to the lambda to lambda. 00:04:16.540 --> 00:04:18.490 align:middle line:84% So note here the lambda is upstairs. 00:04:18.490 --> 00:04:20.410 align:middle line:84% It's very different than 2 lambda. 00:04:20.410 --> 00:04:23.820 align:middle line:90% It's exponential difference. 00:04:23.820 --> 00:04:27.270 align:middle line:84% So we take a hash function that goes-- 00:04:27.270 --> 00:04:30.340 align:middle line:84% takes gigantic strings to lambda. 00:04:30.340 --> 00:04:32.940 align:middle line:84% And moreover, another property that we want 00:04:32.940 --> 00:04:34.480 align:middle line:90% is we can open locally. 00:04:34.480 --> 00:04:36.900 align:middle line:84% Remember, we said the way the Kilian-Micali protocol 00:04:36.900 --> 00:04:42.570 align:middle line:84% works is that the verifier asks, you committed a gigantic PCP. 00:04:42.570 --> 00:04:46.870 align:middle line:84% Open it in location 3, 7, and 15. 00:04:46.870 --> 00:04:48.695 align:middle line:90% Now, how do you open it? 00:04:48.695 --> 00:04:52.630 align:middle line:84% So we also want a opening algorithm. 00:04:52.630 --> 00:04:55.340 align:middle line:84% So really, what we needed when we talked about Merkle hash, 00:04:55.340 --> 00:04:58.610 align:middle line:90% or hashes with local opening-- 00:04:58.610 --> 00:05:02.180 align:middle line:84% in addition to having a key generation and eval algorithm, 00:05:02.180 --> 00:05:04.390 align:middle line:84% we also have a open algorithm that 00:05:04.390 --> 00:05:08.607 align:middle line:84% generates a succinct opening and which 00:05:08.607 --> 00:05:10.690 align:middle line:84% can be verified in the verification algorithm that 00:05:10.690 --> 00:05:11.630 align:middle line:90% verifies it. 00:05:11.630 --> 00:05:14.410 align:middle line:84% So last time, when we constructed this Merkle hash-- 00:05:14.410 --> 00:05:16.010 align:middle line:90% I'll recall it today quickly. 00:05:16.010 --> 00:05:20.150 align:middle line:84% And we ended with how-- proving that it's collision-resistant. 00:05:20.150 --> 00:05:22.340 align:middle line:84% So that's where we're going to start today. 00:05:22.340 --> 00:05:26.080 align:middle line:84% We're going to just wrap up the Kilian-Micali protocol 00:05:26.080 --> 00:05:28.930 align:middle line:84% by explaining the thing that was left 00:05:28.930 --> 00:05:33.400 align:middle line:84% is to argue that this Merkle hash construction is, indeed, 00:05:33.400 --> 00:05:34.610 align:middle line:90% collision-resistant. 00:05:34.610 --> 00:05:38.290 align:middle line:84% So that's where we're going to start today. 00:05:38.290 --> 00:05:41.950 align:middle line:84% So once we do that, once we argue that we have this Merkle 00:05:41.950 --> 00:05:43.970 align:middle line:84% hash, we prove that it's collision-resistant, 00:05:43.970 --> 00:05:46.130 align:middle line:84% then we're done with the Kilian-Micali. 00:05:46.130 --> 00:05:51.380 align:middle line:84% You actually proved that it's sound under this assumption. 00:05:51.380 --> 00:05:55.130 align:middle line:84% So where are we heading today after we finish the Merkle hash? 00:05:55.130 --> 00:06:01.300 align:middle line:84% Now we actually showed a succinct argument for all of np. 00:06:01.300 --> 00:06:02.180 align:middle line:90% This is great. 00:06:02.180 --> 00:06:03.790 align:middle line:90% However, it's interactive. 00:06:03.790 --> 00:06:07.930 align:middle line:84% And interactive proofs or arguments are really-- 00:06:07.930 --> 00:06:10.400 align:middle line:90% they're not very useful. 00:06:10.400 --> 00:06:14.120 align:middle line:84% And the reason they're not very useful is for many reasons. 00:06:14.120 --> 00:06:15.290 align:middle line:90% A, there's latency. 00:06:15.290 --> 00:06:17.120 align:middle line:84% We need to talk back, forth, back, forth. 00:06:17.120 --> 00:06:20.860 align:middle line:84% But another reason, perhaps much more important, 00:06:20.860 --> 00:06:23.570 align:middle line:90% is that it's per verifier. 00:06:23.570 --> 00:06:27.440 align:middle line:84% So if I want to just prove to the world some statement, 00:06:27.440 --> 00:06:28.760 align:middle line:90% I can prove it using-- 00:06:28.760 --> 00:06:31.120 align:middle line:84% I'm not going to go to each person in the world 00:06:31.120 --> 00:06:33.200 align:middle line:84% and give them an interactive proof. 00:06:33.200 --> 00:06:35.060 align:middle line:84% So it's really verifier-specific. 00:06:35.060 --> 00:06:37.070 align:middle line:84% Interactive proofs are verifier-specific. 00:06:37.070 --> 00:06:41.420 align:middle line:84% It convinces the specific verifier you talk with. 00:06:41.420 --> 00:06:45.540 align:middle line:84% And we want a prove that convinces everyone. 00:06:45.540 --> 00:06:49.340 align:middle line:84% So that's where-- the segue we're taking today. 00:06:49.340 --> 00:06:52.690 align:middle line:84% How do we construct, actually, non-interactive, 00:06:52.690 --> 00:06:56.470 align:middle line:84% one that will-- to reduce interaction? 00:06:56.470 --> 00:07:01.400 align:middle line:84% So what we're going to show is how to eliminate interaction. 00:07:01.400 --> 00:07:02.860 align:middle line:84% And this is going to be done using 00:07:02.860 --> 00:07:05.360 align:middle line:84% a really beautiful paradigm called the Fiat-Shamir paradigm. 00:07:05.360 --> 00:07:07.070 align:middle line:84% So I'm going to explain what it is. 00:07:07.070 --> 00:07:08.530 align:middle line:90% It's very, very simple. 00:07:08.530 --> 00:07:10.900 align:middle line:84% And then we're going to introduce the random oracle 00:07:10.900 --> 00:07:14.710 align:middle line:84% model, which is a model that was invented in order to-- 00:07:14.710 --> 00:07:18.340 align:middle line:84% an attempt to analyze or to understand the security 00:07:18.340 --> 00:07:21.130 align:middle line:90% of this Fiat-Shamir paradigm. 00:07:21.130 --> 00:07:23.080 align:middle line:90% It's an ideal model. 00:07:23.080 --> 00:07:25.420 align:middle line:84% We're going to prove the soundness 00:07:25.420 --> 00:07:28.550 align:middle line:84% of the Kilian-Micali protocol that we saw last time. 00:07:28.550 --> 00:07:31.300 align:middle line:84% We're going to actually show that it's sound, 00:07:31.300 --> 00:07:34.277 align:middle line:84% even if you apply the Fiat-Shamir paradigm to it, as 00:07:34.277 --> 00:07:35.860 align:middle line:84% long as you rely on this random oracle 00:07:35.860 --> 00:07:38.505 align:middle line:90% model and this ideal model. 00:07:38.505 --> 00:07:40.630 align:middle line:84% And then we're going to-- probably this we're going 00:07:40.630 --> 00:07:42.165 align:middle line:90% to only get till next time. 00:07:42.165 --> 00:07:43.540 align:middle line:84% But we're going to try to-- we're 00:07:43.540 --> 00:07:46.270 align:middle line:84% going to talk about the soundness of the Fiat-Shamir 00:07:46.270 --> 00:07:48.200 align:middle line:90% and the standard model. 00:07:48.200 --> 00:07:50.750 align:middle line:84% So again, we're going to talk about eliminating interaction 00:07:50.750 --> 00:07:53.548 align:middle line:84% using Fiat-Shamir, talk about the random oracle model, 00:07:53.548 --> 00:07:56.090 align:middle line:84% show that, actually, the random oracle model of this paradigm 00:07:56.090 --> 00:07:57.090 align:middle line:90% works well. 00:07:57.090 --> 00:08:00.690 align:middle line:84% Often, we'll see exactly when it works well, when it doesn't. 00:08:00.690 --> 00:08:02.660 align:middle line:84% And then we're going to talk about, 00:08:02.660 --> 00:08:05.967 align:middle line:84% if we have time maybe-- start talking about security 00:08:05.967 --> 00:08:08.300 align:middle line:84% in the standard model because the random oracle model is 00:08:08.300 --> 00:08:10.140 align:middle line:90% not a-- it's an ideal model. 00:08:10.140 --> 00:08:11.220 align:middle line:90% So is it secure? 00:08:11.220 --> 00:08:15.500 align:middle line:84% Is it sound in-- when used in actual reality? 00:08:15.500 --> 00:08:16.530 align:middle line:90% That's the plan. 00:08:16.530 --> 00:08:17.030 align:middle line:90% Questions? 00:08:17.030 --> 00:08:17.730 align:middle line:90% Yes? 00:08:17.730 --> 00:08:19.938 align:middle line:84% AUDIENCE: You shouldn't be able to do 2 to the lambda 00:08:19.938 --> 00:08:21.900 align:middle line:90% because your thing-- 00:08:21.900 --> 00:08:26.130 align:middle line:84% if you're hashing something that long, you'll find a collision? 00:08:26.130 --> 00:08:31.430 align:middle line:84% YAEL T. KALAI: So of course, you can find a collision. 00:08:31.430 --> 00:08:34.159 align:middle line:90% So we define it-- 00:08:34.159 --> 00:08:38.690 align:middle line:84% so the question was about this 2 to the lambda. 00:08:38.690 --> 00:08:40.492 align:middle line:90% We'll see the construction. 00:08:40.492 --> 00:08:41.034 align:middle line:90% I'll explain. 00:08:41.034 --> 00:08:44.410 align:middle line:90% 00:08:44.410 --> 00:08:46.890 align:middle line:84% We get completeness for 2 to the lambda. 00:08:46.890 --> 00:08:48.950 align:middle line:84% Now you're talking about soundness. 00:08:48.950 --> 00:08:55.490 align:middle line:84% Soundness says that any poly adversary or t-time adversary-- 00:08:55.490 --> 00:08:59.810 align:middle line:84% poly lambda adversary or t-- poly and t lambda adversary 00:08:59.810 --> 00:09:01.500 align:middle line:90% cannot find a collision. 00:09:01.500 --> 00:09:04.062 align:middle line:84% Now, if this t is 2 to the lambda, 00:09:04.062 --> 00:09:05.520 align:middle line:84% then you're not going to be secure. 00:09:05.520 --> 00:09:08.390 align:middle line:84% So the assumption will-- so there's-- this is 00:09:08.390 --> 00:09:09.380 align:middle line:90% for completeness. 00:09:09.380 --> 00:09:12.450 align:middle line:84% For soundness, the assumption is-- for collision-resistant, 00:09:12.450 --> 00:09:17.630 align:middle line:84% the definition is that no poly lambda time or poly t lambda, 00:09:17.630 --> 00:09:20.210 align:middle line:84% depending on if you want standard collision-resistant 00:09:20.210 --> 00:09:23.840 align:middle line:84% or t-collision-resistant, which is a slightly stronger 00:09:23.840 --> 00:09:26.570 align:middle line:84% assumption, cannot find collisions. 00:09:26.570 --> 00:09:27.290 align:middle line:90% Great. 00:09:27.290 --> 00:09:28.290 align:middle line:90% Thanks for the question. 00:09:28.290 --> 00:09:31.940 align:middle line:90% Any other questions? 00:09:31.940 --> 00:09:35.780 align:middle line:84% I like questions-- just reminding you guys. 00:09:35.780 --> 00:09:36.360 align:middle line:90% Yeah? 00:09:36.360 --> 00:09:37.902 align:middle line:84% AUDIENCE: So during this whole thing, 00:09:37.902 --> 00:09:39.960 align:middle line:84% I'm trying to imagine how big are the parameters. 00:09:39.960 --> 00:09:44.660 align:middle line:84% So n inside of the input is something that's-- 00:09:44.660 --> 00:09:47.822 align:middle line:84% normal people can read, or [INAUDIBLE]? 00:09:47.822 --> 00:09:48.780 align:middle line:90% YAEL T. KALAI: Exactly. 00:09:48.780 --> 00:09:51.140 align:middle line:84% So let me talk a little bit about the parameters. 00:09:51.140 --> 00:09:52.140 align:middle line:90% That's a great question. 00:09:52.140 --> 00:09:54.180 align:middle line:84% That's a good thing to start with. 00:09:54.180 --> 00:09:56.100 align:middle line:90% So we want succinctness. 00:09:56.100 --> 00:09:59.030 align:middle line:84% Now, when we say succinct, really, what we want is-- 00:09:59.030 --> 00:10:01.140 align:middle line:84% so we get some things by using cryptography. 00:10:01.140 --> 00:10:04.370 align:middle line:84% Once we use cryptography, things grow with the security 00:10:04.370 --> 00:10:05.730 align:middle line:90% of the-- that we want. 00:10:05.730 --> 00:10:08.550 align:middle line:84% So things will grow with lambda, which is the security parameter. 00:10:08.550 --> 00:10:11.270 align:middle line:84% What the security parameter is depends how paranoid 00:10:11.270 --> 00:10:12.180 align:middle line:90% we are in the world. 00:10:12.180 --> 00:10:14.790 align:middle line:84% You can think about it as 256 bits. 00:10:14.790 --> 00:10:17.000 align:middle line:84% Sometimes, it's more, depending on also 00:10:17.000 --> 00:10:18.180 align:middle line:90% which cryptosystems you use. 00:10:18.180 --> 00:10:20.990 align:middle line:84% But that's a good-- it's independent of the input. 00:10:20.990 --> 00:10:22.950 align:middle line:84% You want as succinct as you can get. 00:10:22.950 --> 00:10:24.740 align:middle line:84% And if you want to use cryptography, 00:10:24.740 --> 00:10:26.990 align:middle line:90% it's like security parameter. 00:10:26.990 --> 00:10:29.480 align:middle line:84% Now, the input-- it should-- in some sense, 00:10:29.480 --> 00:10:31.110 align:middle line:84% it should not depend on the input. 00:10:31.110 --> 00:10:33.710 align:middle line:84% But of course, the input is not going to be more than 2 00:10:33.710 --> 00:10:36.560 align:middle line:84% to the lambda because you think of lambda 00:10:36.560 --> 00:10:41.120 align:middle line:84% is such that 2 to the lambda is more than the number 00:10:41.120 --> 00:10:42.780 align:middle line:90% of molecules in the universe. 00:10:42.780 --> 00:10:45.510 align:middle line:84% So nothing is that big in our world. 00:10:45.510 --> 00:10:46.820 align:middle line:90% So you think of the-- 00:10:46.820 --> 00:10:48.510 align:middle line:90% x can be bigger. 00:10:48.510 --> 00:10:50.420 align:middle line:84% Actually, the input can also be small. 00:10:50.420 --> 00:10:52.712 align:middle line:84% But then it's-- sometimes, you don't need cryptography. 00:10:52.712 --> 00:10:54.890 align:middle line:84% It's so tiny, it's like cryptography is useless. 00:10:54.890 --> 00:10:58.100 align:middle line:90% You can just give the witness. 00:10:58.100 --> 00:11:00.950 align:middle line:84% So usually, we think in our head of the input 00:11:00.950 --> 00:11:02.700 align:middle line:84% as being-- can be much bigger than lambda. 00:11:02.700 --> 00:11:04.220 align:middle line:84% It can be poly lambda and maybe even 00:11:04.220 --> 00:11:08.180 align:middle line:90% be lambda to the log lambda. 00:11:08.180 --> 00:11:10.100 align:middle line:84% But it's not as big as 2 to the lambda. 00:11:10.100 --> 00:11:11.840 align:middle line:90% That's-- doesn't exist. 00:11:11.840 --> 00:11:17.330 align:middle line:84% But it can be anything that's real-world number, in the sense. 00:11:17.330 --> 00:11:21.820 align:middle line:84% And so that's what we should think of. 00:11:21.820 --> 00:11:25.350 align:middle line:90% 00:11:25.350 --> 00:11:27.380 align:middle line:84% AUDIENCE: So when we do something like this, 00:11:27.380 --> 00:11:31.190 align:middle line:84% we're trying to reduce the amount of-- or the size 00:11:31.190 --> 00:11:34.910 align:middle line:84% of the proof from still a reasonable polynomial size 00:11:34.910 --> 00:11:37.342 align:middle line:84% thing, but just to a 256 [INAUDIBLE]? 00:11:37.342 --> 00:11:38.300 align:middle line:90% YAEL T. KALAI: Exactly. 00:11:38.300 --> 00:11:39.360 align:middle line:90% Exactly. 00:11:39.360 --> 00:11:43.040 align:middle line:84% So you can think of it-- you're trying to-- when you do-- 00:11:43.040 --> 00:11:45.420 align:middle line:84% and let me just repeat it also for the mic. 00:11:45.420 --> 00:11:49.350 align:middle line:84% When you're trying-- when you do this interactive argument, 00:11:49.350 --> 00:11:53.050 align:middle line:84% you think of-- you take an x that's still real-world. 00:11:53.050 --> 00:11:54.760 align:middle line:84% You can think of it polynomial lambda. 00:11:54.760 --> 00:11:55.567 align:middle line:90% But it can be more. 00:11:55.567 --> 00:11:57.150 align:middle line:84% But as long as it's a real-world thing 00:11:57.150 --> 00:12:00.150 align:middle line:84% and you reduce it to 256 bits, that's 00:12:00.150 --> 00:12:04.630 align:middle line:84% the practical idea you should think of. 00:12:04.630 --> 00:12:06.600 align:middle line:84% And the more theoretical idea is to say, 00:12:06.600 --> 00:12:08.490 align:middle line:84% you can take any input x, but not more than 2 00:12:08.490 --> 00:12:10.440 align:middle line:84% to the lambda because that's [RASPBERRY]. 00:12:10.440 --> 00:12:12.660 align:middle line:84% But something-- anything less, and we 00:12:12.660 --> 00:12:16.680 align:middle line:90% make it as small as poly lambda. 00:12:16.680 --> 00:12:17.410 align:middle line:90% Great. 00:12:17.410 --> 00:12:19.530 align:middle line:90% Any other questions? 00:12:19.530 --> 00:12:20.370 align:middle line:90% Yeah? 00:12:20.370 --> 00:12:22.420 align:middle line:84% AUDIENCE: And to verify that rho is the opening-- 00:12:22.420 --> 00:12:23.758 align:middle line:90% is that what it is? 00:12:23.758 --> 00:12:24.550 align:middle line:90% YAEL T. KALAI: Rho? 00:12:24.550 --> 00:12:25.960 align:middle line:90% Yes, yes, yes. 00:12:25.960 --> 00:12:27.090 align:middle line:90% Sorry, yes. 00:12:27.090 --> 00:12:28.150 align:middle line:90% I'll go to it now. 00:12:28.150 --> 00:12:31.100 align:middle line:90% 00:12:31.100 --> 00:12:31.600 align:middle line:90% Good. 00:12:31.600 --> 00:12:33.430 align:middle line:90% So let me just finish-- 00:12:33.430 --> 00:12:36.720 align:middle line:84% wrap up what we-- where we left last time, which is the Merkle 00:12:36.720 --> 00:12:37.240 align:middle line:90% hash. 00:12:37.240 --> 00:12:40.000 align:middle line:84% So we use Merkle hash in the Kilian-Micali protocol. 00:12:40.000 --> 00:12:41.888 align:middle line:84% Actually, we don't need to really remember 00:12:41.888 --> 00:12:43.430 align:middle line:84% the Kilian-Micali protocol for today. 00:12:43.430 --> 00:12:45.410 align:middle line:84% We're not going to actually really use it. 00:12:45.410 --> 00:12:47.583 align:middle line:84% But let me still finish the Merkle hash 00:12:47.583 --> 00:12:49.250 align:middle line:84% because it's a very important primitive. 00:12:49.250 --> 00:12:51.320 align:middle line:84% It's used everywhere in cryptography. 00:12:51.320 --> 00:12:53.332 align:middle line:90% So it's very important to know. 00:12:53.332 --> 00:12:55.070 align:middle line:90% So what is the Merkle hash? 00:12:55.070 --> 00:12:58.840 align:middle line:84% It takes any hash function, not local opening, just 00:12:58.840 --> 00:13:01.090 align:middle line:84% a regular hash function that generates a hash key 00:13:01.090 --> 00:13:02.440 align:middle line:90% and has an eval. 00:13:02.440 --> 00:13:04.300 align:middle line:84% Algorithm evaluates, just generates 00:13:04.300 --> 00:13:09.398 align:middle line:84% hash value, such that it takes two lambda bits to lambda bits. 00:13:09.398 --> 00:13:10.690 align:middle line:90% Actually, you can make it more. 00:13:10.690 --> 00:13:13.420 align:middle line:84% It can be even 1 plus epsilon lambda bits to lambda. 00:13:13.420 --> 00:13:14.360 align:middle line:90% You can play with it. 00:13:14.360 --> 00:13:17.740 align:middle line:84% But let's say two lambda, two lambda bits. 00:13:17.740 --> 00:13:22.760 align:middle line:84% And we construct from it a hash function with local opening. 00:13:22.760 --> 00:13:25.150 align:middle line:84% So let me tell you exactly what this hash function 00:13:25.150 --> 00:13:27.520 align:middle line:84% with local opening-- what it looks like. 00:13:27.520 --> 00:13:31.250 align:middle line:84% So the gen, the hash key, is exactly the same as before. 00:13:31.250 --> 00:13:34.750 align:middle line:84% We take the same hash key as our underlying-- so first, 00:13:34.750 --> 00:13:36.200 align:middle line:90% we started with a hash. 00:13:36.200 --> 00:13:39.100 align:middle line:84% We started with this hash family. 00:13:39.100 --> 00:13:39.757 align:middle line:90% What is it? 00:13:39.757 --> 00:13:41.590 align:middle line:84% Last time, we saw we can take-- for example, 00:13:41.590 --> 00:13:43.400 align:middle line:84% I gave an example with the discrete log. 00:13:43.400 --> 00:13:45.900 align:middle line:84% But you can even-- if you don't remember, it doesn't matter. 00:13:45.900 --> 00:13:48.810 align:middle line:84% Think of it-- someone gave you a hash family 00:13:48.810 --> 00:13:52.030 align:middle line:90% with this domain and range. 00:13:52.030 --> 00:13:54.520 align:middle line:84% Now I'm going to do a domain extension. 00:13:54.520 --> 00:13:56.190 align:middle line:84% I'm going to make the domain much bigger 00:13:56.190 --> 00:13:58.150 align:middle line:90% and get local opening. 00:13:58.150 --> 00:13:59.380 align:middle line:90% How do I do it? 00:13:59.380 --> 00:14:02.580 align:middle line:84% So this is the Merkle hash construction. 00:14:02.580 --> 00:14:05.850 align:middle line:84% The idea is-- so the gen is, as I said-- just 00:14:05.850 --> 00:14:09.060 align:middle line:84% generate the same hash key as the original gen, no change 00:14:09.060 --> 00:14:10.420 align:middle line:90% to the gen algorithm. 00:14:10.420 --> 00:14:12.580 align:middle line:84% The eval algorithm, on the other hand, of course, 00:14:12.580 --> 00:14:15.540 align:middle line:84% changes because the domain is much bigger. 00:14:15.540 --> 00:14:18.730 align:middle line:84% It takes strings of size, at most, 2 to the lambda bits. 00:14:18.730 --> 00:14:20.200 align:middle line:90% And what does it do? 00:14:20.200 --> 00:14:22.150 align:middle line:84% So what it does is the following. 00:14:22.150 --> 00:14:23.560 align:middle line:90% It takes as input x. 00:14:23.560 --> 00:14:27.180 align:middle line:84% Let's suppose, for simplicity, that x is exactly 00:14:27.180 --> 00:14:30.075 align:middle line:90% 2 to the l times lambda bits. 00:14:30.075 --> 00:14:34.244 align:middle line:90% 00:14:34.244 --> 00:14:35.800 align:middle line:90% You don't have to assume this. 00:14:35.800 --> 00:14:37.240 align:middle line:90% This is just easy to assume. 00:14:37.240 --> 00:14:38.880 align:middle line:84% And you can always get it with padding. 00:14:38.880 --> 00:14:41.180 align:middle line:84% Take any input and pad it so it will be of this form. 00:14:41.180 --> 00:14:42.980 align:middle line:90% And now hash it. 00:14:42.980 --> 00:14:45.550 align:middle line:84% I'll say a word if it's not of this form. 00:14:45.550 --> 00:14:48.470 align:middle line:84% But if it is of this form, what do you do? 00:14:48.470 --> 00:14:50.770 align:middle line:90% You take your input x. 00:14:50.770 --> 00:14:53.870 align:middle line:84% Just partition it to blocks, each of length lambda. 00:14:53.870 --> 00:14:56.530 align:middle line:90% So you have 2 to the l blocks. 00:14:56.530 --> 00:15:00.670 align:middle line:84% You have an input x of length 2 to the l times lambda. 00:15:00.670 --> 00:15:04.240 align:middle line:84% You partition it to chunks, each of length lambda. 00:15:04.240 --> 00:15:05.960 align:middle line:90% So you have 2 to the l chunks. 00:15:05.960 --> 00:15:10.360 align:middle line:84% Let's call the chunks x1, x2, x3, x4, and so on, up to x 2 00:15:10.360 --> 00:15:12.580 align:middle line:90% to the lambda, each of them-- 00:15:12.580 --> 00:15:17.650 align:middle line:84% up to x2 to the l-- sorry, each of them of length lambda. 00:15:17.650 --> 00:15:19.120 align:middle line:90% And now what you do-- 00:15:19.120 --> 00:15:20.510 align:middle line:90% you take two blocks-- 00:15:20.510 --> 00:15:21.910 align:middle line:90% this is two lambda bits-- 00:15:21.910 --> 00:15:26.350 align:middle line:84% and hash it using our building block hash 00:15:26.350 --> 00:15:28.190 align:middle line:90% that takes 2 lambda to lambda. 00:15:28.190 --> 00:15:29.720 align:middle line:90% You take the next two lambda. 00:15:29.720 --> 00:15:31.090 align:middle line:90% You hash. 00:15:31.090 --> 00:15:32.360 align:middle line:90% You take these two. 00:15:32.360 --> 00:15:33.400 align:middle line:90% You hash. 00:15:33.400 --> 00:15:36.700 align:middle line:84% So in other words, you take that 2 to the l 00:15:36.700 --> 00:15:41.900 align:middle line:84% blocks to 2 to the l minus 1 blocks. 00:15:41.900 --> 00:15:42.790 align:middle line:90% Every pair, you hash. 00:15:42.790 --> 00:15:43.580 align:middle line:90% Every pair, you hash. 00:15:43.580 --> 00:15:44.230 align:middle line:90% Every pair, you hash. 00:15:44.230 --> 00:15:45.105 align:middle line:90% Every pair, you hash. 00:15:45.105 --> 00:15:49.100 align:middle line:84% You got 2 to the l minus 1 blocks. 00:15:49.100 --> 00:15:50.360 align:middle line:90% Then you take these blocks. 00:15:50.360 --> 00:15:51.875 align:middle line:90% And again, every pair, you hash. 00:15:51.875 --> 00:15:52.750 align:middle line:90% Every pair, you hash. 00:15:52.750 --> 00:15:55.630 align:middle line:84% Every pair, you hash 2 to the l minus 2 blocks, 00:15:55.630 --> 00:15:59.470 align:middle line:84% and so on and so forth until you arrive to one block at the end. 00:15:59.470 --> 00:16:00.770 align:middle line:90% What do you output? 00:16:00.770 --> 00:16:02.860 align:middle line:90% You output the top, the final-- 00:16:02.860 --> 00:16:05.320 align:middle line:84% it's going to be somewhere here-- 00:16:05.320 --> 00:16:09.130 align:middle line:84% block, which is often called a root. 00:16:09.130 --> 00:16:10.480 align:middle line:90% You output the root. 00:16:10.480 --> 00:16:13.350 align:middle line:84% And you output the depth of the tree. 00:16:13.350 --> 00:16:14.600 align:middle line:90% That's the output of the hash. 00:16:14.600 --> 00:16:16.100 align:middle line:90% So the output is the root. 00:16:16.100 --> 00:16:19.480 align:middle line:84% The hash value here-- it's lambda bits 00:16:19.480 --> 00:16:22.030 align:middle line:84% and d, which you also think of it as being lambda bits. 00:16:22.030 --> 00:16:25.030 align:middle line:84% Even if it's less, just encode it using lambda bits. 00:16:25.030 --> 00:16:27.550 align:middle line:84% So if you're mad now at me because I promised you 00:16:27.550 --> 00:16:31.210 align:middle line:84% lambda bits and you see here two lambda bits, apply this 00:16:31.210 --> 00:16:34.660 align:middle line:84% hash one more time, and you'll get your lambda bits. 00:16:34.660 --> 00:16:37.200 align:middle line:84% But having two lambda bits is also fine. 00:16:37.200 --> 00:16:38.152 align:middle line:90% Yeah? 00:16:38.152 --> 00:16:41.720 align:middle line:84% AUDIENCE: Why are we bounding the input length to 2 00:16:41.720 --> 00:16:43.680 align:middle line:84% to the lambda instead of just arbitrary? 00:16:43.680 --> 00:16:43.833 align:middle line:90% YAEL T. KALAI: Good. 00:16:43.833 --> 00:16:43.871 align:middle line:90% Good. 00:16:43.871 --> 00:16:43.910 align:middle line:90% Good. 00:16:43.910 --> 00:16:44.091 align:middle line:90% Good. 00:16:44.091 --> 00:16:44.273 align:middle line:90% Good. 00:16:44.273 --> 00:16:44.922 align:middle line:90% Great. 00:16:44.922 --> 00:16:46.380 align:middle line:84% Because last time-- great question. 00:16:46.380 --> 00:16:47.755 align:middle line:84% So last time, when I mentioned, I 00:16:47.755 --> 00:16:50.130 align:middle line:84% said, just take star here, anything. 00:16:50.130 --> 00:16:53.970 align:middle line:84% So why am I bounding it out to 2 the lambda? 00:16:53.970 --> 00:16:59.190 align:middle line:84% So this construction bounds 2 to the lambda because as you see, 00:16:59.190 --> 00:17:01.170 align:middle line:90% I take every lambda I can take. 00:17:01.170 --> 00:17:02.160 align:middle line:90% That's all it gives me. 00:17:02.160 --> 00:17:03.330 align:middle line:90% So that's all I get. 00:17:03.330 --> 00:17:05.280 align:middle line:84% Now you can say, wait, what if I want more? 00:17:05.280 --> 00:17:06.599 align:middle line:90% Maybe I want 2 to the lambda. 00:17:06.599 --> 00:17:08.790 align:middle line:84% You can actually get more than 2 to the lambda. 00:17:08.790 --> 00:17:10.920 align:middle line:84% For example, you can bootstrap this. 00:17:10.920 --> 00:17:14.240 align:middle line:84% So now you can take 2 to the lambda to lambda. 00:17:14.240 --> 00:17:18.812 align:middle line:84% You can create a Merkle hash of this Merkle hash. 00:17:18.812 --> 00:17:21.410 align:middle line:90% But actually, you never-- 00:17:21.410 --> 00:17:23.420 align:middle line:84% it doesn't come up because you never need to. 00:17:23.420 --> 00:17:25.145 align:middle line:90% 2 to the lambda is-- 00:17:25.145 --> 00:17:26.900 align:middle line:84% think nothing is more than 2 to the-- we 00:17:26.900 --> 00:17:28.560 align:middle line:84% choose lambda so that in our world, 00:17:28.560 --> 00:17:30.630 align:middle line:84% nothing is more than size 2 to the lambda. 00:17:30.630 --> 00:17:33.161 align:middle line:90% But you can think of-- 00:17:33.161 --> 00:17:36.690 align:middle line:84% you can get-- if you-- just as a mathematical curiosity, 00:17:36.690 --> 00:17:40.040 align:middle line:90% you can apply it. 00:17:40.040 --> 00:17:42.120 align:middle line:84% So once you have from 2 to the lambda to lambda, 00:17:42.120 --> 00:17:46.010 align:middle line:84% you can chop your things to 2 to the lambda 00:17:46.010 --> 00:17:48.980 align:middle line:84% and do this-- use this as a building 00:17:48.980 --> 00:17:50.340 align:middle line:90% block to a bigger Merkle hash. 00:17:50.340 --> 00:17:53.540 align:middle line:90% So you can amplify it. 00:17:53.540 --> 00:17:57.510 align:middle line:84% But we're not-- for us, 2 to the lambda to lambda is good enough. 00:17:57.510 --> 00:17:58.010 align:middle line:90% Great. 00:17:58.010 --> 00:18:00.410 align:middle line:90% Great question. 00:18:00.410 --> 00:18:03.300 align:middle line:90% Any other question? 00:18:03.300 --> 00:18:04.405 align:middle line:90% Yes? 00:18:04.405 --> 00:18:05.780 align:middle line:84% AUDIENCE: Why does the depth need 00:18:05.780 --> 00:18:07.130 align:middle line:90% to be included in the output? 00:18:07.130 --> 00:18:09.447 align:middle line:84% Should it not just be a function of the length of x? 00:18:09.447 --> 00:18:10.280 align:middle line:90% YAEL T. KALAI: Good. 00:18:10.280 --> 00:18:11.520 align:middle line:90% Great, great question. 00:18:11.520 --> 00:18:14.400 align:middle line:90% Why do I insist on including d? 00:18:14.400 --> 00:18:15.780 align:middle line:90% Is it not a function of x? 00:18:15.780 --> 00:18:16.770 align:middle line:90% It is a function of x. 00:18:16.770 --> 00:18:18.978 align:middle line:84% It's a deterministic function of the length, not even 00:18:18.978 --> 00:18:20.280 align:middle line:90% of x-- of the length of x. 00:18:20.280 --> 00:18:20.960 align:middle line:90% Yes. 00:18:20.960 --> 00:18:23.460 align:middle line:90% However, nobody knows what x is. 00:18:23.460 --> 00:18:26.970 align:middle line:84% So at the end of the day, I want collision resistance. 00:18:26.970 --> 00:18:29.510 align:middle line:84% And so the property we want from this hash 00:18:29.510 --> 00:18:31.080 align:middle line:84% is that it's collision resistance. 00:18:31.080 --> 00:18:32.700 align:middle line:84% What does collision-resistant means? 00:18:32.700 --> 00:18:37.430 align:middle line:84% It means that you cannot output a hash value with two different 00:18:37.430 --> 00:18:38.720 align:middle line:90% openings. 00:18:38.720 --> 00:18:41.990 align:middle line:84% Now, when you open a hash value, nobody knows what the x is. 00:18:41.990 --> 00:18:44.220 align:middle line:84% Actually, you may not even know-- 00:18:44.220 --> 00:18:48.260 align:middle line:84% well, if you-- when you open, you know. 00:18:48.260 --> 00:18:53.180 align:middle line:84% But when you give someone a hash value, there's no x inherently-- 00:18:53.180 --> 00:18:54.330 align:middle line:90% a part of it. 00:18:54.330 --> 00:18:56.937 align:middle line:90% If you don't include the depth-- 00:18:56.937 --> 00:18:59.520 align:middle line:84% actually, if there's an attack, it's not collision resistance. 00:18:59.520 --> 00:19:00.210 align:middle line:90% It's really not. 00:19:00.210 --> 00:19:02.670 align:middle line:84% It's not just a-- why is it not collision resistance? 00:19:02.670 --> 00:19:06.510 align:middle line:84% For example, just as an attack, let's say I publish this root, 00:19:06.510 --> 00:19:07.430 align:middle line:90% even-- 00:19:07.430 --> 00:19:08.580 align:middle line:90% this is my root. 00:19:08.580 --> 00:19:09.750 align:middle line:90% This is my input. 00:19:09.750 --> 00:19:12.020 align:middle line:90% My input is x1, x2, x3, x4. 00:19:12.020 --> 00:19:13.740 align:middle line:90% And the output is root. 00:19:13.740 --> 00:19:16.560 align:middle line:84% Now let me break the collision resistance. 00:19:16.560 --> 00:19:18.210 align:middle line:84% I'll give you two different openings. 00:19:18.210 --> 00:19:20.850 align:middle line:90% One is x1, x2, x3, x4. 00:19:20.850 --> 00:19:21.630 align:middle line:90% You do the hash? 00:19:21.630 --> 00:19:22.650 align:middle line:90% You see you're happy. 00:19:22.650 --> 00:19:23.960 align:middle line:90% It's a good opening. 00:19:23.960 --> 00:19:27.920 align:middle line:84% Now let me give you another opening, just this and this. 00:19:27.920 --> 00:19:29.630 align:middle line:90% That's also a good opening. 00:19:29.630 --> 00:19:32.330 align:middle line:84% So I open it in two different ways. 00:19:32.330 --> 00:19:33.480 align:middle line:90% That's not okay. 00:19:33.480 --> 00:19:34.880 align:middle line:90% That's a collision. 00:19:34.880 --> 00:19:38.390 align:middle line:84% If you include d, however, then-- 00:19:38.390 --> 00:19:40.570 align:middle line:84% so that's exactly what will allow me 00:19:40.570 --> 00:19:41.820 align:middle line:90% to argue collision resistance. 00:19:41.820 --> 00:19:43.580 align:middle line:90% It's this d. 00:19:43.580 --> 00:19:44.220 align:middle line:90% Great question. 00:19:44.220 --> 00:19:46.760 align:middle line:90% Thank you. 00:19:46.760 --> 00:19:49.580 align:middle line:90% So this is the construction. 00:19:49.580 --> 00:19:51.630 align:middle line:90% Questions? 00:19:51.630 --> 00:19:52.130 align:middle line:90% Let's see. 00:19:52.130 --> 00:19:52.950 align:middle line:90% How do we open? 00:19:52.950 --> 00:19:55.800 align:middle line:84% So now this is just so far great. 00:19:55.800 --> 00:19:58.023 align:middle line:84% We managed to go from 2 to the lambda to lambda. 00:19:58.023 --> 00:19:59.690 align:middle line:84% I didn't argue collision resistance yet. 00:19:59.690 --> 00:20:02.420 align:middle line:84% But at least we did domain extension. 00:20:02.420 --> 00:20:04.020 align:middle line:90% So we extended the domain. 00:20:04.020 --> 00:20:07.130 align:middle line:84% But I also want-- especially, I need it for the Kilian-Micali 00:20:07.130 --> 00:20:09.960 align:middle line:84% protocol and for many, many other uses in cryptography-- 00:20:09.960 --> 00:20:13.020 align:middle line:84% I want to be able to do local opening. 00:20:13.020 --> 00:20:15.860 align:middle line:84% So remember, what does local opening mean? 00:20:15.860 --> 00:20:18.230 align:middle line:90% I may not want to open when-- 00:20:18.230 --> 00:20:22.160 align:middle line:84% with-- I may not want to give you my entire input. 00:20:22.160 --> 00:20:23.660 align:middle line:90% I may just want to give you-- 00:20:23.660 --> 00:20:26.750 align:middle line:84% to convince you that this hash value 00:20:26.750 --> 00:20:31.930 align:middle line:84% in some location i of the input-- 00:20:31.930 --> 00:20:34.045 align:middle line:84% the value is a big B. But I don't 00:20:34.045 --> 00:20:36.420 align:middle line:84% want to give you the entire-- because the entire input is 00:20:36.420 --> 00:20:36.920 align:middle line:90% gigantic. 00:20:36.920 --> 00:20:38.850 align:middle line:90% You can't even hold it. 00:20:38.850 --> 00:20:40.630 align:middle line:90% So I want a succinct opening. 00:20:40.630 --> 00:20:43.870 align:middle line:84% I want to convince you in a very succinct way 00:20:43.870 --> 00:20:48.510 align:middle line:84% that what's sitting here in this bit is 0 or is 1. 00:20:48.510 --> 00:20:50.110 align:middle line:90% So how do I do it? 00:20:50.110 --> 00:20:55.900 align:middle line:84% So this construction is actually really nice. 00:20:55.900 --> 00:20:58.300 align:middle line:84% It gives you a local opening in a very nice way. 00:20:58.300 --> 00:20:59.680 align:middle line:90% So what's the local opening? 00:20:59.680 --> 00:21:01.950 align:middle line:90% Suppose I want to open this-- 00:21:01.950 --> 00:21:03.690 align:middle line:90% the bit here sitting here. 00:21:03.690 --> 00:21:05.190 align:middle line:90% What I'm going to do-- 00:21:05.190 --> 00:21:07.840 align:middle line:84% I'm going to actually give you this entire block. 00:21:07.840 --> 00:21:08.800 align:middle line:90% It's only lambda bits. 00:21:08.800 --> 00:21:10.493 align:middle line:90% So it's not that big. 00:21:10.493 --> 00:21:11.410 align:middle line:90% I give you this block. 00:21:11.410 --> 00:21:12.520 align:middle line:90% What do you do with it? 00:21:12.520 --> 00:21:16.450 align:middle line:84% So let me help you-- convince you that this block is, indeed, 00:21:16.450 --> 00:21:18.070 align:middle line:90% the block related to the root. 00:21:18.070 --> 00:21:23.200 align:middle line:84% Namely, it's the block that, indeed, sits here next to-- 00:21:23.200 --> 00:21:25.440 align:middle line:90% how do I convince you? 00:21:25.440 --> 00:21:27.280 align:middle line:90% I give you the sibling. 00:21:27.280 --> 00:21:29.650 align:middle line:90% So this block has a parent. 00:21:29.650 --> 00:21:32.790 align:middle line:84% I give you the sibling and the parent. 00:21:32.790 --> 00:21:34.810 align:middle line:90% This parent has a parent. 00:21:34.810 --> 00:21:38.850 align:middle line:84% I give you the sibling and the parent, and so on and so forth, 00:21:38.850 --> 00:21:40.380 align:middle line:90% until you get to the root. 00:21:40.380 --> 00:21:42.340 align:middle line:90% I give you all these blocks. 00:21:42.340 --> 00:21:47.320 align:middle line:84% So in each layer, I open two blocks, 00:21:47.320 --> 00:21:48.910 align:middle line:90% which are the two siblings. 00:21:48.910 --> 00:21:50.128 align:middle line:90% So I open two siblings. 00:21:50.128 --> 00:21:50.670 align:middle line:90% You get this. 00:21:50.670 --> 00:21:51.760 align:middle line:90% I open the two siblings. 00:21:51.760 --> 00:21:52.302 align:middle line:90% You get this. 00:21:52.302 --> 00:21:53.830 align:middle line:84% I open the two siblings, and so on. 00:21:53.830 --> 00:21:54.720 align:middle line:90% Yes? 00:21:54.720 --> 00:21:56.480 align:middle line:84% AUDIENCE: This is a constant factor. 00:21:56.480 --> 00:21:57.730 align:middle line:90% So I don't know if it matters. 00:21:57.730 --> 00:21:59.980 align:middle line:84% But do you strictly need to return the ancestors? 00:21:59.980 --> 00:22:01.740 align:middle line:84% You can only return the siblings, right? 00:22:01.740 --> 00:22:01.866 align:middle line:90% YAEL T. KALAI: Good. 00:22:01.866 --> 00:22:01.929 align:middle line:90% Good. 00:22:01.929 --> 00:22:01.995 align:middle line:90% Good. 00:22:01.995 --> 00:22:02.250 align:middle line:90% Right. 00:22:02.250 --> 00:22:02.585 align:middle line:90% Right. 00:22:02.585 --> 00:22:02.920 align:middle line:90% Right. 00:22:02.920 --> 00:22:03.795 align:middle line:90% You're totally right. 00:22:03.795 --> 00:22:05.910 align:middle line:84% You're saying, well, if you really want to be-- 00:22:05.910 --> 00:22:08.118 align:middle line:84% what you're saying, which is completely right thing-- 00:22:08.118 --> 00:22:09.880 align:middle line:84% this is wasteful because actually, 00:22:09.880 --> 00:22:11.680 align:middle line:84% all I need to give you is the sibling. 00:22:11.680 --> 00:22:14.250 align:middle line:90% So why waste communication? 00:22:14.250 --> 00:22:17.840 align:middle line:84% If I want to open this, I'll give you this and this sibling. 00:22:17.840 --> 00:22:19.090 align:middle line:90% I don't need to give you this. 00:22:19.090 --> 00:22:20.533 align:middle line:84% You can compute this on your own. 00:22:20.533 --> 00:22:21.700 align:middle line:90% So compute this on your own. 00:22:21.700 --> 00:22:22.710 align:middle line:90% I'll give you this. 00:22:22.710 --> 00:22:24.250 align:middle line:90% I don't need to give you this. 00:22:24.250 --> 00:22:25.090 align:middle line:90% You have these two. 00:22:25.090 --> 00:22:26.610 align:middle line:90% So compute this on your own. 00:22:26.610 --> 00:22:29.980 align:middle line:84% And then I'll only give you this and then-- and so on. 00:22:29.980 --> 00:22:31.300 align:middle line:90% You're 100% correct. 00:22:31.300 --> 00:22:34.110 align:middle line:84% I actually just need to give you one. 00:22:34.110 --> 00:22:37.170 align:middle line:84% I wrote two because it's just easier to say. 00:22:37.170 --> 00:22:39.420 align:middle line:90% But yes, exactly, one is enough. 00:22:39.420 --> 00:22:42.660 align:middle line:90% And you can compute the-- 00:22:42.660 --> 00:22:45.510 align:middle line:90% fantastic. 00:22:45.510 --> 00:22:47.980 align:middle line:90% So I denote it by-- 00:22:47.980 --> 00:22:50.250 align:middle line:90% so what does the open do? 00:22:50.250 --> 00:22:53.250 align:middle line:84% For each layer, it gives you two blocks 00:22:53.250 --> 00:22:54.910 align:middle line:90% for layer j denoted by zj. 00:22:54.910 --> 00:22:57.630 align:middle line:90% So zj is two blocks. 00:22:57.630 --> 00:22:59.640 align:middle line:84% And the leaves-- it's two blocks. 00:22:59.640 --> 00:23:00.520 align:middle line:90% j equals 0. 00:23:00.520 --> 00:23:02.740 align:middle line:84% It's in the leaf-- layer 1, layer 2, up to layer d. 00:23:02.740 --> 00:23:03.907 align:middle line:90% It's actually just the root. 00:23:03.907 --> 00:23:07.680 align:middle line:84% So you can actually go to d minus 1 if you want. 00:23:07.680 --> 00:23:12.750 align:middle line:84% But I'll just-- in my mind, I want to include the root. 00:23:12.750 --> 00:23:16.450 align:middle line:84% The reason I include both in the root is now when I analyze it, 00:23:16.450 --> 00:23:18.880 align:middle line:84% it's-- notation-wise, it's just very, very easy. 00:23:18.880 --> 00:23:21.780 align:middle line:84% But really, it's enough, like you said, to have the sibling. 00:23:21.780 --> 00:23:24.930 align:middle line:84% And the roots, of course, you don't need to give. 00:23:24.930 --> 00:23:27.440 align:middle line:84% But let's just think, this is how I open. 00:23:27.440 --> 00:23:29.740 align:middle line:90% And now how do I verify? 00:23:29.740 --> 00:23:33.160 align:middle line:84% I just take each two sibling, compute the hash, 00:23:33.160 --> 00:23:37.060 align:middle line:84% and make sure it corresponds to the relevant z's-- 00:23:37.060 --> 00:23:38.690 align:middle line:90% indeed, the parent. 00:23:38.690 --> 00:23:40.880 align:middle line:84% So again, you gave me all these things. 00:23:40.880 --> 00:23:42.440 align:middle line:90% I compute these two. 00:23:42.440 --> 00:23:44.958 align:middle line:84% I check that it's consistent with what you gave you, 00:23:44.958 --> 00:23:46.250 align:middle line:90% or if you didn't give me, fine. 00:23:46.250 --> 00:23:47.690 align:middle line:90% I'll compute it on my own. 00:23:47.690 --> 00:23:48.680 align:middle line:90% I get this. 00:23:48.680 --> 00:23:51.065 align:middle line:90% I'll compute this and give in. 00:23:51.065 --> 00:23:53.440 align:middle line:84% And then I'll check that-- all I need to check at the end 00:23:53.440 --> 00:23:54.648 align:middle line:90% is consistency with the root. 00:23:54.648 --> 00:23:58.255 align:middle line:90% 00:23:58.255 --> 00:24:01.870 align:middle line:90% That's the verification. 00:24:01.870 --> 00:24:05.336 align:middle line:84% Question about the design, the algorithms? 00:24:05.336 --> 00:24:08.440 align:middle line:90% 00:24:08.440 --> 00:24:11.120 align:middle line:84% So this is where we left off, actually, last time. 00:24:11.120 --> 00:24:14.860 align:middle line:84% And what I want to do now is do the collision resistance. 00:24:14.860 --> 00:24:16.720 align:middle line:84% I'm happy that, actually, we got a chance 00:24:16.720 --> 00:24:19.370 align:middle line:84% to do it again because it's a very important primitive. 00:24:19.370 --> 00:24:23.010 align:middle line:84% So it's worth having it ingrained in your mind. 00:24:23.010 --> 00:24:25.810 align:middle line:90% 00:24:25.810 --> 00:24:27.980 align:middle line:84% So why is it collision-resistant? 00:24:27.980 --> 00:24:30.550 align:middle line:90% 00:24:30.550 --> 00:24:32.600 align:middle line:84% So to prove collision resistance, 00:24:32.600 --> 00:24:33.790 align:middle line:90% what do we want to argue? 00:24:33.790 --> 00:24:39.340 align:middle line:84% That an adversary that's given a hash key cannot produce a hash 00:24:39.340 --> 00:24:39.950 align:middle line:90% value-- 00:24:39.950 --> 00:24:41.530 align:middle line:90% namely, root in d-- 00:24:41.530 --> 00:24:44.820 align:middle line:90% with two different openings. 00:24:44.820 --> 00:24:59.020 align:middle line:84% So suppose there exists a poly-size adversary that does 00:24:59.020 --> 00:25:04.180 align:middle line:84% find a collision such that the probability that A-- 00:25:04.180 --> 00:25:05.770 align:middle line:90% he gets a hash key. 00:25:05.770 --> 00:25:13.630 align:middle line:84% Hash key is from gen. And somehow, he manages to output 00:25:13.630 --> 00:25:16.940 align:middle line:84% a hash value, which is root in d. 00:25:16.940 --> 00:25:19.450 align:middle line:90% That's just a hash value. 00:25:19.450 --> 00:25:24.940 align:middle line:90% And he gives me some index i. 00:25:24.940 --> 00:25:27.530 align:middle line:84% He managed to open it in two different way. 00:25:27.530 --> 00:25:32.000 align:middle line:84% He gives me an opening that says i is 0. 00:25:32.000 --> 00:25:37.120 align:middle line:84% And he gives me another opening that says the i-th bit is 1 00:25:37.120 --> 00:25:41.920 align:middle line:84% and such that for both of them, such that for every B, 00:25:41.920 --> 00:25:47.260 align:middle line:84% for both 0 and 1, ver will accept-- 00:25:47.260 --> 00:25:56.140 align:middle line:84% ver and hash key root in d, i, and row B outputs 1. 00:25:56.140 --> 00:26:00.790 align:middle line:84% So suppose I have an algorithm that gives me 00:26:00.790 --> 00:26:04.660 align:middle line:84% a hash value, an index, and a valid openings, both a 00:26:04.660 --> 00:26:06.020 align:middle line:90% 0 and to 1. 00:26:06.020 --> 00:26:09.650 align:middle line:84% Valid-- I mean that the ver will accept both of them. 00:26:09.650 --> 00:26:11.680 align:middle line:90% Oh, sorry-- B. 00:26:11.680 --> 00:26:18.010 align:middle line:84% So ver takes hash key of value, an index i, and a B, big B, 00:26:18.010 --> 00:26:22.760 align:middle line:84% saying whether index i is 0 or 1, and a proof, an opening. 00:26:22.760 --> 00:26:25.970 align:middle line:90% And suppose he accepts both. 00:26:25.970 --> 00:26:28.920 align:middle line:84% Suppose he accepts both with probability at least, 00:26:28.920 --> 00:26:31.350 align:middle line:90% I don't know, epsilon. 00:26:31.350 --> 00:26:34.073 align:middle line:84% So suppose there's this and exists epsilon. 00:26:34.073 --> 00:26:41.885 align:middle line:90% 00:26:41.885 --> 00:26:43.850 align:middle line:84% So suppose there exists epsilon such that 00:26:43.850 --> 00:26:46.190 align:middle line:84% for any lambda, the probability that A 00:26:46.190 --> 00:26:50.210 align:middle line:84% managed to find the collision like this is at least epsilon. 00:26:50.210 --> 00:26:53.030 align:middle line:84% I'm going to argue then you can find 00:26:53.030 --> 00:26:55.850 align:middle line:84% a collision in the underlying h, in the small h, 00:26:55.850 --> 00:26:58.580 align:middle line:90% with probability epsilon. 00:26:58.580 --> 00:27:01.910 align:middle line:84% So if you have an algorithm like this, 00:27:01.910 --> 00:27:18.860 align:middle line:84% then there exists an algorithm poly size such that B-- 00:27:18.860 --> 00:27:22.940 align:middle line:84% such that the probability that B-- 00:27:22.940 --> 00:27:29.240 align:middle line:84% he gets hash key-- the probability that he outputs, 00:27:29.240 --> 00:27:38.240 align:middle line:84% I know x0, x, and x, prime such that the original eval hk, x 00:27:38.240 --> 00:27:46.190 align:middle line:84% equals eval hk, x prime, and x is different 00:27:46.190 --> 00:27:50.900 align:middle line:84% than x prime, is at least epsilon. 00:27:50.900 --> 00:27:53.550 align:middle line:84% But we assume that this is collision resistance. 00:27:53.550 --> 00:27:56.660 align:middle line:84% We started with an underlying hash function 00:27:56.660 --> 00:27:58.230 align:middle line:90% that's collision-resistant. 00:27:58.230 --> 00:28:02.717 align:middle line:84% So the epsilon has to be negligible. 00:28:02.717 --> 00:28:04.050 align:middle line:90% That's what we're going to show. 00:28:04.050 --> 00:28:07.730 align:middle line:84% So we're going to use if an adversary can 00:28:07.730 --> 00:28:13.830 align:middle line:84% find a local opening that collides for the Merkle hash, 00:28:13.830 --> 00:28:16.700 align:middle line:84% we can use them to actually break 00:28:16.700 --> 00:28:20.810 align:middle line:84% the defined collision in the underlying 2 lambda 00:28:20.810 --> 00:28:26.150 align:middle line:84% to lambda hash function in the little hash function. 00:28:26.150 --> 00:28:27.900 align:middle line:90% So how does B work? 00:28:27.900 --> 00:28:28.950 align:middle line:90% What does B do? 00:28:28.950 --> 00:28:30.660 align:middle line:90% B takes a hash key. 00:28:30.660 --> 00:28:34.820 align:middle line:84% He just runs A. So let me-- so we claim that there 00:28:34.820 --> 00:28:36.815 align:middle line:90% exists a B. So let see. 00:28:36.815 --> 00:28:41.370 align:middle line:84% B, an input hash key, what does he do? 00:28:41.370 --> 00:28:54.260 align:middle line:84% Just run A. So get root D, I, row 0, row 1, which is just A 00:28:54.260 --> 00:28:56.840 align:middle line:90% and hash key. 00:28:56.840 --> 00:29:00.420 align:middle line:90% Now, he got row 0 and row 1. 00:29:00.420 --> 00:29:02.130 align:middle line:90% What are row 0, row 1? 00:29:02.130 --> 00:29:07.440 align:middle line:84% Each row is this kind of two pairs of siblings. 00:29:07.440 --> 00:29:09.440 align:middle line:84% I'm going to assume that both exist because it's 00:29:09.440 --> 00:29:10.320 align:middle line:90% just easier for me. 00:29:10.320 --> 00:29:11.700 align:middle line:90% That's why I wrote both of them. 00:29:11.700 --> 00:29:21.000 align:middle line:84% So each opening-- so row 0 is for each level you have Z0, 00:29:21.000 --> 00:29:32.540 align:middle line:90% J from 0 to D. And row 1 is-- 00:29:32.540 --> 00:29:40.130 align:middle line:90% let's call it Z1, J. 00:29:40.130 --> 00:29:41.495 align:middle line:90% Now, what do we know? 00:29:41.495 --> 00:29:50.760 align:middle line:84% In the leaves, so we know that Z0, 0 is different than Z1, 0. 00:29:50.760 --> 00:29:54.660 align:middle line:84% The two leaves are different because, in one leaf-- 00:29:54.660 --> 00:29:57.630 align:middle line:84% suppose verifier accepts both of them. 00:29:57.630 --> 00:30:00.830 align:middle line:84% In the case that these are both accepted, 00:30:00.830 --> 00:30:03.840 align:middle line:84% I'm going to argue that I found collisions. 00:30:03.840 --> 00:30:06.990 align:middle line:84% So now suppose row 0 and row 1 are accepted. 00:30:06.990 --> 00:30:12.800 align:middle line:90% So ver accepts both of them. 00:30:12.800 --> 00:30:16.320 align:middle line:84% Now, if ver accepts both of them-- 00:30:16.320 --> 00:30:19.380 align:middle line:84% so we know that the leaves are different because, 00:30:19.380 --> 00:30:22.590 align:middle line:84% in the leaves, in one case, I have here a 1, 00:30:22.590 --> 00:30:24.630 align:middle line:84% in the other case, I have here a 0. 00:30:24.630 --> 00:30:26.920 align:middle line:90% So they have to be different. 00:30:26.920 --> 00:30:29.070 align:middle line:84% So I know the leaves are different. 00:30:29.070 --> 00:30:38.825 align:middle line:84% I also know that Z0, D equals Z1, D. These are both a root. 00:30:38.825 --> 00:30:40.950 align:middle line:84% Now, of course, I said, we don't need to include it 00:30:40.950 --> 00:30:43.890 align:middle line:84% because-- but I'm just putting here because I want-- 00:30:43.890 --> 00:30:46.260 align:middle line:84% the reason I want to include it is just for clarity 00:30:46.260 --> 00:30:51.420 align:middle line:84% to say, look, we have D layers of information on each opening. 00:30:51.420 --> 00:30:53.730 align:middle line:84% The leaves, they must be different because one 00:30:53.730 --> 00:30:55.290 align:middle line:90% opens to 0, one opens to 1. 00:30:55.290 --> 00:30:57.640 align:middle line:84% The root, the left one must be the same. 00:30:57.640 --> 00:30:58.950 align:middle line:90% It's the root. 00:30:58.950 --> 00:31:03.480 align:middle line:84% It means that there must be some kind of two adjacent layers 00:31:03.480 --> 00:31:04.920 align:middle line:90% on which one of-- 00:31:04.920 --> 00:31:08.380 align:middle line:84% below they disagree and above they agree. 00:31:08.380 --> 00:31:10.710 align:middle line:84% We know here they disagree, here they agree. 00:31:10.710 --> 00:31:11.308 align:middle line:90% They disagree. 00:31:11.308 --> 00:31:12.850 align:middle line:84% Do they disagree here, disagree here? 00:31:12.850 --> 00:31:14.392 align:middle line:84% At some point they're going to agree. 00:31:14.392 --> 00:31:23.190 align:middle line:84% So we say there must be a layer J such that Zj0 is 00:31:23.190 --> 00:31:35.130 align:middle line:84% different than Zj1, But Zj plus 1, 0 is equal to Zj plus 1, 1. 00:31:35.130 --> 00:31:35.970 align:middle line:90% Yeah? 00:31:35.970 --> 00:31:37.750 align:middle line:90% OK, they disagree here. 00:31:37.750 --> 00:31:39.010 align:middle line:90% How about one layer above? 00:31:39.010 --> 00:31:39.775 align:middle line:90% Do they agree? 00:31:39.775 --> 00:31:40.650 align:middle line:90% If they agree, great. 00:31:40.650 --> 00:31:42.400 align:middle line:84% Then that's going to be our j plus 1. 00:31:42.400 --> 00:31:43.150 align:middle line:90% They disagree? 00:31:43.150 --> 00:31:45.267 align:middle line:84% Let's go up until, at some point, 00:31:45.267 --> 00:31:47.350 align:middle line:84% they'll agree because, Hamiltonian, do they agree. 00:31:47.350 --> 00:31:47.850 align:middle line:90% Yeah. 00:31:47.850 --> 00:31:51.120 align:middle line:84% AUDIENCE: So just for the video, should it be 0 j [INAUDIBLE] 00:31:51.120 --> 00:31:53.735 align:middle line:90% and 0 j plus 1? 00:31:53.735 --> 00:31:55.360 align:middle line:84% YAEL T. KALAI: Oh, thank you very much. 00:31:55.360 --> 00:31:57.220 align:middle line:90% Thank you. 00:31:57.220 --> 00:31:57.720 align:middle line:90% Great. 00:31:57.720 --> 00:31:58.150 align:middle line:90% Thank you. 00:31:58.150 --> 00:32:00.525 align:middle line:84% Yeah, it's not just for the video, it's also for you guys 00:32:00.525 --> 00:32:04.990 align:middle line:84% so I won't confuse you more than that. 00:32:04.990 --> 00:32:06.990 align:middle line:90% Thank you. 00:32:06.990 --> 00:32:10.720 align:middle line:90% 1, j, 1, j plus 1. 00:32:10.720 --> 00:32:12.480 align:middle line:90% Thank you. 00:32:12.480 --> 00:32:14.550 align:middle line:90% OK, yes. 00:32:14.550 --> 00:32:16.620 align:middle line:90% Is it-- 00:32:16.620 --> 00:32:18.330 align:middle line:90% AUDIENCE: Is that [INAUDIBLE]? 00:32:18.330 --> 00:32:20.220 align:middle line:90% Because j plus 1 is-- 00:32:20.220 --> 00:32:21.480 align:middle line:90% oh. 00:32:21.480 --> 00:32:22.680 align:middle line:90% You missed j plus 1. 00:32:22.680 --> 00:32:23.370 align:middle line:90% YAEL T. KALAI: Did I miss-- 00:32:23.370 --> 00:32:24.620 align:middle line:90% AUDIENCE: You missed j plus 1. 00:32:24.620 --> 00:32:25.680 align:middle line:90% AUDIENCE: On the bottom. 00:32:25.680 --> 00:32:27.190 align:middle line:90% YAEL T. KALAI: Yes. 00:32:27.190 --> 00:32:28.215 align:middle line:90% AUDIENCE: You need a 0. 00:32:28.215 --> 00:32:29.680 align:middle line:90% YAEL T. KALAI: Oh my God. 00:32:29.680 --> 00:32:31.140 align:middle line:90% OK. 00:32:31.140 --> 00:32:33.035 align:middle line:90% No, the 0, 1. 00:32:33.035 --> 00:32:34.446 align:middle line:90% Ah! 00:32:34.446 --> 00:32:37.350 align:middle line:90% OK, did I get it right? 00:32:37.350 --> 00:32:38.190 align:middle line:90% Yes. 00:32:38.190 --> 00:32:42.970 align:middle line:84% OK, so there's a layer j such that, in layer j 00:32:42.970 --> 00:32:45.690 align:middle line:84% they disagree, in layer j plus 1 they agree. 00:32:45.690 --> 00:32:46.980 align:middle line:90% That's it. 00:32:46.980 --> 00:32:48.180 align:middle line:90% This is a collision. 00:32:48.180 --> 00:32:49.060 align:middle line:90% Why? 00:32:49.060 --> 00:32:51.270 align:middle line:90% What is layer j plus 1? 00:32:51.270 --> 00:32:55.950 align:middle line:84% One of them is the father, is the parent. 00:32:55.950 --> 00:33:00.840 align:middle line:84% So we have two that they disagree. 00:33:00.840 --> 00:33:04.020 align:middle line:90% But both of these they agree on. 00:33:04.020 --> 00:33:06.060 align:middle line:84% In particular, they agree on this. 00:33:06.060 --> 00:33:08.320 align:middle line:84% So then, so we found a collision. 00:33:08.320 --> 00:33:21.520 align:middle line:84% This must mean that the hash eval hash key of Z0j 00:33:21.520 --> 00:33:27.850 align:middle line:84% is equal to eval hash key of Z1j. 00:33:27.850 --> 00:33:34.990 align:middle line:84% Because this value is one of this, and one of this 00:33:34.990 --> 00:33:38.352 align:middle line:84% depending if it's the left or the right depending on the tree, 00:33:38.352 --> 00:33:39.620 align:middle line:90% and they're both equal. 00:33:39.620 --> 00:33:40.340 align:middle line:90% So done. 00:33:40.340 --> 00:33:49.130 align:middle line:84% I found a collision with the same exact probability. 00:33:49.130 --> 00:33:52.030 align:middle line:90% So it's-- 00:33:52.030 --> 00:33:53.500 align:middle line:90% Now, as I said, this-- 00:33:53.500 --> 00:33:56.740 align:middle line:84% I wrote here, suppose if this poly lambda, 00:33:56.740 --> 00:33:59.950 align:middle line:84% I could have-- if we assumed that the underlying hash 00:33:59.950 --> 00:34:03.940 align:middle line:84% function is t secure, namely you can't find collisions 00:34:03.940 --> 00:34:06.770 align:middle line:84% even if you run time poly t of lambda, 00:34:06.770 --> 00:34:11.710 align:middle line:84% then we get that the Merkle hash is poly t secure because B, 00:34:11.710 --> 00:34:14.188 align:middle line:84% all it does really is just run A. 00:34:14.188 --> 00:34:17.560 align:middle line:84% It doesn't run much more than A, it just runs A and then it does 00:34:17.560 --> 00:34:18.949 align:middle line:90% something very trivial. 00:34:18.949 --> 00:34:20.929 align:middle line:84% So the complexity of breaking the Merkle hash 00:34:20.929 --> 00:34:22.929 align:middle line:84% is really the same as the complexity of breaking 00:34:22.929 --> 00:34:25.179 align:middle line:90% the underlying hash. 00:34:25.179 --> 00:34:28.079 align:middle line:84% So if the underlying hash is t secure, Merkle hash is t secure. 00:34:28.079 --> 00:34:32.800 align:middle line:90% 00:34:32.800 --> 00:34:33.620 align:middle line:90% Questions? 00:34:33.620 --> 00:34:39.920 align:middle line:90% 00:34:39.920 --> 00:34:40.850 align:middle line:90% OK. 00:34:40.850 --> 00:34:43.100 align:middle line:90% So where are we? 00:34:43.100 --> 00:34:44.900 align:middle line:90% So we proved the Merkle hash. 00:34:44.900 --> 00:34:46.780 align:middle line:84% As we saw, the Merkle hash was used 00:34:46.780 --> 00:34:50.020 align:middle line:84% to give an interactive-- a succinct interactive argument 00:34:50.020 --> 00:34:51.790 align:middle line:90% for all of NP. 00:34:51.790 --> 00:34:56.511 align:middle line:90% So now, if you're willing to-- 00:34:56.511 --> 00:35:01.460 align:middle line:84% you're happy with interactive protocols, thank you very much. 00:35:01.460 --> 00:35:03.675 align:middle line:84% I hope you enjoyed the semester, and we're done. 00:35:03.675 --> 00:35:04.960 align:middle line:90% [LAUGHTER] 00:35:04.960 --> 00:35:07.810 align:middle line:84% If you're not though-- but, as I said, we're actually-- 00:35:07.810 --> 00:35:10.150 align:middle line:84% we're not happy with interactive protocols. 00:35:10.150 --> 00:35:11.570 align:middle line:84% It's really interesting, actually, 00:35:11.570 --> 00:35:13.240 align:middle line:84% to think of the evolution of this 00:35:13.240 --> 00:35:18.700 align:middle line:84% because before all this interactive proofs and arguments 00:35:18.700 --> 00:35:22.060 align:middle line:84% and so on, we had just mathematical proofs, which 00:35:22.060 --> 00:35:26.170 align:middle line:84% were not interactive, but they were very, very long. 00:35:26.170 --> 00:35:27.620 align:middle line:90% And people were not happy. 00:35:27.620 --> 00:35:29.150 align:middle line:90% It's like, oh, they're so long. 00:35:29.150 --> 00:35:31.520 align:middle line:84% And then interactive proofs were defined. 00:35:31.520 --> 00:35:34.630 align:middle line:84% I think they were defined only for the sake of zero knowledge. 00:35:34.630 --> 00:35:37.000 align:middle line:84% They were defined just to get zero knowledge proofs. 00:35:37.000 --> 00:35:38.500 align:middle line:84% I'm going to actually mention that-- 00:35:38.500 --> 00:35:41.590 align:middle line:84% we're going to talk about zero knowledge later today. 00:35:41.590 --> 00:35:44.650 align:middle line:84% And this motivated the interest-- 00:35:44.650 --> 00:35:46.450 align:middle line:90% to introduce interaction. 00:35:46.450 --> 00:35:48.282 align:middle line:84% And then people are like, wow, you-- 00:35:48.282 --> 00:35:50.240 align:middle line:84% oh, what a great-- forget about zero knowledge. 00:35:50.240 --> 00:35:51.140 align:middle line:90% Forget about cryptography. 00:35:51.140 --> 00:35:52.360 align:middle line:90% This is such a great model. 00:35:52.360 --> 00:35:56.270 align:middle line:84% Using interaction we can prove a lot more. 00:35:56.270 --> 00:35:57.590 align:middle line:90% And we saw the GKR protocol. 00:35:57.590 --> 00:36:02.680 align:middle line:84% You can do-- you can prove, actually, any circuits 00:36:02.680 --> 00:36:05.440 align:middle line:84% that are really, really huge as long as they're kind of 00:36:05.440 --> 00:36:09.440 align:middle line:84% have that, you can do P space or any computation that 00:36:09.440 --> 00:36:10.430 align:middle line:90% has poly depth. 00:36:10.430 --> 00:36:12.660 align:middle line:84% Your verifier can be any depth D. You can-- 00:36:12.660 --> 00:36:15.540 align:middle line:84% the verifier runs in time D. Great. 00:36:15.540 --> 00:36:17.255 align:middle line:84% Not-- it doesn't run in the side, 00:36:17.255 --> 00:36:18.630 align:middle line:84% so it's much, much more powerful. 00:36:18.630 --> 00:36:18.740 align:middle line:90% Wow. 00:36:18.740 --> 00:36:18.920 align:middle line:90% Wow. 00:36:18.920 --> 00:36:19.560 align:middle line:90% Wow. 00:36:19.560 --> 00:36:21.860 align:middle line:84% And then people are like, actually, with cryptography, 00:36:21.860 --> 00:36:23.015 align:middle line:90% you can do much more. 00:36:23.015 --> 00:36:23.515 align:middle line:90% Great. 00:36:23.515 --> 00:36:24.050 align:middle line:90% Yeah! 00:36:24.050 --> 00:36:26.520 align:middle line:84% But now, but wait, there was a big price. 00:36:26.520 --> 00:36:28.520 align:middle line:84% We actually don't want interaction. 00:36:28.520 --> 00:36:29.550 align:middle line:90% So where are we. 00:36:29.550 --> 00:36:32.270 align:middle line:90% Are we back at NP? 00:36:32.270 --> 00:36:35.150 align:middle line:84% NP is very-- we're back in the mathematical proofs that 00:36:35.150 --> 00:36:37.010 align:middle line:90% are way, way too long? 00:36:37.010 --> 00:36:40.460 align:middle line:84% So I said, no, we're actually going 00:36:40.460 --> 00:36:42.690 align:middle line:84% to circle back in a very interesting way 00:36:42.690 --> 00:36:44.905 align:middle line:84% and get succinct non-interactive proofs. 00:36:44.905 --> 00:36:47.600 align:middle line:90% 00:36:47.600 --> 00:36:49.265 align:middle line:90% So how do we circle back? 00:36:49.265 --> 00:37:08.990 align:middle line:90% 00:37:08.990 --> 00:37:13.040 align:middle line:84% So this idea of how to circle back actually 00:37:13.040 --> 00:37:19.170 align:middle line:84% was put forth by Fiat and Shamir. 00:37:19.170 --> 00:37:22.640 align:middle line:90% This is in the mid '80s, In '86. 00:37:22.640 --> 00:37:25.830 align:middle line:84% They proposed a really, really nice paradigm. 00:37:25.830 --> 00:37:29.090 align:middle line:84% Actually, they didn't think about-- this is, remember, 00:37:29.090 --> 00:37:29.790 align:middle line:90% this is '86. 00:37:29.790 --> 00:37:32.190 align:middle line:84% This is before interactive proofs. 00:37:32.190 --> 00:37:35.510 align:middle line:84% It was just when zero knowledge was introduced. 00:37:35.510 --> 00:37:38.340 align:middle line:84% Interactive proofs just came about, 00:37:38.340 --> 00:37:41.520 align:middle line:84% but now there was no PCP, no interactive argument, 00:37:41.520 --> 00:37:43.040 align:middle line:90% none of that. 00:37:43.040 --> 00:37:45.130 align:middle line:90% This is in '86, Fiat and Shamir. 00:37:45.130 --> 00:37:56.180 align:middle line:90% 00:37:56.180 --> 00:37:59.540 align:middle line:84% They proposed a method of actually 00:37:59.540 --> 00:38:02.700 align:middle line:84% reducing interaction-- of constructing signature schemes. 00:38:02.700 --> 00:38:08.000 align:middle line:84% Now, I stand behind what I said, that this class will not require 00:38:08.000 --> 00:38:10.247 align:middle line:90% a lot of crypto background. 00:38:10.247 --> 00:38:12.330 align:middle line:84% You don't need to know what signature schemes are. 00:38:12.330 --> 00:38:18.350 align:middle line:84% But what they did, their idea is, there is a primitive called 00:38:18.350 --> 00:38:19.830 align:middle line:90% identification scheme. 00:38:19.830 --> 00:38:22.372 align:middle line:84% I want to prove to you that I'm Yael. 00:38:22.372 --> 00:38:23.580 align:middle line:90% How do I prove that I'm Yael? 00:38:23.580 --> 00:38:25.740 align:middle line:84% I have a public key corresponding to my name. 00:38:25.740 --> 00:38:28.115 align:middle line:84% And I'm going to prove to you that I know the secret key. 00:38:28.115 --> 00:38:30.058 align:middle line:84% Me knowing-- whoever knows the secret key has 00:38:30.058 --> 00:38:31.850 align:middle line:84% my identity, essentially, that's how things 00:38:31.850 --> 00:38:33.180 align:middle line:90% work in the digital world. 00:38:33.180 --> 00:38:35.790 align:middle line:84% So I'm going to prove to you that I know the secret key. 00:38:35.790 --> 00:38:38.360 align:middle line:90% This proves that I'm me. 00:38:38.360 --> 00:38:40.550 align:middle line:90% This proof is interactive. 00:38:40.550 --> 00:38:43.830 align:middle line:84% Identification protocols are like three-round protocols. 00:38:43.830 --> 00:38:46.830 align:middle line:84% I give you a message alpha, you send me a question beta, 00:38:46.830 --> 00:38:48.930 align:middle line:84% I give you an answer gamma, you verify. 00:38:48.930 --> 00:38:50.900 align:middle line:90% That's how it works. 00:38:50.900 --> 00:38:54.740 align:middle line:84% Now, they said, let's convert this identification scheme 00:38:54.740 --> 00:38:56.570 align:middle line:90% into a signature scheme. 00:38:56.570 --> 00:38:59.570 align:middle line:84% Instead of interacting to make sure it's you, 00:38:59.570 --> 00:39:04.720 align:middle line:84% every time you sign-- you want to send a message, 00:39:04.720 --> 00:39:08.730 align:middle line:84% use this message, take this identification protocol together 00:39:08.730 --> 00:39:11.440 align:middle line:84% with the message and eliminate the interaction. 00:39:11.440 --> 00:39:12.940 align:middle line:84% I'll explain exactly how they do it. 00:39:12.940 --> 00:39:15.820 align:middle line:84% But they do it in a way to construct signature scheme. 00:39:15.820 --> 00:39:17.820 align:middle line:90% That was their goal. 00:39:17.820 --> 00:39:21.810 align:middle line:84% But now, after several years after, we use it all the time 00:39:21.810 --> 00:39:24.900 align:middle line:84% to actually forget about just the specific application 00:39:24.900 --> 00:39:26.620 align:middle line:84% of identification scheme to signature, 00:39:26.620 --> 00:39:27.820 align:middle line:90% that's one application. 00:39:27.820 --> 00:39:31.170 align:middle line:84% But actually we can show-- we can use it to reduce, 00:39:31.170 --> 00:39:34.860 align:middle line:84% to eliminate interaction, not only from identification scheme, 00:39:34.860 --> 00:39:39.190 align:middle line:84% but from any interactive protocol that is public coin. 00:39:39.190 --> 00:39:40.480 align:middle line:90% So let me explain. 00:39:40.480 --> 00:39:44.190 align:middle line:90% So now, take any protocol. 00:39:44.190 --> 00:40:04.830 align:middle line:84% So this is a paradigm for eliminating interaction 00:40:04.830 --> 00:40:15.330 align:middle line:84% from interactive protocol that are public coin. 00:40:15.330 --> 00:40:19.180 align:middle line:84% So not all protocol, but ones that are public coin. 00:40:19.180 --> 00:40:22.560 align:middle line:84% So what is a public coin protocol? 00:40:22.560 --> 00:40:25.090 align:middle line:84% Take any protocol, let's say, a proof. 00:40:25.090 --> 00:40:28.770 align:middle line:84% So I have a prover and a verifier. 00:40:28.770 --> 00:40:30.540 align:middle line:90% And suppose for a second-- 00:40:30.540 --> 00:40:34.390 align:middle line:84% so suppose for simplicity that it's three messages. 00:40:34.390 --> 00:40:37.570 align:middle line:84% So the verifier-- the prover sends a message alpha. 00:40:37.570 --> 00:40:41.435 align:middle line:84% The verifier sends beta, which is random. 00:40:41.435 --> 00:40:43.950 align:middle line:84% Public coin means the message of the verifier 00:40:43.950 --> 00:40:46.030 align:middle line:90% is completely random. 00:40:46.030 --> 00:40:48.720 align:middle line:90% Let's say it's lambda bits. 00:40:48.720 --> 00:40:51.833 align:middle line:84% If it's less, then just pad it to be lambda. 00:40:51.833 --> 00:40:53.500 align:middle line:84% And if it's more, just call that lambda. 00:40:53.500 --> 00:40:55.000 align:middle line:84% Make that the security parameter. 00:40:55.000 --> 00:40:58.240 align:middle line:84% Just increase the security parameter. 00:40:58.240 --> 00:41:01.410 align:middle line:90% Now you send gamma. 00:41:01.410 --> 00:41:02.680 align:middle line:90% And maybe it's more round. 00:41:02.680 --> 00:41:08.130 align:middle line:84% So maybe then he sends delta, let's say random bits, 00:41:08.130 --> 00:41:12.150 align:middle line:84% and then you say epsilon, and you can continue. 00:41:12.150 --> 00:41:15.100 align:middle line:84% Let me stop here for the sake of-- 00:41:15.100 --> 00:41:18.370 align:middle line:84% Now I'm going to eliminate interaction. 00:41:18.370 --> 00:41:20.460 align:middle line:90% How do we eliminate interaction? 00:41:20.460 --> 00:41:22.410 align:middle line:84% It's an interaction, it's very important. 00:41:22.410 --> 00:41:23.880 align:middle line:90% I mean, the entire-- 00:41:23.880 --> 00:41:28.140 align:middle line:84% if you remember the sumcheck in GKR-- 00:41:28.140 --> 00:41:32.580 align:middle line:84% I mean, it's tempting maybe to say, oh, tell the prover, 00:41:32.580 --> 00:41:34.915 align:middle line:84% compute alpha, beta, gamma, just compute 00:41:34.915 --> 00:41:36.040 align:middle line:90% the transcript on your own. 00:41:36.040 --> 00:41:40.890 align:middle line:84% You simulate the verifier's messages, then he'll cheat. 00:41:40.890 --> 00:41:44.640 align:middle line:84% So how do you get rid of the interaction? 00:41:44.640 --> 00:41:49.440 align:middle line:90% It seems really, really hard. 00:41:49.440 --> 00:41:51.010 align:middle line:90% Actually, it's so easy. 00:41:51.010 --> 00:41:52.920 align:middle line:90% I mean, their idea is trivial. 00:41:52.920 --> 00:41:54.160 align:middle line:90% So what is their idea? 00:41:54.160 --> 00:41:57.900 align:middle line:90% They say the following. 00:41:57.900 --> 00:42:01.900 align:middle line:84% How does the verifier-- how does the prover get this beta? 00:42:01.900 --> 00:42:04.180 align:middle line:90% The verifier chose it. 00:42:04.180 --> 00:42:05.830 align:middle line:90% Do you know what? 00:42:05.830 --> 00:42:09.375 align:middle line:84% Let's not have the ver-- now we don't have a verifier. 00:42:09.375 --> 00:42:10.250 align:middle line:90% It's not interactive. 00:42:10.250 --> 00:42:11.300 align:middle line:90% There is no verifier. 00:42:11.300 --> 00:42:13.240 align:middle line:90% So how do you compute this beta? 00:42:13.240 --> 00:42:16.840 align:middle line:84% Let's compute it as a hash function applied 00:42:16.840 --> 00:42:19.870 align:middle line:90% to the transcript so far. 00:42:19.870 --> 00:42:21.440 align:middle line:90% So let me explain. 00:42:21.440 --> 00:42:24.790 align:middle line:84% So how-- here's how you convert it 00:42:24.790 --> 00:42:30.460 align:middle line:84% to P Fiat-Shamir, V Fiat-Shamir, this 00:42:30.460 --> 00:42:34.390 align:middle line:84% is associated with some hash family. 00:42:34.390 --> 00:42:36.950 align:middle line:84% There are some-- it's associated with a hash family. 00:42:36.950 --> 00:42:40.360 align:middle line:84% So the Fiat-Shamir paradigm, you can take any hash family and use 00:42:40.360 --> 00:42:42.220 align:middle line:90% that to reduce interaction. 00:42:42.220 --> 00:42:44.180 align:middle line:84% How do you use it to reduce interaction? 00:42:44.180 --> 00:42:50.600 align:middle line:84% Now, there are some hash key that's chosen once and for all. 00:42:50.600 --> 00:42:51.770 align:middle line:90% Everybody knows it. 00:42:51.770 --> 00:42:53.540 align:middle line:84% Either the verifier sends it once, 00:42:53.540 --> 00:42:56.120 align:middle line:84% or if you think about public-- everybody can verify, 00:42:56.120 --> 00:43:00.980 align:middle line:84% I don't know, the US government publishes this hash key, 00:43:00.980 --> 00:43:02.440 align:middle line:90% everybody uses this hash key. 00:43:02.440 --> 00:43:04.610 align:middle line:84% There are some fixed hash key, everybody uses it. 00:43:04.610 --> 00:43:10.930 align:middle line:84% Now, once we agree on a hash key, what does the prover do? 00:43:10.930 --> 00:43:12.610 align:middle line:90% He computes alpha. 00:43:12.610 --> 00:43:17.860 align:middle line:84% Let's say he wants to prove that x is in some language. 00:43:17.860 --> 00:43:20.830 align:middle line:84% So let's say he says, OK, I'm going to prove to you that x 00:43:20.830 --> 00:43:22.180 align:middle line:90% is in the language. 00:43:22.180 --> 00:43:24.040 align:middle line:90% Let me prove it to you. 00:43:24.040 --> 00:43:26.530 align:middle line:90% OK, I compute the alpha. 00:43:26.530 --> 00:43:28.640 align:middle line:90% Now I'm waiting for a beta. 00:43:28.640 --> 00:43:30.320 align:middle line:90% But there is no verifier. 00:43:30.320 --> 00:43:31.548 align:middle line:90% Fine. 00:43:31.548 --> 00:43:32.840 align:middle line:90% I'll tell you what the beta is. 00:43:32.840 --> 00:43:36.250 align:middle line:84% Beta is just-- has to-- is going to be eval 00:43:36.250 --> 00:43:42.730 align:middle line:84% of hash key and the transcript so far, x and alpha. 00:43:42.730 --> 00:43:46.210 align:middle line:84% That's currently what's in the transcript, the statement 00:43:46.210 --> 00:43:48.520 align:middle line:90% and the first message alpha. 00:43:48.520 --> 00:43:50.500 align:middle line:84% Now the proof is like, OK, this is the beta 00:43:50.500 --> 00:43:51.770 align:middle line:90% I got from the verifier. 00:43:51.770 --> 00:43:55.180 align:middle line:84% He's interpreting this as the beta he got from the verifier. 00:43:55.180 --> 00:43:59.540 align:middle line:84% And now he computes gamma, my answer, the prover's answer. 00:43:59.540 --> 00:44:01.840 align:middle line:84% Now he's waiting for a message for-- a query 00:44:01.840 --> 00:44:04.990 align:middle line:90% from the verifier, some delta. 00:44:04.990 --> 00:44:06.610 align:middle line:84% But there is no verifier, so it's 00:44:06.610 --> 00:44:12.970 align:middle line:84% going to compute the delta as eval of the hash key using 00:44:12.970 --> 00:44:14.150 align:middle line:90% the transcript so far. 00:44:14.150 --> 00:44:19.750 align:middle line:90% So x, alpha, beta, gamma. 00:44:19.750 --> 00:44:23.890 align:middle line:84% Once he has delta, he's going to go back to being a prover 00:44:23.890 --> 00:44:27.850 align:middle line:90% and compute epsilon. 00:44:27.850 --> 00:44:29.420 align:middle line:90% And then you can continue. 00:44:29.420 --> 00:44:30.790 align:middle line:90% Next message, he goes-- 00:44:30.790 --> 00:44:34.450 align:middle line:84% computes a hash value of all the transcript 00:44:34.450 --> 00:44:37.770 align:middle line:84% so far, computes the next prover's message. 00:44:37.770 --> 00:44:43.090 align:middle line:84% Here another verif-- and we go-- that's how we continue. 00:44:43.090 --> 00:44:45.500 align:middle line:84% Any questions about-- so what did we go? 00:44:45.500 --> 00:44:49.090 align:middle line:84% We started from an interactive protocol. 00:44:49.090 --> 00:44:51.320 align:middle line:90% You can have many rounds. 00:44:51.320 --> 00:44:54.785 align:middle line:84% And now all we need is to agree on a hash key. 00:44:54.785 --> 00:44:57.410 align:middle line:84% And once again, we're going to hash key-- the prover just gives 00:44:57.410 --> 00:44:58.980 align:middle line:90% you-- this is one message. 00:44:58.980 --> 00:45:01.160 align:middle line:90% That's it. 00:45:01.160 --> 00:45:01.880 align:middle line:90% Yeah. 00:45:01.880 --> 00:45:03.685 align:middle line:84% AUDIENCE: Is it important to include beta in the transcript 00:45:03.685 --> 00:45:04.430 align:middle line:90% when you're hashing? 00:45:04.430 --> 00:45:05.670 align:middle line:84% YAEL T. KALAI: Good, great question. 00:45:05.670 --> 00:45:06.630 align:middle line:90% Is it important to include beta? 00:45:06.630 --> 00:45:08.297 align:middle line:84% Actually, you don't need to include beta 00:45:08.297 --> 00:45:10.520 align:middle line:84% at all because the verifier can compute beta. 00:45:10.520 --> 00:45:14.640 align:middle line:84% So you only need to know beta so you can compute gamma. 00:45:14.640 --> 00:45:17.030 align:middle line:84% You actually don't need to include it. 00:45:17.030 --> 00:45:17.693 align:middle line:90% Great question. 00:45:17.693 --> 00:45:18.610 align:middle line:90% Great, great question. 00:45:18.610 --> 00:45:22.220 align:middle line:90% 00:45:22.220 --> 00:45:25.790 align:middle line:84% So note, for example, if you think about Kilian and Micali 00:45:25.790 --> 00:45:28.140 align:middle line:84% protocol, you may not remember it, 00:45:28.140 --> 00:45:30.760 align:middle line:84% but let me just write it here just to refresh your memory. 00:45:30.760 --> 00:45:31.260 align:middle line:90% Why not? 00:45:31.260 --> 00:45:33.052 align:middle line:84% You don't need to actually understand this, 00:45:33.052 --> 00:45:36.290 align:middle line:84% but since it's such a nice protocol-- and so, 00:45:36.290 --> 00:45:37.050 align:middle line:90% how does it go? 00:45:37.050 --> 00:45:38.790 align:middle line:90% There's a prover and a verifier. 00:45:38.790 --> 00:45:40.650 align:middle line:90% The verifier sends a hash key. 00:45:40.650 --> 00:45:44.210 align:middle line:84% So he wants to prove that x is in L. He 00:45:44.210 --> 00:45:47.280 align:middle line:90% does a Merkle hash of the PC. 00:45:47.280 --> 00:45:48.660 align:middle line:90% So he computes a PCP. 00:45:48.660 --> 00:45:56.130 align:middle line:84% Pi is a PCP for x in L. And he sends you the Merkle hash. 00:45:56.130 --> 00:46:02.340 align:middle line:84% So he sends you root and the depth. 00:46:02.340 --> 00:46:07.220 align:middle line:84% That's just the-- so he takes the PCP 00:46:07.220 --> 00:46:09.595 align:middle line:84% and he does a hash with local opening. 00:46:09.595 --> 00:46:10.970 align:middle line:84% For example, Merkle hash actually 00:46:10.970 --> 00:46:13.800 align:middle line:84% can do any hash with local opening that you want. 00:46:13.800 --> 00:46:15.950 align:middle line:90% This is the most common one. 00:46:15.950 --> 00:46:21.060 align:middle line:84% And then he gets the randomness from the PCP verifier. 00:46:21.060 --> 00:46:24.140 align:middle line:84% So this is r from r corresponding 00:46:24.140 --> 00:46:26.360 align:middle line:90% to the PCP verifier. 00:46:26.360 --> 00:46:29.100 align:middle line:84% This determines a few locations to open. 00:46:29.100 --> 00:46:30.240 align:middle line:90% So now he opens. 00:46:30.240 --> 00:46:36.320 align:middle line:84% So he gives-- so this randomness corresponds to some locations, 00:46:36.320 --> 00:46:39.860 align:middle line:84% i1 up to il, and then you just open pi i1 00:46:39.860 --> 00:46:45.230 align:middle line:84% with open 1 up to pi il with open l. 00:46:45.230 --> 00:46:46.650 align:middle line:90% That's the protocol. 00:46:46.650 --> 00:46:50.900 align:middle line:90% Note, this is completely random. 00:46:50.900 --> 00:46:53.690 align:middle line:84% It's the randomness of the PCP verifier. 00:46:53.690 --> 00:46:56.610 align:middle line:90% So we can eliminate interaction. 00:46:56.610 --> 00:46:58.550 align:middle line:84% This, if you think of it, this is just 00:46:58.550 --> 00:47:01.820 align:middle line:84% of a protocol where you send a hash key, 00:47:01.820 --> 00:47:04.605 align:middle line:84% and then you have alpha, beta, gamma. 00:47:04.605 --> 00:47:08.480 align:middle line:90% 00:47:08.480 --> 00:47:10.260 align:middle line:90% So let's eliminate interaction. 00:47:10.260 --> 00:47:12.090 align:middle line:84% So how do we eliminate interaction? 00:47:12.090 --> 00:47:14.720 align:middle line:90% Well, there's this hash key. 00:47:14.720 --> 00:47:16.640 align:middle line:84% We can use this hash key to do Fiat-Shamir, 00:47:16.640 --> 00:47:21.020 align:middle line:84% but we can also use another hash key, hash key sub Fiat-Shamir. 00:47:21.020 --> 00:47:26.970 align:middle line:84% And now the-- well, this can be-- now you give alpha. 00:47:26.970 --> 00:47:29.820 align:middle line:84% Beta is going to be simply-- you don't have to include it. 00:47:29.820 --> 00:47:31.400 align:middle line:84% But it's going to be, in our head, 00:47:31.400 --> 00:47:42.080 align:middle line:84% it's going to be eval of hash key Fiat-Shamir of x in alpha. 00:47:42.080 --> 00:47:46.520 align:middle line:84% And then maybe hash key is also part of the transcript. 00:47:46.520 --> 00:47:48.870 align:middle line:90% And this gives beta. 00:47:48.870 --> 00:47:50.905 align:middle line:84% Now you compute the gamma, which is the opening. 00:47:50.905 --> 00:47:54.290 align:middle line:90% 00:47:54.290 --> 00:47:59.480 align:middle line:84% So you can take any-- so now if-- 00:47:59.480 --> 00:48:01.290 align:middle line:84% what does the Fiat-Shamir gives you? 00:48:01.290 --> 00:48:04.460 align:middle line:84% It gives us a way-- remember, Kilian and Micali 00:48:04.460 --> 00:48:06.300 align:middle line:90% was very succinct. 00:48:06.300 --> 00:48:10.580 align:middle line:84% You can take x any-- let's say NP language, 00:48:10.580 --> 00:48:11.703 align:middle line:90% N can be very large. 00:48:11.703 --> 00:48:14.370 align:middle line:84% It can be lambda to the 1,000, I don't know, it can be whatever. 00:48:14.370 --> 00:48:16.530 align:middle line:84% It can be even super polynomial lambda. 00:48:16.530 --> 00:48:20.780 align:middle line:84% It can be almost as large as 2 to the lambda. 00:48:20.780 --> 00:48:22.980 align:middle line:84% And look how succinct the protocol is. 00:48:22.980 --> 00:48:26.510 align:middle line:84% You just send a hash key, the root, which is lambda bits, 00:48:26.510 --> 00:48:30.920 align:middle line:84% and the opening, the PCP is all lambda bits, poly lambda bits, 00:48:30.920 --> 00:48:32.880 align:middle line:90% so very, very succinct. 00:48:32.880 --> 00:48:34.770 align:middle line:84% And now you can even just make it-- 00:48:34.770 --> 00:48:39.740 align:middle line:84% so what is this-- you can all send it all one round. 00:48:39.740 --> 00:48:41.295 align:middle line:90% So what does it give you? 00:48:41.295 --> 00:48:42.170 align:middle line:90% What does it tell us? 00:48:42.170 --> 00:48:45.170 align:middle line:84% That we can take any NP statement 00:48:45.170 --> 00:48:47.210 align:middle line:84% and give a proof of size poly lambda. 00:48:47.210 --> 00:48:48.730 align:middle line:90% Doesn't matter what size x is. 00:48:48.730 --> 00:48:51.990 align:middle line:90% 00:48:51.990 --> 00:48:54.120 align:middle line:90% That's amazing. 00:48:54.120 --> 00:48:56.160 align:middle line:84% Without cryptography, we need poly [INAUDIBLE], 00:48:56.160 --> 00:48:57.940 align:middle line:90% these gigantic witnesses. 00:48:57.940 --> 00:48:58.440 align:middle line:90% Yeah. 00:48:58.440 --> 00:49:00.732 align:middle line:84% AUDIENCE: I guess for the collision resistance security 00:49:00.732 --> 00:49:03.000 align:middle line:84% property and probabilistic encoder hash keys, 00:49:03.000 --> 00:49:05.450 align:middle line:84% you can imagine some kind of weird hash family 00:49:05.450 --> 00:49:07.450 align:middle line:84% where there exist hash keys that are really bad. 00:49:07.450 --> 00:49:10.080 align:middle line:84% And so I guess here it's fine because the verifier 00:49:10.080 --> 00:49:11.080 align:middle line:90% chooses the hash key. 00:49:11.080 --> 00:49:13.800 align:middle line:84% But you might imagine if the US government publishes a hash key 00:49:13.800 --> 00:49:16.230 align:middle line:84% or anything else, what if it happens to be a bad one 00:49:16.230 --> 00:49:17.650 align:middle line:84% or it was chosen to be a bad one? 00:49:17.650 --> 00:49:19.300 align:middle line:90% YAEL T. KALAI: OK, two things. 00:49:19.300 --> 00:49:20.760 align:middle line:84% First, you're saying, who chooses 00:49:20.760 --> 00:49:22.350 align:middle line:84% this hash key of the Fiat-Shamir, 00:49:22.350 --> 00:49:23.940 align:middle line:90% how do we know that we trust it? 00:49:23.940 --> 00:49:27.060 align:middle line:84% But you know, it's much worse than that. 00:49:27.060 --> 00:49:27.760 align:middle line:90% Is it secure? 00:49:27.760 --> 00:49:31.320 align:middle line:84% Let's say it's chosen randomly from the hash family. 00:49:31.320 --> 00:49:34.140 align:middle line:90% Is this sound? 00:49:34.140 --> 00:49:36.600 align:middle line:90% So again, what did we do here? 00:49:36.600 --> 00:49:39.610 align:middle line:84% We started with an interactive protocol. 00:49:39.610 --> 00:49:40.600 align:middle line:90% We proved it's sound. 00:49:40.600 --> 00:49:41.790 align:middle line:84% Let's say, Kilian and Micali is sound. 00:49:41.790 --> 00:49:42.580 align:middle line:90% We proved it. 00:49:42.580 --> 00:49:44.330 align:middle line:84% Assuming we have collision-resistant hash, 00:49:44.330 --> 00:49:46.470 align:middle line:90% we proved that it's sound. 00:49:46.470 --> 00:49:50.640 align:middle line:84% It's sound assuming the prover gets the messages 00:49:50.640 --> 00:49:52.090 align:middle line:90% of the verifier randomly. 00:49:52.090 --> 00:49:54.070 align:middle line:90% That's what it sounds. 00:49:54.070 --> 00:49:56.820 align:middle line:90% We used it to prove soundness. 00:49:56.820 --> 00:49:57.983 align:middle line:90% Now, what am I saying? 00:49:57.983 --> 00:49:58.900 align:middle line:90% What are we doing now? 00:49:58.900 --> 00:50:01.240 align:middle line:90% I'm saying, oh, forget about it. 00:50:01.240 --> 00:50:02.230 align:middle line:90% It's not random. 00:50:02.230 --> 00:50:07.890 align:middle line:84% Actually, you compute it on your own from some hash key 00:50:07.890 --> 00:50:10.200 align:middle line:84% that someone chooses even honestly 00:50:10.200 --> 00:50:13.200 align:middle line:84% from-- let's say we agree-- we all agreed on some hash family 00:50:13.200 --> 00:50:14.948 align:middle line:84% and someone honestly chose a hash key. 00:50:14.948 --> 00:50:16.240 align:middle line:90% But now you know this hash key. 00:50:16.240 --> 00:50:18.300 align:middle line:90% Now you compute. 00:50:18.300 --> 00:50:19.270 align:middle line:90% Who says it's sound? 00:50:19.270 --> 00:50:20.380 align:middle line:90% I mean, is it still sound? 00:50:20.380 --> 00:50:21.580 align:middle line:90% Maybe it's not sound. 00:50:21.580 --> 00:50:23.580 align:middle line:84% AUDIENCE: Maybe the hash key always outputs 0, 00:50:23.580 --> 00:50:24.577 align:middle line:90% but at the start-- 00:50:24.577 --> 00:50:25.410 align:middle line:90% [INTERPOSING VOICES] 00:50:25.410 --> 00:50:26.160 align:middle line:90% YAEL T. KALAI: OK. 00:50:26.160 --> 00:50:34.090 align:middle line:84% So first of all, of course, there's-- one can think of-- 00:50:34.090 --> 00:50:37.060 align:middle line:84% this hash functions need to have some property. 00:50:37.060 --> 00:50:39.330 align:middle line:84% Collision resistance, at the minimum, 00:50:39.330 --> 00:50:42.180 align:middle line:84% if you can find collisions-- for example, here, you're screwed. 00:50:42.180 --> 00:50:44.400 align:middle line:90% I mean, it can't be like that. 00:50:44.400 --> 00:50:45.610 align:middle line:90% It can't be trivial. 00:50:45.610 --> 00:50:46.860 align:middle line:90% So you need some property. 00:50:46.860 --> 00:50:50.070 align:middle line:84% Now the question is, what property do you need? 00:50:50.070 --> 00:50:54.300 align:middle line:84% What property do you need from this hash family 00:50:54.300 --> 00:50:55.270 align:middle line:90% to argue soundness? 00:50:55.270 --> 00:50:56.210 align:middle line:90% Yeah. 00:50:56.210 --> 00:50:59.100 align:middle line:84% AUDIENCE: I'm not sure if it's pseudorandomness or true 00:50:59.100 --> 00:51:01.237 align:middle line:84% randomness, but the output's still random. 00:51:01.237 --> 00:51:02.320 align:middle line:90% YAEL T. KALAI: Very, very. 00:51:02.320 --> 00:51:02.800 align:middle line:90% OK, good. 00:51:02.800 --> 00:51:04.508 align:middle line:84% So it seems like, well, what do you need? 00:51:04.508 --> 00:51:06.940 align:middle line:84% It needs to be random, like in that protocol. 00:51:06.940 --> 00:51:08.550 align:middle line:90% We want to say, take any-- 00:51:08.550 --> 00:51:09.490 align:middle line:90% what is our goal? 00:51:09.490 --> 00:51:13.380 align:middle line:84% Our goal is to say, take any protocol that is sound, 00:51:13.380 --> 00:51:18.340 align:middle line:84% public coin, and we want to convert it to non-interactive. 00:51:18.340 --> 00:51:19.740 align:middle line:90% That's what we're trying to do. 00:51:19.740 --> 00:51:21.550 align:middle line:84% Now, I'm saying, what property do you need? 00:51:21.550 --> 00:51:24.690 align:middle line:84% Well, look here, well, our guarantee 00:51:24.690 --> 00:51:26.380 align:middle line:84% was that it's sound if this is random. 00:51:26.380 --> 00:51:30.540 align:middle line:84% So we need this hash to be somehow random. 00:51:30.540 --> 00:51:32.520 align:middle line:90% Stands to reason. 00:51:32.520 --> 00:51:34.150 align:middle line:90% So this is written out. 00:51:34.150 --> 00:51:36.400 align:middle line:84% But, look, hash functions are not random. 00:51:36.400 --> 00:51:37.420 align:middle line:90% It's a hash function. 00:51:37.420 --> 00:51:40.440 align:middle line:84% By the way, let me say, this paradigm 00:51:40.440 --> 00:51:41.980 align:middle line:90% is used all over the place. 00:51:41.980 --> 00:51:43.690 align:middle line:90% It's a very popular paradigm. 00:51:43.690 --> 00:51:46.600 align:middle line:84% It's used a lot in signature schemes 00:51:46.600 --> 00:51:50.290 align:middle line:90% and also in proof systems. 00:51:50.290 --> 00:51:52.240 align:middle line:90% It's used all over the place. 00:51:52.240 --> 00:51:54.680 align:middle line:90% And which hash function is used? 00:51:54.680 --> 00:51:57.490 align:middle line:84% Some off-the-shelf hash function, SHA256, 00:51:57.490 --> 00:52:03.370 align:middle line:84% like these engineer-type hash functions that are optimized. 00:52:03.370 --> 00:52:07.455 align:middle line:90% So is it secure with SHA256? 00:52:07.455 --> 00:52:08.580 align:middle line:90% It's definitely not random. 00:52:08.580 --> 00:52:11.230 align:middle line:90% 00:52:11.230 --> 00:52:13.900 align:middle line:90% So we actually don't know. 00:52:13.900 --> 00:52:18.100 align:middle line:84% So let me be honest that is it secure? 00:52:18.100 --> 00:52:20.030 align:middle line:90% I don't know. 00:52:20.030 --> 00:52:20.530 align:middle line:90% Yeah. 00:52:20.530 --> 00:52:21.310 align:middle line:90% AUDIENCE: Yeah. 00:52:21.310 --> 00:52:23.230 align:middle line:84% I think the specification [INAUDIBLE] 00:52:23.230 --> 00:52:26.140 align:middle line:84% is already shown that by length extension [INAUDIBLE] 00:52:26.140 --> 00:52:29.395 align:middle line:84% is definitely not now indistinguishable. 00:52:29.395 --> 00:52:30.520 align:middle line:90% YAEL T. KALAI: Yeah, right. 00:52:30.520 --> 00:52:31.030 align:middle line:90% Yeah. 00:52:31.030 --> 00:52:32.225 align:middle line:90% [INTERPOSING VOICES] 00:52:32.225 --> 00:52:33.100 align:middle line:90% YAEL T. KALAI: Right. 00:52:33.100 --> 00:52:33.280 align:middle line:90% Right. 00:52:33.280 --> 00:52:33.780 align:middle line:90% Right. 00:52:33.780 --> 00:52:35.260 align:middle line:90% So actually, let me-- good. 00:52:35.260 --> 00:52:36.630 align:middle line:90% So let me just say a few things. 00:52:36.630 --> 00:52:39.670 align:middle line:90% 00:52:39.670 --> 00:52:43.600 align:middle line:90% OK, maybe I'll cut to the chase. 00:52:43.600 --> 00:52:46.880 align:middle line:84% I do know-- let me tell you, it's not necessarily secure. 00:52:46.880 --> 00:52:50.050 align:middle line:84% Actually, unfortunately, we have counterexamples. 00:52:50.050 --> 00:52:52.760 align:middle line:84% So I said this is used in practice all the time. 00:52:52.760 --> 00:52:56.810 align:middle line:84% It's one of the great inventions of cryptography. 00:52:56.810 --> 00:52:57.505 align:middle line:90% Is it secure? 00:52:57.505 --> 00:52:58.005 align:middle line:90% No. 00:52:58.005 --> 00:53:00.140 align:middle line:90% [LAUGHTER] 00:53:00.140 --> 00:53:01.480 align:middle line:90% So what do I mean by no? 00:53:01.480 --> 00:53:04.730 align:middle line:84% OK, let me-- is it always secure? 00:53:04.730 --> 00:53:06.100 align:middle line:90% No. 00:53:06.100 --> 00:53:08.800 align:middle line:84% So let me say-- let me take back my notes said. 00:53:08.800 --> 00:53:10.040 align:middle line:90% Is it always secure? 00:53:10.040 --> 00:53:11.590 align:middle line:84% Is it always the case that when you 00:53:11.590 --> 00:53:14.230 align:middle line:84% start with an interactive protocol 00:53:14.230 --> 00:53:17.110 align:middle line:84% and convert a public coin, and you apply Fiat-Shamir, is it 00:53:17.110 --> 00:53:17.810 align:middle line:90% always secure? 00:53:17.810 --> 00:53:18.430 align:middle line:90% No. 00:53:18.430 --> 00:53:21.100 align:middle line:84% Moreover, let me tell you, we have 00:53:21.100 --> 00:53:24.820 align:middle line:84% protocols so that no matter which hash family 00:53:24.820 --> 00:53:31.990 align:middle line:84% you use, for all hash families, the protocol becomes insecure. 00:53:31.990 --> 00:53:33.800 align:middle line:84% Let me tell you even more than that. 00:53:33.800 --> 00:53:37.650 align:middle line:90% That will really you'll be mad. 00:53:37.650 --> 00:53:41.920 align:middle line:84% The Kilian-Micali protocol that we built up, 00:53:41.920 --> 00:53:45.560 align:middle line:84% ah, ah, ah, even that's not secure. 00:53:45.560 --> 00:53:48.250 align:middle line:84% The Fiat-Shamir will be secure on n. 00:53:48.250 --> 00:53:53.870 align:middle line:84% But this, let me actually put an asterisk there, it's what-- 00:53:53.870 --> 00:53:55.450 align:middle line:84% OK, so let me tell you what's known 00:53:55.450 --> 00:53:58.240 align:middle line:84% about the insecurity of the Fiat-Shamir paradigm 00:53:58.240 --> 00:53:59.450 align:middle line:90% for this protocol. 00:53:59.450 --> 00:54:02.750 align:middle line:84% What is known is there are some contrived-- 00:54:02.750 --> 00:54:05.920 align:middle line:84% so the Kilian-Micali protocol says, 00:54:05.920 --> 00:54:10.840 align:middle line:84% take any hash function that's collision-resistant 00:54:10.840 --> 00:54:18.190 align:middle line:84% and take any PCP, we get soundness. 00:54:18.190 --> 00:54:24.790 align:middle line:84% There are examples of specific hash functions or specific PCPs 00:54:24.790 --> 00:54:26.740 align:middle line:84% that are sound, of course, because it's-- 00:54:26.740 --> 00:54:28.990 align:middle line:84% I mean, there are examples of collision-resistant hash 00:54:28.990 --> 00:54:32.450 align:middle line:84% functions and PCPs such that this, of course, 00:54:32.450 --> 00:54:35.200 align:middle line:84% is sound-- it's sound for any collision hash function PCP, 00:54:35.200 --> 00:54:38.470 align:middle line:84% but such that no matter which hash 00:54:38.470 --> 00:54:40.910 align:middle line:84% function you use for the Fiat-Shamir, 00:54:40.910 --> 00:54:44.780 align:middle line:84% this will be insecure, not sound. 00:54:44.780 --> 00:54:45.835 align:middle line:90% No matter what you use. 00:54:45.835 --> 00:54:50.600 align:middle line:90% 00:54:50.600 --> 00:54:52.012 align:middle line:90% Yeah? 00:54:52.012 --> 00:54:54.470 align:middle line:84% AUDIENCE: Could you do a little more in detail what breaks? 00:54:54.470 --> 00:54:55.303 align:middle line:90% YAEL T. KALAI: Yeah. 00:54:55.303 --> 00:54:57.930 align:middle line:84% I'll say a little bit what breaks in a second. 00:54:57.930 --> 00:54:58.430 align:middle line:90% Yeah. 00:54:58.430 --> 00:55:00.170 align:middle line:84% AUDIENCE: [INAUDIBLE] or it's natural? 00:55:00.170 --> 00:55:01.170 align:middle line:90% YAEL T. KALAI: OK, good. 00:55:01.170 --> 00:55:01.830 align:middle line:90% Same question. 00:55:01.830 --> 00:55:06.680 align:middle line:84% So the example for why-- so why it breaks? 00:55:06.680 --> 00:55:10.110 align:middle line:84% The example for why it breaks is very contrived actually. 00:55:10.110 --> 00:55:14.910 align:middle line:84% So that's why, is the message here, don't use Fiat-Shamir. 00:55:14.910 --> 00:55:15.900 align:middle line:90% We have a break. 00:55:15.900 --> 00:55:17.270 align:middle line:90% No, that's not the message. 00:55:17.270 --> 00:55:18.950 align:middle line:84% You should use Fiat-Shamir because, in practice, it 00:55:18.950 --> 00:55:19.800 align:middle line:90% works very well. 00:55:19.800 --> 00:55:22.820 align:middle line:84% I don't have a single instance that people use Fiat-Shamir 00:55:22.820 --> 00:55:24.590 align:middle line:90% in practice and it broke. 00:55:24.590 --> 00:55:26.520 align:middle line:90% So it's a great paradigm. 00:55:26.520 --> 00:55:28.100 align:middle line:90% Use it. 00:55:28.100 --> 00:55:30.780 align:middle line:84% Can we come up with a general proof of security? 00:55:30.780 --> 00:55:34.070 align:middle line:84% No, because we have counterexamples. 00:55:34.070 --> 00:55:36.300 align:middle line:90% So what did we learn? 00:55:36.300 --> 00:55:38.900 align:middle line:90% So maybe I'll start by saying-- 00:55:38.900 --> 00:55:42.050 align:middle line:84% I'll say very, very high level, not in detail, 00:55:42.050 --> 00:55:45.170 align:middle line:90% but about the counterexamples. 00:55:45.170 --> 00:55:47.030 align:middle line:84% How can we build counterexamples? 00:55:47.030 --> 00:55:49.470 align:middle line:84% And as opposed to going to the Kilian-Micali protocol, 00:55:49.470 --> 00:55:52.280 align:middle line:84% because there you need to work a little harder to fit it in-- 00:55:52.280 --> 00:55:54.480 align:middle line:84% I'll say a word about how you fit it in there too. 00:55:54.480 --> 00:55:55.950 align:middle line:90% But the idea is the following. 00:55:55.950 --> 00:56:00.240 align:middle line:84% Let me try to give you a proof that is-- 00:56:00.240 --> 00:56:02.880 align:middle line:84% or an interactive protocol that is sound. 00:56:02.880 --> 00:56:06.470 align:middle line:90% But when you convert it to-- 00:56:06.470 --> 00:56:09.440 align:middle line:84% when you apply Fiat-Shamir, soundness breaks. 00:56:09.440 --> 00:56:12.980 align:middle line:90% So the idea is the following. 00:56:12.980 --> 00:56:15.120 align:middle line:84% It can be a very contrived protocol. 00:56:15.120 --> 00:56:24.470 align:middle line:84% So what I want to do is construct a contrived protocol 00:56:24.470 --> 00:56:26.660 align:middle line:90% that is sound. 00:56:26.660 --> 00:56:28.400 align:middle line:84% But when you apply Fiat-Shamir, no matter 00:56:28.400 --> 00:56:31.880 align:middle line:84% which hash function you use, it will break. 00:56:31.880 --> 00:56:35.550 align:middle line:84% And intuitively, the contrived protocol is the following. 00:56:35.550 --> 00:56:40.670 align:middle line:84% Take any sound protocol, for example, Kilian-Micali. 00:56:40.670 --> 00:56:43.580 align:middle line:84% Whatever-- or GKR whatever sound protocol you like. 00:56:43.580 --> 00:56:44.990 align:middle line:90% And I'm going to change it-- 00:56:44.990 --> 00:56:47.780 align:middle line:84% I'm going to tweak a little bit that the soundness will still 00:56:47.780 --> 00:56:48.300 align:middle line:90% remain. 00:56:48.300 --> 00:56:53.960 align:middle line:84% I'm going to tweak it so that the soundness will still hold. 00:56:53.960 --> 00:56:56.520 align:middle line:84% But on the tweaked protocol, when you apply Fiat-Shamir, 00:56:56.520 --> 00:56:58.920 align:middle line:90% it will fail. 00:56:58.920 --> 00:57:02.510 align:middle line:84% So start with PV, for example, GKR, for example, Kilian-Micali, 00:57:02.510 --> 00:57:04.040 align:middle line:90% whatever you like. 00:57:04.040 --> 00:57:07.460 align:middle line:84% And I'm going to tweak it a little bit. 00:57:07.460 --> 00:57:08.970 align:middle line:90% How am I going to tweak it? 00:57:08.970 --> 00:57:12.590 align:middle line:84% I'm going to say, tell the verifier, you know what? 00:57:12.590 --> 00:57:15.710 align:middle line:84% Accept, if you accept it before, but 00:57:15.710 --> 00:57:17.700 align:middle line:84% accept also if something very weird happens. 00:57:17.700 --> 00:57:21.210 align:middle line:84% But don't worry, it will never happen. 00:57:21.210 --> 00:57:22.830 align:middle line:84% When else are you going to accept? 00:57:22.830 --> 00:57:28.100 align:middle line:84% So remember the verifier, let's say, he sends a random beta. 00:57:28.100 --> 00:57:33.510 align:middle line:84% If the prover, let's say, ahead of time, guessed your beta, 00:57:33.510 --> 00:57:35.970 align:middle line:84% he told you, I know how you're going to compute your beta. 00:57:35.970 --> 00:57:41.430 align:middle line:84% So if the prover, ahead of time, send you 00:57:41.430 --> 00:57:44.250 align:middle line:90% a message that will tell you-- 00:57:44.250 --> 00:57:51.910 align:middle line:84% say, I can predict beta, and will predict beta ahead of time, 00:57:51.910 --> 00:57:54.668 align:middle line:84% then you accept him because this is random. 00:57:54.668 --> 00:57:56.710 align:middle line:84% What's the probability that you can pick my beta? 00:57:56.710 --> 00:57:59.920 align:middle line:84% If beta is random 0, 1 to the lambda, 00:57:59.920 --> 00:58:01.750 align:middle line:84% there's no way you can predict it. 00:58:01.750 --> 00:58:04.170 align:middle line:84% So if by any chance you predict I'm going to-- 00:58:04.170 --> 00:58:07.242 align:middle line:84% you won the lottery, I'll accept you. 00:58:07.242 --> 00:58:08.950 align:middle line:84% I don't care if x in the language or not. 00:58:08.950 --> 00:58:12.300 align:middle line:84% It only adds a negligible probability of-- 00:58:12.300 --> 00:58:15.960 align:middle line:84% because the probability that you could predict beta is 1 over 2 00:58:15.960 --> 00:58:16.550 align:middle line:90% to the beta. 00:58:16.550 --> 00:58:20.550 align:middle line:90% 00:58:20.550 --> 00:58:23.830 align:middle line:84% Now, what happens in the Fiat-Shamir paradigm? 00:58:23.830 --> 00:58:26.505 align:middle line:84% Oh, I can tell you, oh, I know, beta, I can predict it. 00:58:26.505 --> 00:58:28.630 align:middle line:84% And I'm going to tell you exactly how I predict it. 00:58:28.630 --> 00:58:33.290 align:middle line:84% Beta is going to be equal hash key and this message. 00:58:33.290 --> 00:58:37.650 align:middle line:90% 00:58:37.650 --> 00:58:38.740 align:middle line:90% That's the idea. 00:58:38.740 --> 00:58:43.000 align:middle line:84% Now, to implement this idea, it's harder. 00:58:43.000 --> 00:58:43.930 align:middle line:90% It requires some work. 00:58:43.930 --> 00:58:47.400 align:middle line:84% I'll tell you why this idea is not trivially implemented, 00:58:47.400 --> 00:58:55.470 align:middle line:84% because when we do Fiat-Shamir, we say we start with a protocol. 00:58:55.470 --> 00:58:57.510 align:middle line:84% And now the question is, does there 00:58:57.510 --> 00:59:02.520 align:middle line:84% exist a hash of Fiat-Shamir hash family for which it's secure? 00:59:02.520 --> 00:59:06.880 align:middle line:84% Now, we saw with the protocol, this protocol can say, 00:59:06.880 --> 00:59:10.650 align:middle line:84% OK, alpha is hash key, for example. 00:59:10.650 --> 00:59:14.670 align:middle line:84% And then you accept, if you originally accepted, 00:59:14.670 --> 00:59:22.500 align:middle line:84% or if eval of hash key of alpha, which is also hash key, 00:59:22.500 --> 00:59:23.488 align:middle line:90% is equal to beta. 00:59:23.488 --> 00:59:25.530 align:middle line:84% Now, this will not happen, but in the Fiat-Shamir 00:59:25.530 --> 00:59:26.500 align:middle line:90% it will happen. 00:59:26.500 --> 00:59:28.500 align:middle line:84% I'm going to just send the Fiat-Shamir hash key. 00:59:28.500 --> 00:59:30.210 align:middle line:90% That's what I do. 00:59:30.210 --> 00:59:34.780 align:middle line:84% But then someone will say, OK, so you give me a protocol. 00:59:34.780 --> 00:59:36.840 align:middle line:84% What is the length of your alpha? 00:59:36.840 --> 00:59:38.320 align:middle line:90% It's lambda bits. 00:59:38.320 --> 00:59:42.220 align:middle line:84% I'm going to use a hash function that the hash key is longer. 00:59:42.220 --> 00:59:44.730 align:middle line:84% And now you can't send it because here I'm like, 00:59:44.730 --> 00:59:47.550 align:middle line:90% I'll send the hash key. 00:59:47.550 --> 00:59:51.160 align:middle line:84% So then you need to use a hash to squish this hash key in. 00:59:51.160 --> 00:59:53.250 align:middle line:90% It's more complicated. 00:59:53.250 --> 00:59:59.070 align:middle line:84% But the basic idea is, this does not 00:59:59.070 --> 01:00:05.160 align:middle line:84% work if somehow the verifier accepts you if you convinced him 01:00:05.160 --> 01:00:07.750 align:middle line:90% that you can predict his beta. 01:00:07.750 --> 01:00:16.020 align:middle line:84% That's really-- and so we can construct contrived protocols 01:00:16.020 --> 01:00:17.200 align:middle line:90% that achieve this. 01:00:17.200 --> 01:00:20.640 align:middle line:84% Or we can construct a very contrived hash function 01:00:20.640 --> 01:00:23.597 align:middle line:84% that do this weird game inside the hash function, 01:00:23.597 --> 01:00:25.680 align:middle line:84% like the hash function becomes trivial if you feed 01:00:25.680 --> 01:00:28.170 align:middle line:90% it something that kind of-- 01:00:28.170 --> 01:00:32.960 align:middle line:84% so it requires more work, but it's all very contrived. 01:00:32.960 --> 01:00:35.320 align:middle line:84% So I hope I convinced you by-- with these examples, 01:00:35.320 --> 01:00:37.730 align:middle line:84% the counterexamples are so contrived. 01:00:37.730 --> 01:00:41.470 align:middle line:84% So when you say, oh, we found that Fiat-Shamir is not secure, 01:00:41.470 --> 01:00:45.860 align:middle line:84% and, you show this example, the reaction should be, come on. 01:00:45.860 --> 01:00:48.400 align:middle line:90% Nobody uses these protocols. 01:00:48.400 --> 01:00:52.970 align:middle line:84% But what it does tell us, you can't apply Fiat-Shamir blind. 01:00:52.970 --> 01:00:55.360 align:middle line:84% What it does tell us is, for all of us 01:00:55.360 --> 01:00:58.460 align:middle line:84% who are obsessed with trying to prove the paradigm, 01:00:58.460 --> 01:01:02.560 align:middle line:84% there's no general proof because we have counterexamples. 01:01:02.560 --> 01:01:04.870 align:middle line:90% At least that. 01:01:04.870 --> 01:01:05.380 align:middle line:90% Question? 01:01:05.380 --> 01:01:08.380 align:middle line:84% AUDIENCE: Do you need to start with the protocol that's 01:01:08.380 --> 01:01:09.285 align:middle line:90% negligibly sound? 01:01:09.285 --> 01:01:10.160 align:middle line:90% YAEL T. KALAI: Great. 01:01:10.160 --> 01:01:11.860 align:middle line:90% Great question. 01:01:11.860 --> 01:01:13.765 align:middle line:90% That's my next one. 01:01:13.765 --> 01:01:14.265 align:middle line:90% Yeah. 01:01:14.265 --> 01:01:16.810 align:middle line:90% 01:01:16.810 --> 01:01:20.240 align:middle line:84% The answer is yes, but I'll talk about that next. 01:01:20.240 --> 01:01:22.240 align:middle line:84% The question was about negligible soundness, 01:01:22.240 --> 01:01:24.020 align:middle line:90% but we'll get to that next. 01:01:24.020 --> 01:01:29.020 align:middle line:90% So any questions though before-- 01:01:29.020 --> 01:01:29.780 align:middle line:90% OK. 01:01:29.780 --> 01:01:33.890 align:middle line:84% So but, still, people use the Fiat-Shamir paradigm. 01:01:33.890 --> 01:01:37.870 align:middle line:84% And there's a question of is it sound? 01:01:37.870 --> 01:01:40.930 align:middle line:84% For natural protocols, is it sound? 01:01:40.930 --> 01:01:43.960 align:middle line:84% And the answer is, actually, it would have been nice 01:01:43.960 --> 01:01:46.030 align:middle line:84% if we can come up with nice protocols 01:01:46.030 --> 01:01:49.910 align:middle line:84% and say, at least a large class of protocols, and say, yeah, 01:01:49.910 --> 01:01:52.580 align:middle line:84% if you use this hash function, this specific hash function, 01:01:52.580 --> 01:01:54.100 align:middle line:84% which we know is collision-resistant 01:01:54.100 --> 01:01:56.450 align:middle line:84% under discrete log or under some other assumption, 01:01:56.450 --> 01:01:57.635 align:middle line:90% then your scheme is sound. 01:01:57.635 --> 01:01:58.635 align:middle line:90% That would be very nice. 01:01:58.635 --> 01:02:01.360 align:middle line:90% 01:02:01.360 --> 01:02:04.540 align:middle line:84% We're still not there yet, but we made a lot of progress 01:02:04.540 --> 01:02:05.410 align:middle line:90% in recent years. 01:02:05.410 --> 01:02:07.160 align:middle line:84% And I want to tell you about the progress. 01:02:07.160 --> 01:02:15.790 align:middle line:84% But before that, the first kind of way 01:02:15.790 --> 01:02:19.150 align:middle line:84% we tried to analyze-- so the Fiat-Shamir gained popularity 01:02:19.150 --> 01:02:20.300 align:middle line:90% very quickly. 01:02:20.300 --> 01:02:24.310 align:middle line:84% And because it's so simple and so efficient, 01:02:24.310 --> 01:02:26.390 align:middle line:90% it became very, very popular. 01:02:26.390 --> 01:02:30.185 align:middle line:84% And people really wanted to understand its security. 01:02:30.185 --> 01:02:30.685 align:middle line:90% Is it sound? 01:02:30.685 --> 01:02:32.560 align:middle line:90% Is it not sound? 01:02:32.560 --> 01:02:36.880 align:middle line:84% And then in '93, Bellare and Rogaway 01:02:36.880 --> 01:02:40.755 align:middle line:84% introduced an ideal model called the Random Oracle Model. 01:02:40.755 --> 01:02:55.150 align:middle line:90% 01:02:55.150 --> 01:02:58.870 align:middle line:84% And this model said, you know what? 01:02:58.870 --> 01:03:02.590 align:middle line:84% By the way, this was before we had any counterexamples. 01:03:02.590 --> 01:03:06.250 align:middle line:84% This model was introduced by Bellare and Rogaway 01:03:06.250 --> 01:03:11.590 align:middle line:90% in, I believe, '93. 01:03:11.590 --> 01:03:13.660 align:middle line:84% This was before we knew any counterexamples 01:03:13.660 --> 01:03:15.020 align:middle line:90% for the paradigm. 01:03:15.020 --> 01:03:18.910 align:middle line:84% And they-- I mean, except for some, 01:03:18.910 --> 01:03:22.520 align:middle line:84% which goes to your question, Leo, but I'm going to get to it. 01:03:22.520 --> 01:03:25.780 align:middle line:84% And they wanted to ask, can we prove security 01:03:25.780 --> 01:03:30.360 align:middle line:90% of the Fiat-Shamir-- 01:03:30.360 --> 01:03:32.070 align:middle line:84% what do we need about the hash function? 01:03:32.070 --> 01:03:34.153 align:middle line:84% What properties do we need about the hash function 01:03:34.153 --> 01:03:34.950 align:middle line:90% to prove security? 01:03:34.950 --> 01:03:37.230 align:middle line:84% And the first property they said, you know what? 01:03:37.230 --> 01:03:41.330 align:middle line:84% What if the hash function was completely random? 01:03:41.330 --> 01:03:43.040 align:middle line:84% So when you use Fiat-Shamir, we use 01:03:43.040 --> 01:03:45.665 align:middle line:84% a specific-- there's a circuit that computes the hash function. 01:03:45.665 --> 01:03:48.080 align:middle line:84% It's like a Turing machine, a polynomial time Turing 01:03:48.080 --> 01:03:49.580 align:middle line:84% machine or a polynomial size circuit 01:03:49.580 --> 01:03:51.140 align:middle line:90% takes a hash key and, OK. 01:03:51.140 --> 01:03:52.140 align:middle line:90% They say, you know what? 01:03:52.140 --> 01:03:55.490 align:middle line:84% What if the hash function is completely random? 01:03:55.490 --> 01:04:01.160 align:middle line:84% So the Random Oracle Model says, suppose 01:04:01.160 --> 01:04:14.870 align:middle line:84% we apply Fiat-Shamir paradigm with truly random function 01:04:14.870 --> 01:04:18.630 align:middle line:84% H. So this is completely, completely random. 01:04:18.630 --> 01:04:20.660 align:middle line:84% So what do I mean by completely random? 01:04:20.660 --> 01:04:30.800 align:middle line:84% So now, I guess, let me, instead of choosing a function 01:04:30.800 --> 01:04:37.080 align:middle line:84% from a family, we don't choose a function, and we just say, 01:04:37.080 --> 01:04:39.450 align:middle line:84% suppose they have a truly random-- 01:04:39.450 --> 01:04:41.450 align:middle line:84% they have access to a-- both of them-- 01:04:41.450 --> 01:04:44.510 align:middle line:84% to a truly, truly random function. 01:04:44.510 --> 01:04:45.780 align:middle line:90% And they can ask. 01:04:45.780 --> 01:04:49.500 align:middle line:84% So when the prover computes alpha, 01:04:49.500 --> 01:04:51.800 align:middle line:84% he asks-- he has Oracle access to this function. 01:04:51.800 --> 01:04:54.320 align:middle line:84% And he tells the function, give me 01:04:54.320 --> 01:04:58.950 align:middle line:84% the function applied to x and alpha, and he gets back beta. 01:04:58.950 --> 01:05:03.300 align:middle line:84% And every time this hash, this Oracle, he gets a query, 01:05:03.300 --> 01:05:05.060 align:middle line:84% he chooses a completely random-- so 01:05:05.060 --> 01:05:09.080 align:middle line:84% think of this as a database of all poly of size 2 01:05:09.080 --> 01:05:12.740 align:middle line:84% to the lambda of all the-- just random, random elements. 01:05:12.740 --> 01:05:16.100 align:middle line:84% So really, really truly random function. 01:05:16.100 --> 01:05:19.950 align:middle line:84% So now the question was, OK, if this is truly random, 01:05:19.950 --> 01:05:21.380 align:middle line:90% now can we get security? 01:05:21.380 --> 01:05:24.000 align:middle line:90% At least, that's the minimum. 01:05:24.000 --> 01:05:27.530 align:middle line:84% And moreover, it seemed like the answer should be yes because, 01:05:27.530 --> 01:05:31.530 align:middle line:84% in some sense, what was their intuition? 01:05:31.530 --> 01:05:33.860 align:middle line:84% The intuition is, what does it matter 01:05:33.860 --> 01:05:38.180 align:middle line:84% if you're talking to a verifier that gives you random queries 01:05:38.180 --> 01:05:41.130 align:middle line:84% or you're talking to, in terms of the prover. 01:05:41.130 --> 01:05:42.810 align:middle line:84% So the prover is trying to cheat. 01:05:42.810 --> 01:05:44.900 align:middle line:84% What does it matter if he's talking to a verifier 01:05:44.900 --> 01:05:47.540 align:middle line:84% to give him random betas, or he's 01:05:47.540 --> 01:05:51.270 align:middle line:84% talking to a random function that gives him random betas? 01:05:51.270 --> 01:05:52.710 align:middle line:90% Both of them give random betas. 01:05:52.710 --> 01:05:54.350 align:middle line:90% What's the difference? 01:05:54.350 --> 01:05:58.500 align:middle line:84% So it should at least be secure in the Random Oracle Model. 01:05:58.500 --> 01:06:01.910 align:middle line:90% Let's first establish that. 01:06:01.910 --> 01:06:04.055 align:middle line:84% So is it secure in the Random Oracle Model. 01:06:04.055 --> 01:06:04.555 align:middle line:90% No. 01:06:04.555 --> 01:06:07.310 align:middle line:90% 01:06:07.310 --> 01:06:09.622 align:middle line:90% And this goes to Leo's question. 01:06:09.622 --> 01:06:12.080 align:middle line:84% And I'm going to tell you why it's not secure in the Random 01:06:12.080 --> 01:06:12.990 align:middle line:90% Oracle Model. 01:06:12.990 --> 01:06:20.270 align:middle line:84% And actually, let me take a little detour and tell you-- 01:06:20.270 --> 01:06:23.030 align:middle line:84% I'll show why it's not secure in the Random Oracle 01:06:23.030 --> 01:06:26.220 align:middle line:90% Model via a little protocol. 01:06:26.220 --> 01:06:29.720 align:middle line:84% This protocol actually is going to be useful because, actually, 01:06:29.720 --> 01:06:31.880 align:middle line:84% later, we will show that the Fiat-Shamir 01:06:31.880 --> 01:06:33.510 align:middle line:90% is sound for this protocol. 01:06:33.510 --> 01:06:34.470 align:middle line:90% It's kind of weird. 01:06:34.470 --> 01:06:37.230 align:middle line:84% But let's-- this protocol, by the way, 01:06:37.230 --> 01:06:39.410 align:middle line:90% is very important protocol. 01:06:39.410 --> 01:06:44.580 align:middle line:84% So let me quickly do-- let me do a little detour. 01:06:44.580 --> 01:06:46.530 align:middle line:84% I think it's a really interesting detour. 01:06:46.530 --> 01:06:48.800 align:middle line:90% So I hope you enjoy it. 01:06:48.800 --> 01:06:52.260 align:middle line:84% It takes us a little bit into the land of cryptography, 01:06:52.260 --> 01:06:53.440 align:middle line:90% but not too bad-- 01:06:53.440 --> 01:06:56.420 align:middle line:90% 01:06:56.420 --> 01:06:58.410 align:middle line:84% a little further than we went so far. 01:06:58.410 --> 01:07:02.810 align:middle line:84% So far we just talked about hash functions. 01:07:02.810 --> 01:07:08.240 align:middle line:84% So what I'm going to say now is going 01:07:08.240 --> 01:07:10.310 align:middle line:84% to be a little bit of a high level. 01:07:10.310 --> 01:07:12.950 align:middle line:90% 01:07:12.950 --> 01:07:18.470 align:middle line:84% So a protocol that I want to talk about 01:07:18.470 --> 01:07:20.940 align:middle line:84% is actually a zero knowledge protocol. 01:07:20.940 --> 01:07:25.170 align:middle line:84% So, so far, we just talked about verification, verification, 01:07:25.170 --> 01:07:27.720 align:middle line:90% succinctness, and efficiency. 01:07:27.720 --> 01:07:31.140 align:middle line:84% But, as I mentioned, interactive protocols 01:07:31.140 --> 01:07:34.170 align:middle line:84% were actually invented for the sake of zero knowledge. 01:07:34.170 --> 01:07:35.530 align:middle line:90% So what was the goal? 01:07:35.530 --> 01:07:39.058 align:middle line:84% The goal was, forget about succinctness now. 01:07:39.058 --> 01:07:40.600 align:middle line:84% It was not at all about succinctness. 01:07:40.600 --> 01:07:44.980 align:middle line:84% All we wanted is a prover that has, let's say, 01:07:44.980 --> 01:07:46.580 align:middle line:90% a witness for some-- 01:07:46.580 --> 01:07:48.030 align:middle line:90% there's some language. 01:07:48.030 --> 01:07:50.160 align:middle line:84% And let's say, the language we're 01:07:50.160 --> 01:07:53.230 align:middle line:84% going to be interested for today, just as an example, 01:07:53.230 --> 01:07:55.640 align:middle line:84% is the language of Hamiltonian cycle. 01:07:55.640 --> 01:07:58.800 align:middle line:90% 01:07:58.800 --> 01:08:00.070 align:middle line:90% That's just an example. 01:08:00.070 --> 01:08:03.630 align:middle line:84% So this language consists of graphs. 01:08:03.630 --> 01:08:06.850 align:middle line:84% So this is the language that consists of all graphs. 01:08:06.850 --> 01:08:10.650 align:middle line:84% Graph is just consists of nodes and edges 01:08:10.650 --> 01:08:14.970 align:middle line:84% such that this graph has a Hamiltonian cycle such 01:08:14.970 --> 01:08:23.439 align:middle line:90% that G has a Hamiltonian cycle. 01:08:23.439 --> 01:08:29.640 align:middle line:84% What this means is just, you can just-- 01:08:29.640 --> 01:08:34.450 align:middle line:84% there's a kind of a cycle of all the nodes. 01:08:34.450 --> 01:08:36.640 align:middle line:84% So it means that there's a cycle of all the nodes. 01:08:36.640 --> 01:08:43.920 align:middle line:84% So let's say you start with node i1, i2, up to i n, and then go-- 01:08:43.920 --> 01:08:45.540 align:middle line:84% up to i n so that there's an edge 01:08:45.540 --> 01:08:50.220 align:middle line:84% here, edge, edge, edge, edge, edge, and edge all the way back. 01:08:50.220 --> 01:08:57.029 align:middle line:84% That means, if you can-- if there is some such a setting 01:08:57.029 --> 01:09:00.149 align:middle line:84% of the nodes for which you can set them in a way 01:09:00.149 --> 01:09:02.680 align:middle line:84% that there's edges that complete a cycle, 01:09:02.680 --> 01:09:05.970 align:middle line:84% then we say the graph has a Hamiltonian cycle. 01:09:05.970 --> 01:09:09.100 align:middle line:90% This language is NP complete. 01:09:09.100 --> 01:09:13.090 align:middle line:84% Now, so now going back, what is the zero knowledge proof? 01:09:13.090 --> 01:09:14.760 align:middle line:84% A zero knowledge proof is a way I 01:09:14.760 --> 01:09:19.490 align:middle line:84% want to convince you that a graph G has a Hamiltonian cycle. 01:09:19.490 --> 01:09:21.240 align:middle line:84% Now, I can give you the Hamiltonian cycle. 01:09:21.240 --> 01:09:22.170 align:middle line:90% I can give you-- see? 01:09:22.170 --> 01:09:23.170 align:middle line:90% Here's the nodes. 01:09:23.170 --> 01:09:24.990 align:middle line:84% You can look, there's a cycle there. 01:09:24.990 --> 01:09:27.279 align:middle line:84% But I don't want to give you any information. 01:09:27.279 --> 01:09:29.770 align:middle line:84% I don't want you to learn anything. 01:09:29.770 --> 01:09:31.835 align:middle line:84% I don't want you to find the Hamiltonian cycle. 01:09:31.835 --> 01:09:33.460 align:middle line:84% I don't want to reveal any information, 01:09:33.460 --> 01:09:36.005 align:middle line:84% but I want to convince you that it has a Hamiltonian cycle. 01:09:36.005 --> 01:09:39.270 align:middle line:90% 01:09:39.270 --> 01:09:41.189 align:middle line:90% How do I do that? 01:09:41.189 --> 01:09:45.010 align:middle line:84% So this kind of-- so there's a celebrated result. 01:09:45.010 --> 01:09:46.800 align:middle line:84% It started with Goldwasser, Micali, 01:09:46.800 --> 01:09:51.300 align:middle line:84% and Markov in the mid '80s and where they defined this notion 01:09:51.300 --> 01:09:54.340 align:middle line:84% of zero knowledge and constructed some protocols. 01:09:54.340 --> 01:10:00.300 align:middle line:84% But later, very shortly later, by Goldreich, Micali, 01:10:00.300 --> 01:10:04.740 align:middle line:84% and Wigderson showed that, actually, any PNP language 01:10:04.740 --> 01:10:07.750 align:middle line:90% has a zero knowledge proof. 01:10:07.750 --> 01:10:10.140 align:middle line:84% Let me give you one specific zero knowledge 01:10:10.140 --> 01:10:13.620 align:middle line:84% proof for the Hamiltonian cycle language. 01:10:13.620 --> 01:10:16.080 align:middle line:90% And this is due to Blum. 01:10:16.080 --> 01:10:18.260 align:middle line:90% So I'll show you the proof. 01:10:18.260 --> 01:10:19.810 align:middle line:90% It's very, very nice. 01:10:19.810 --> 01:10:23.920 align:middle line:84% And it's going to be useful for us to show why the Random Oracle 01:10:23.920 --> 01:10:26.218 align:middle line:84% Model fails, and then also to show the security 01:10:26.218 --> 01:10:27.010 align:middle line:90% of the Fiat-Shamir. 01:10:27.010 --> 01:10:30.520 align:middle line:84% So this is actually-- we'll get back to this protocol. 01:10:30.520 --> 01:10:33.460 align:middle line:90% So what is this protocol? 01:10:33.460 --> 01:10:35.740 align:middle line:90% There's a prover and a verifier. 01:10:35.740 --> 01:10:37.690 align:middle line:90% The idea is the following. 01:10:37.690 --> 01:10:44.650 align:middle line:84% The prover will-- he knows-- he will first-- he has a G. 01:10:44.650 --> 01:10:47.530 align:middle line:84% The first thing he's going to permute-- 01:10:47.530 --> 01:10:49.910 align:middle line:90% completely permute the nodes. 01:10:49.910 --> 01:10:52.310 align:middle line:84% So he's going to choose a random permutation pi. 01:10:52.310 --> 01:10:55.150 align:middle line:84% Let's say n is the number denoted 01:10:55.150 --> 01:10:58.960 align:middle line:84% by n, the number of vertices in G. 01:10:58.960 --> 01:11:06.100 align:middle line:84% He's going to choose a random permutation of the nodes. 01:11:06.100 --> 01:11:08.780 align:middle line:84% Now he has the permuted graph in his head. 01:11:08.780 --> 01:11:12.670 align:middle line:90% So he has pi of G in his head. 01:11:12.670 --> 01:11:16.030 align:middle line:84% Now this, it has, this pi of G has a Hamiltonian cycle 01:11:16.030 --> 01:11:18.890 align:middle line:84% because G has and I just renamed the nodes. 01:11:18.890 --> 01:11:20.800 align:middle line:90% Now I'm going to-- 01:11:20.800 --> 01:11:24.860 align:middle line:84% I want to give you just this Hamiltonian cycle. 01:11:24.860 --> 01:11:27.440 align:middle line:84% So I want to give you the nodes here that form a Hamiltonian. 01:11:27.440 --> 01:11:29.450 align:middle line:90% So I want to give you-- 01:11:29.450 --> 01:11:31.660 align:middle line:84% I would like to give you the nodes that 01:11:31.660 --> 01:11:34.270 align:middle line:84% form the Hamiltonian, just the Hamiltonian cycle. 01:11:34.270 --> 01:11:37.900 align:middle line:84% But I can't give you, that will reveal information. 01:11:37.900 --> 01:11:39.650 align:middle line:90% So I don't want to do that. 01:11:39.650 --> 01:11:45.425 align:middle line:84% Instead, I'm going to give it to you in a safe, hidden. 01:11:45.425 --> 01:11:47.050 align:middle line:84% This is what's called, in cryptography, 01:11:47.050 --> 01:11:48.620 align:middle line:90% we call this commitment scheme. 01:11:48.620 --> 01:11:56.102 align:middle line:84% So I'm going to give you a commitment of the cycle C. 01:11:56.102 --> 01:12:01.316 align:middle line:84% So think of this, for all the possible edges, and grid 0, 0, 01:12:01.316 --> 01:12:03.840 align:middle line:84% 0, 0, only in the cycle I'm going to put 1. 01:12:03.840 --> 01:12:04.840 align:middle line:90% That's what I mean here. 01:12:04.840 --> 01:12:06.760 align:middle line:90% Because, so this is-- 01:12:06.760 --> 01:12:12.850 align:middle line:84% think of it as a matrix of n by n-- 01:12:12.850 --> 01:12:16.690 align:middle line:90% sorry, yeah, n by n. 01:12:16.690 --> 01:12:20.320 align:middle line:84% For any possible edge, for any possible nodes, i and j, 01:12:20.320 --> 01:12:23.710 align:middle line:84% I'm going to put 0, like there is no edge, only 01:12:23.710 --> 01:12:26.110 align:middle line:84% if it's in the cycle I'm going to put an edge there. 01:12:26.110 --> 01:12:26.890 align:middle line:90% Yeah. 01:12:26.890 --> 01:12:30.710 align:middle line:84% AUDIENCE: So a cycle is on the label of the permuted graph. 01:12:30.710 --> 01:12:34.210 align:middle line:84% YAEL T. KALAI: Exactly, on the permuted graph. 01:12:34.210 --> 01:12:37.510 align:middle line:84% The reason I permute the graph is to ensure zero knowledgeness. 01:12:37.510 --> 01:12:39.700 align:middle line:84% Even though when I send the commitment, 01:12:39.700 --> 01:12:41.230 align:middle line:90% really, think of it-- 01:12:41.230 --> 01:12:44.240 align:middle line:84% we're going to later talk about how to do this commitment. 01:12:44.240 --> 01:12:47.240 align:middle line:84% But for now, think of it, there's a safe. 01:12:47.240 --> 01:12:50.150 align:middle line:84% I'm putting my commitment inside the safe. 01:12:50.150 --> 01:12:52.640 align:middle line:84% I leave the key to myself and I give you this box. 01:12:52.640 --> 01:12:55.550 align:middle line:90% So you learn nothing. 01:12:55.550 --> 01:12:57.580 align:middle line:84% So here, really, you learn nothing. 01:12:57.580 --> 01:13:00.220 align:middle line:84% But now-- but you're not convinced either 01:13:00.220 --> 01:13:01.400 align:middle line:90% because you just got a safe. 01:13:01.400 --> 01:13:02.775 align:middle line:84% What are you going to do with it? 01:13:02.775 --> 01:13:05.440 align:middle line:84% So now here's how I'm going to convince you that, actually, 01:13:05.440 --> 01:13:10.000 align:middle line:84% this graph has a Hamiltonian cycle without leaking 01:13:10.000 --> 01:13:11.770 align:middle line:90% any information. 01:13:11.770 --> 01:13:15.540 align:middle line:84% So you, the verifier, you're going to give me a random bit 01:13:15.540 --> 01:13:23.630 align:middle line:84% B. This is going to be random, random bit. 01:13:23.630 --> 01:13:30.900 align:middle line:84% Now, if B is 0, I'm just going to open this. 01:13:30.900 --> 01:13:36.860 align:middle line:90% So if B is 0, if B is 0, open. 01:13:36.860 --> 01:13:38.570 align:middle line:90% I'm going to open the safe. 01:13:38.570 --> 01:13:40.430 align:middle line:84% And now you can see that what's sitting 01:13:40.430 --> 01:13:44.180 align:middle line:90% there is a Hamiltonian cycle. 01:13:44.180 --> 01:13:46.760 align:middle line:90% Now, what did you learn? 01:13:46.760 --> 01:13:50.250 align:middle line:84% Well, because I permuted, it's just a random cycle. 01:13:50.250 --> 01:13:52.580 align:middle line:84% Actually, it has nothing to do with the graph. 01:13:52.580 --> 01:13:57.920 align:middle line:84% I can even first just choose a random cycle, commit to it, 01:13:57.920 --> 01:14:01.940 align:middle line:84% and then post choose this permutation 01:14:01.940 --> 01:14:05.340 align:middle line:90% to align with this cycle. 01:14:05.340 --> 01:14:08.970 align:middle line:84% So really, because I chose a random permutation, 01:14:08.970 --> 01:14:11.182 align:middle line:90% it's just a random cycle. 01:14:11.182 --> 01:14:12.390 align:middle line:90% So you didn't learn anything. 01:14:12.390 --> 01:14:13.790 align:middle line:90% It's just a random cycle. 01:14:13.790 --> 01:14:16.580 align:middle line:84% You and yourself can put a random cycle in a safe. 01:14:16.580 --> 01:14:20.480 align:middle line:90% So really, no information. 01:14:20.480 --> 01:14:23.840 align:middle line:90% What if B equals 1? 01:14:23.840 --> 01:14:29.180 align:middle line:84% If B equals 1, I want to-- first I want to give you pi. 01:14:29.180 --> 01:14:30.240 align:middle line:90% So I give you pi. 01:14:30.240 --> 01:14:32.210 align:middle line:90% But now I can't open this. 01:14:32.210 --> 01:14:34.790 align:middle line:84% Because now, if you know pi, and you see the cycle, 01:14:34.790 --> 01:14:37.490 align:middle line:84% you know what my Hamiltonian cycle is. 01:14:37.490 --> 01:14:39.230 align:middle line:84% So what I'm going to do, I just want 01:14:39.230 --> 01:14:47.450 align:middle line:84% to convince you that this cycle only has 01:14:47.450 --> 01:14:50.720 align:middle line:90% edges that were in this graph. 01:14:50.720 --> 01:14:55.170 align:middle line:84% So I'm going to open only the non-edges. 01:14:55.170 --> 01:14:57.560 align:middle line:84% So instead of opening everything, 01:14:57.560 --> 01:15:09.590 align:middle line:84% I'm going to open non-edges in the permuted graph. 01:15:09.590 --> 01:15:13.860 align:middle line:84% So note, here we have-- so I have here-- 01:15:13.860 --> 01:15:16.770 align:middle line:84% so there's a question, how do I open? 01:15:16.770 --> 01:15:22.470 align:middle line:84% So think of it, I commit to n squared bits. 01:15:22.470 --> 01:15:26.550 align:middle line:84% For any possible ij, I have a bit saying, is it 0 or is it 1? 01:15:26.550 --> 01:15:28.380 align:middle line:84% Is there an edge or is it not an edge? 01:15:28.380 --> 01:15:31.940 align:middle line:84% Think of it as I'm giving you n squared safes. 01:15:31.940 --> 01:15:35.250 align:middle line:84% Now, if B is 0, I open all the safes. 01:15:35.250 --> 01:15:37.610 align:middle line:84% I open all the safes and you see, oh, there's 01:15:37.610 --> 01:15:39.620 align:middle line:90% only-- there's just a cycle. 01:15:39.620 --> 01:15:44.900 align:middle line:84% There's everything is 0 except for i1 and i2 are-- 01:15:44.900 --> 01:15:47.730 align:middle line:84% there's one, and then i2, i3, that's it. 01:15:47.730 --> 01:15:49.820 align:middle line:90% Everything else is 0. 01:15:49.820 --> 01:15:53.250 align:middle line:84% If you send me a 1, then I open something else. 01:15:53.250 --> 01:15:54.630 align:middle line:90% I don't open everything. 01:15:54.630 --> 01:15:55.770 align:middle line:90% The opposite. 01:15:55.770 --> 01:15:59.660 align:middle line:90% What I do is, I give you pi. 01:15:59.660 --> 01:16:06.890 align:middle line:84% And for every non-edge in pi, I open the non-edge safe 01:16:06.890 --> 01:16:10.020 align:middle line:90% and I show you, see, there's 0. 01:16:10.020 --> 01:16:14.950 align:middle line:84% So all the safes I opened are just going to be 0. 01:16:14.950 --> 01:16:16.450 align:middle line:84% So you really didn't learn anything. 01:16:16.450 --> 01:16:17.680 align:middle line:90% I just opened zeros. 01:16:17.680 --> 01:16:20.070 align:middle line:84% You can simulate that in your head. 01:16:20.070 --> 01:16:21.120 align:middle line:90% What do you learn? 01:16:21.120 --> 01:16:25.530 align:middle line:84% In some sense, you know that if you accept me, 01:16:25.530 --> 01:16:28.830 align:middle line:84% I'm going to open to just zeros there. 01:16:28.830 --> 01:16:30.700 align:middle line:84% And the pi doesn't reveal anything. 01:16:30.700 --> 01:16:34.350 align:middle line:90% It's just a random permutation. 01:16:34.350 --> 01:16:39.070 align:middle line:84% So note, you, the verifier, didn't learn anything. 01:16:39.070 --> 01:16:44.180 align:middle line:84% If you open to 0, if you send me 0, I just open random cycle. 01:16:44.180 --> 01:16:45.930 align:middle line:84% Has nothing to do with the graph, nothing, 01:16:45.930 --> 01:16:48.450 align:middle line:90% just random cycle. 01:16:48.450 --> 01:16:50.490 align:middle line:90% That's not helpful for you. 01:16:50.490 --> 01:16:55.320 align:middle line:84% If you open 1, I gave you completely random permutation. 01:16:55.320 --> 01:17:00.960 align:middle line:84% You know pi G on your own, and I opened to zeros. 01:17:00.960 --> 01:17:02.800 align:middle line:90% All the non-edges are open to 0. 01:17:02.800 --> 01:17:05.790 align:middle line:90% You learn nothing. 01:17:05.790 --> 01:17:12.240 align:middle line:84% Still, you are somewhat convinced that this protocol-- 01:17:12.240 --> 01:17:14.440 align:middle line:90% that the graph is Hamiltonian. 01:17:14.440 --> 01:17:17.130 align:middle line:84% Why are you somewhat convinced that there's 01:17:17.130 --> 01:17:18.340 align:middle line:90% a Hamiltonian cycle? 01:17:18.340 --> 01:17:19.990 align:middle line:90% Why are you somewhat convinced? 01:17:19.990 --> 01:17:23.790 align:middle line:84% Because if there is no Hamiltonian cycle in G, 01:17:23.790 --> 01:17:28.050 align:middle line:90% I cannot open to both 0 and 1. 01:17:28.050 --> 01:17:30.340 align:middle line:84% Why is it the case that I cannot open? 01:17:30.340 --> 01:17:32.160 align:middle line:90% Let's see. 01:17:32.160 --> 01:17:35.670 align:middle line:84% I'm achieving-- let's say the graph, is 01:17:35.670 --> 01:17:39.780 align:middle line:90% there is no Hamiltonian cycle. 01:17:39.780 --> 01:17:44.460 align:middle line:84% Now, I sent you these n squared safes. 01:17:44.460 --> 01:17:48.660 align:middle line:84% Case one, there's indeed only a Hamiltonian cycle there. 01:17:48.660 --> 01:17:52.050 align:middle line:84% Indeed, when you open all these n safes, what you see 01:17:52.050 --> 01:17:55.800 align:middle line:84% is everything is 0 except for Hamiltonian cycle. 01:17:55.800 --> 01:17:59.440 align:middle line:84% If that's not the case, I cannot open to 0. 01:17:59.440 --> 01:18:03.840 align:middle line:90% If I open to 0, you catch me. 01:18:03.840 --> 01:18:06.400 align:middle line:84% Now, suppose I did succeed in opening to 0. 01:18:06.400 --> 01:18:09.250 align:middle line:84% Namely, there's just a Hamiltonian cycle there. 01:18:09.250 --> 01:18:11.280 align:middle line:90% That's it. 01:18:11.280 --> 01:18:14.640 align:middle line:84% Then I claim there's no way I can open to 1. 01:18:14.640 --> 01:18:16.260 align:middle line:90% Why? 01:18:16.260 --> 01:18:18.660 align:middle line:84% If there is a Hamiltonian cycle there, 01:18:18.660 --> 01:18:23.280 align:middle line:84% I know the Hamiltonian cycle is not on the non-edges 01:18:23.280 --> 01:18:25.500 align:middle line:90% because the non-edges are 0. 01:18:25.500 --> 01:18:28.260 align:middle line:84% If I open on one, the non-edges are 0. 01:18:28.260 --> 01:18:30.070 align:middle line:84% So the Hamiltonian cycle is on the edges. 01:18:30.070 --> 01:18:31.625 align:middle line:84% But there is no Hamiltonian cycle. 01:18:31.625 --> 01:18:34.800 align:middle line:84% [LAUGHS] It can't be on the edges. 01:18:34.800 --> 01:18:38.700 align:middle line:84% So either-- I'm achieving prover-- either I can-- 01:18:38.700 --> 01:18:40.750 align:middle line:90% I may be able to open to 0. 01:18:40.750 --> 01:18:44.250 align:middle line:84% I may be able to open to 1, but I can't open to both. 01:18:44.250 --> 01:18:48.600 align:middle line:84% So with probability 1/2, you'll reject me. 01:18:48.600 --> 01:18:52.233 align:middle line:84% Half isn't that great, but it's something. 01:18:52.233 --> 01:18:54.150 align:middle line:84% So at least now we know, with probability 1/2, 01:18:54.150 --> 01:18:55.192 align:middle line:90% I'm going to be rejected. 01:18:55.192 --> 01:18:59.730 align:middle line:90% 01:18:59.730 --> 01:19:01.890 align:middle line:90% You like the detour? 01:19:01.890 --> 01:19:03.550 align:middle line:84% OK, let's go back to the random Oracle. 01:19:03.550 --> 01:19:04.830 align:middle line:90% But before-- yeah. 01:19:04.830 --> 01:19:07.330 align:middle line:84% AUDIENCE: So do you have to compute the whole graph, or just 01:19:07.330 --> 01:19:08.860 align:middle line:90% a cycle? 01:19:08.860 --> 01:19:11.350 align:middle line:84% YAEL T. KALAI: So what-- no, what I commit to is, 01:19:11.350 --> 01:19:14.980 align:middle line:84% actually, I have n squared commitments. 01:19:14.980 --> 01:19:19.600 align:middle line:84% Everything is 0 except for a random cycle. 01:19:19.600 --> 01:19:21.440 align:middle line:90% I do-- I only commit to zeros. 01:19:21.440 --> 01:19:23.840 align:middle line:84% Why is it important that I only commit to zeros? 01:19:23.840 --> 01:19:28.580 align:middle line:90% Because when I open-- ah, OK. 01:19:28.580 --> 01:19:32.200 align:middle line:84% I want to make sure that there's a cycle here. 01:19:32.200 --> 01:19:35.240 align:middle line:84% But when I open to 1, I don't want to reveal anything. 01:19:35.240 --> 01:19:37.120 align:middle line:84% And the way I don't reveal anything 01:19:37.120 --> 01:19:41.570 align:middle line:84% is I show that all the non-edges in pi, in pi of g, 01:19:41.570 --> 01:19:45.722 align:middle line:84% if you open them here, you'll get a 0. 01:19:45.722 --> 01:19:46.430 align:middle line:90% AUDIENCE: Oh, OK. 01:19:46.430 --> 01:19:47.330 align:middle line:90% So it's a matrix. 01:19:47.330 --> 01:19:49.930 align:middle line:84% So it already kind of has everything-- 01:19:49.930 --> 01:19:52.392 align:middle line:84% with the cycle, like outlining the cycle. 01:19:52.392 --> 01:19:53.350 align:middle line:90% YAEL T. KALAI: Exactly. 01:19:53.350 --> 01:19:53.920 align:middle line:90% Exactly. 01:19:53.920 --> 01:19:56.230 align:middle line:90% What I commit to is a matrix-- 01:19:56.230 --> 01:19:57.910 align:middle line:84% what I commit to is a matrix that 01:19:57.910 --> 01:20:00.350 align:middle line:84% only has a Hamiltonian cycle and that's it. 01:20:00.350 --> 01:20:03.640 align:middle line:90% Everything else is 0. 01:20:03.640 --> 01:20:04.300 align:middle line:90% Yeah. 01:20:04.300 --> 01:20:09.250 align:middle line:84% AUDIENCE: So in the second case, the verifier cannot use 01:20:09.250 --> 01:20:12.880 align:middle line:84% the permutation to figure out what edges are not 01:20:12.880 --> 01:20:14.920 align:middle line:84% in the Hamiltonian cycle for the original graph. 01:20:14.920 --> 01:20:15.795 align:middle line:90% YAEL T. KALAI: Right. 01:20:15.795 --> 01:20:18.050 align:middle line:84% So in the B equals 1 case you're talking about? 01:20:18.050 --> 01:20:18.550 align:middle line:90% Yeah. 01:20:18.550 --> 01:20:21.518 align:middle line:84% In the B equals 1 case, the verifier-- 01:20:21.518 --> 01:20:22.310 align:middle line:90% what does he learn? 01:20:22.310 --> 01:20:23.840 align:middle line:90% He learns pi, the permutation. 01:20:23.840 --> 01:20:25.960 align:middle line:84% That's just a random permutation. 01:20:25.960 --> 01:20:27.970 align:middle line:84% And then I'm just telling you, I'm 01:20:27.970 --> 01:20:29.748 align:middle line:84% reassuring you that I didn't lie. 01:20:29.748 --> 01:20:31.040 align:middle line:90% What do I mean by reassure you? 01:20:31.040 --> 01:20:33.887 align:middle line:84% I open-- everybody, you can compute pi G on your own. 01:20:33.887 --> 01:20:34.720 align:middle line:90% That's not a secret. 01:20:34.720 --> 01:20:36.050 align:middle line:90% G is given, pi is given. 01:20:36.050 --> 01:20:38.150 align:middle line:84% You can find G. You see all the non-edges. 01:20:38.150 --> 01:20:41.230 align:middle line:84% That's not a-- and all the non-edges, 01:20:41.230 --> 01:20:44.040 align:middle line:84% I'm going to open only the non-edges and show you zeros. 01:20:44.040 --> 01:20:46.600 align:middle line:90% 01:20:46.600 --> 01:20:51.130 align:middle line:84% Because the point is, if I was honest, what I should do, 01:20:51.130 --> 01:20:54.320 align:middle line:84% is put ones only on edges, and not only on edges, 01:20:54.320 --> 01:20:56.410 align:middle line:84% only on the Hamiltonian and the edges that 01:20:56.410 --> 01:20:58.480 align:middle line:90% form a Hamiltonian cycle. 01:20:58.480 --> 01:21:00.320 align:middle line:84% That's what I should do if I'm honest. 01:21:00.320 --> 01:21:02.883 align:middle line:84% And what I show you, I don't show you 01:21:02.883 --> 01:21:04.550 align:middle line:84% that because that will give information. 01:21:04.550 --> 01:21:05.930 align:middle line:90% But at least what I show you. 01:21:05.930 --> 01:21:09.760 align:middle line:84% Then all the non-edges here, I committed to 0. 01:21:09.760 --> 01:21:12.850 align:middle line:84% And that gives you no information. 01:21:12.850 --> 01:21:18.260 align:middle line:84% But if, indeed, the non-edges are 0, 01:21:18.260 --> 01:21:20.500 align:middle line:84% and there's a Hamiltonian cycle, that 01:21:20.500 --> 01:21:23.240 align:middle line:84% means the Hamiltonian cycle must be edges. 01:21:23.240 --> 01:21:26.680 align:middle line:84% And then it means that pi of G has a Hamiltonian cycle. 01:21:26.680 --> 01:21:27.740 align:middle line:90% And that can't be. 01:21:27.740 --> 01:21:29.710 align:middle line:84% If G doesn't have a Hamiltonian cycle, pi of G 01:21:29.710 --> 01:21:31.220 align:middle line:84% doesn't have a Hamiltonian cycle. 01:21:31.220 --> 01:21:35.860 align:middle line:84% And that's why I can't succeed in convincing you 01:21:35.860 --> 01:21:37.700 align:middle line:90% in answering both questions. 01:21:37.700 --> 01:21:41.200 align:middle line:90% 01:21:41.200 --> 01:21:41.950 align:middle line:90% Yeah. 01:21:41.950 --> 01:21:44.020 align:middle line:84% AUDIENCE: Is there a formal way to say what 01:21:44.020 --> 01:21:45.680 align:middle line:90% it means to be zero knowledge? 01:21:45.680 --> 01:21:46.930 align:middle line:90% Like, [INAUDIBLE]. 01:21:46.930 --> 01:21:48.796 align:middle line:90% YAEL T. KALAI: Yeah, good. 01:21:48.796 --> 01:21:49.610 align:middle line:90% Good, good, good. 01:21:49.610 --> 01:21:50.330 align:middle line:90% So the question. 01:21:50.330 --> 01:21:52.663 align:middle line:84% Yeah, actually, I planned not to go into the definition, 01:21:52.663 --> 01:21:55.810 align:middle line:84% but it's so beautiful, so I will. 01:21:55.810 --> 01:21:56.360 align:middle line:90% Yeah. 01:21:56.360 --> 01:22:00.200 align:middle line:84% So the question was, what is the definition 01:22:00.200 --> 01:22:01.850 align:middle line:90% actually of zero knowledge? 01:22:01.850 --> 01:22:03.830 align:middle line:84% And the definition of zero knowledge 01:22:03.830 --> 01:22:08.220 align:middle line:84% says that, what does it mean, you don't learn anything. 01:22:08.220 --> 01:22:11.040 align:middle line:90% So the definition says that-- 01:22:11.040 --> 01:22:16.070 align:middle line:84% so this is the definition of zero knowledge. 01:22:16.070 --> 01:22:21.770 align:middle line:84% What it says is, the verifier-- actually, it says, 01:22:21.770 --> 01:22:22.530 align:middle line:90% it's stronger. 01:22:22.530 --> 01:22:26.480 align:middle line:84% It says, for every verifier, not just the honest verifier, 01:22:26.480 --> 01:22:27.560 align:middle line:90% even malicious verifier. 01:22:27.560 --> 01:22:30.140 align:middle line:84% You can talk about honest verifier zero knowledge, 01:22:30.140 --> 01:22:33.020 align:middle line:84% the honest verifier, who just does what it should do 01:22:33.020 --> 01:22:35.670 align:middle line:84% and just listens, doesn't learn anything. 01:22:35.670 --> 01:22:38.160 align:middle line:84% But actually, there's a stronger notion of malicious. 01:22:38.160 --> 01:22:44.150 align:middle line:84% So let's say even for a malicious verifier, 01:22:44.150 --> 01:22:46.400 align:middle line:90% you want to say what he learned. 01:22:46.400 --> 01:22:50.600 align:middle line:84% He could have simulated on his own. 01:22:50.600 --> 01:22:53.210 align:middle line:84% So the definition says, for every-- 01:22:53.210 --> 01:22:57.796 align:middle line:84% so you-- OK, for every verifier, if you look at the transcript-- 01:22:57.796 --> 01:23:01.610 align:middle line:90% 01:23:01.610 --> 01:23:07.740 align:middle line:84% and for every x in l, for every x, 01:23:07.740 --> 01:23:10.400 align:middle line:84% if you look at the transcript between the honest prover 01:23:10.400 --> 01:23:15.150 align:middle line:84% and the verifier, the prover has a witness, 01:23:15.150 --> 01:23:17.810 align:middle line:90% but the verifier doesn't. 01:23:17.810 --> 01:23:19.910 align:middle line:84% What he learned from this transcript or what 01:23:19.910 --> 01:23:21.000 align:middle line:90% the verifier maybe-- 01:23:21.000 --> 01:23:22.530 align:middle line:84% sorry, let me write it differently. 01:23:22.530 --> 01:23:29.450 align:middle line:84% Let me say the view of v star while interacting 01:23:29.450 --> 01:23:34.880 align:middle line:90% with p and input x. 01:23:34.880 --> 01:23:42.190 align:middle line:84% So whatever V star learned, he could have simulated on his own. 01:23:42.190 --> 01:23:46.850 align:middle line:90% 01:23:46.850 --> 01:23:52.610 align:middle line:84% So it says there exists a simulator. 01:23:52.610 --> 01:23:57.855 align:middle line:84% And this is efficient, an efficient simulator, 01:23:57.855 --> 01:24:04.610 align:middle line:84% such that the simulator efficiently can 01:24:04.610 --> 01:24:09.512 align:middle line:84% generate this transcript on its own if he has V star. 01:24:09.512 --> 01:24:10.970 align:middle line:84% He needs V star because, of course, 01:24:10.970 --> 01:24:13.280 align:middle line:84% V star depends what he sends and so on. 01:24:13.280 --> 01:24:16.610 align:middle line:84% But he could generate it on his own. 01:24:16.610 --> 01:24:17.582 align:middle line:90% Yeah. 01:24:17.582 --> 01:24:19.040 align:middle line:84% AUDIENCE: Can the stimulator depend 01:24:19.040 --> 01:24:21.010 align:middle line:84% on V star if we're then using [INAUDIBLE]? 01:24:21.010 --> 01:24:23.100 align:middle line:84% So then, is it the same simulator for everyone? 01:24:23.100 --> 01:24:23.610 align:middle line:90% Or is it-- 01:24:23.610 --> 01:24:25.527 align:middle line:84% YAEL T. KALAI: Oh, my God, there are so many-- 01:24:25.527 --> 01:24:28.890 align:middle line:84% OK, there's so, so many notions of zero knowledge. 01:24:28.890 --> 01:24:30.897 align:middle line:90% So for example, first of all-- 01:24:30.897 --> 01:24:31.980 align:middle line:90% I'll answer your question. 01:24:31.980 --> 01:24:35.150 align:middle line:84% The question was, is simulator only gets V star 01:24:35.150 --> 01:24:36.360 align:middle line:90% as Oracle access? 01:24:36.360 --> 01:24:37.440 align:middle line:90% Does it get an input? 01:24:37.440 --> 01:24:38.700 align:middle line:90% Is it universal? 01:24:38.700 --> 01:24:41.810 align:middle line:84% Is it for there exists a simulator for every V star, 01:24:41.810 --> 01:24:44.300 align:middle line:84% or is it for every V star there is a simulator? 01:24:44.300 --> 01:24:46.140 align:middle line:90% Moreover, let me continue. 01:24:46.140 --> 01:24:47.730 align:middle line:90% Is V star all-powerful? 01:24:47.730 --> 01:24:50.950 align:middle line:84% Is V star supposed to be PPT or a poly size? 01:24:50.950 --> 01:24:55.850 align:middle line:90% 01:24:55.850 --> 01:24:59.090 align:middle line:84% And the answer is, there's many definitions. 01:24:59.090 --> 01:25:04.400 align:middle line:90% But yeah. 01:25:04.400 --> 01:25:14.810 align:middle line:84% So originally, all the protocols we had used the verifier 01:25:14.810 --> 01:25:17.660 align:middle line:90% as a black box. 01:25:17.660 --> 01:25:22.130 align:middle line:84% However, in 2001, I think was it, 01:25:22.130 --> 01:25:27.003 align:middle line:84% Boaz Barak was the first to construct non-black box 01:25:27.003 --> 01:25:28.670 align:middle line:84% zero knowledge, where the simulator used 01:25:28.670 --> 01:25:30.210 align:middle line:90% verifier is a non-black box. 01:25:30.210 --> 01:25:33.300 align:middle line:84% And it was a really breakthrough result 01:25:33.300 --> 01:25:38.450 align:middle line:84% because what he managed to get is a new zero knowledge proof 01:25:38.450 --> 01:25:39.960 align:middle line:90% that we didn't know of before. 01:25:39.960 --> 01:25:42.560 align:middle line:90% It was kind of constant round. 01:25:42.560 --> 01:25:45.930 align:middle line:84% Now you can say, wait, this is also constant round. 01:25:45.930 --> 01:25:47.870 align:middle line:84% What do you mean we didn't know before? 01:25:47.870 --> 01:25:49.450 align:middle line:90% But this is only soundness half. 01:25:49.450 --> 01:25:52.730 align:middle line:90% 01:25:52.730 --> 01:25:55.980 align:middle line:84% Turns out, if you want negligible soundness, 01:25:55.980 --> 01:25:58.860 align:middle line:84% you need to repeat this protocol sequentially. 01:25:58.860 --> 01:26:03.600 align:middle line:84% If you repeat it in parallel, it's 01:26:03.600 --> 01:26:05.430 align:middle line:90% not necessarily zero knowledge. 01:26:05.430 --> 01:26:08.530 align:middle line:84% Actually, yeah, this one actually is not zero knowledge 01:26:08.530 --> 01:26:09.870 align:middle line:90% if you repeat it in parallel. 01:26:09.870 --> 01:26:11.850 align:middle line:90% We'll talk about that. 01:26:11.850 --> 01:26:15.300 align:middle line:84% And so, using non-black techniques, 01:26:15.300 --> 01:26:18.600 align:middle line:84% he managed to show the first kind of constant round 01:26:18.600 --> 01:26:21.280 align:middle line:84% zero knowledge-- public coin zero knowledge proof. 01:26:21.280 --> 01:26:30.140 align:middle line:84% So there's many, many variants is the point. 01:26:30.140 --> 01:26:32.760 align:middle line:90% 01:26:32.760 --> 01:26:37.410 align:middle line:84% But this is a common variant to think about. 01:26:37.410 --> 01:26:40.660 align:middle line:84% And also, so this is kind of poly size, 01:26:40.660 --> 01:26:42.820 align:middle line:90% or V can have auxiliary input. 01:26:42.820 --> 01:26:45.970 align:middle line:84% So for every x in [INAUDIBLE] or V star is poly size. 01:26:45.970 --> 01:26:50.940 align:middle line:84% So we can have auxiliary information about the x, 01:26:50.940 --> 01:26:53.200 align:middle line:84% even if it has auxiliary information about x, still, 01:26:53.200 --> 01:26:54.580 align:middle line:90% so V star is-- 01:26:54.580 --> 01:26:58.860 align:middle line:84% may have auxiliary information about x, still 01:26:58.860 --> 01:27:02.100 align:middle line:90% the two are indistinguishable. 01:27:02.100 --> 01:27:03.870 align:middle line:90% Yeah. 01:27:03.870 --> 01:27:10.920 align:middle line:84% AUDIENCE: What if the prover for the commitment where he created 01:27:10.920 --> 01:27:13.380 align:middle line:84% matrices that ensure that there's 01:27:13.380 --> 01:27:16.500 align:middle line:84% a cycle in that matrix that commits to that? 01:27:16.500 --> 01:27:19.260 align:middle line:84% YAEL T. KALAI: Wait, again, what if the prover 01:27:19.260 --> 01:27:21.060 align:middle line:90% commits to a cycle or no? 01:27:21.060 --> 01:27:23.880 align:middle line:84% AUDIENCE: He commits to a cycle, but the cycle is not necessarily 01:27:23.880 --> 01:27:25.207 align:middle line:90% with-- 01:27:25.207 --> 01:27:26.040 align:middle line:90% [INTERPOSING VOICES] 01:27:26.040 --> 01:27:27.780 align:middle line:84% YAEL T. KALAI: It has nothing to do with G. Just 01:27:27.780 --> 01:27:28.695 align:middle line:90% commit to any cycle. 01:27:28.695 --> 01:27:29.010 align:middle line:90% AUDIENCE: Yes. 01:27:29.010 --> 01:27:29.730 align:middle line:90% YAEL T. KALAI: OK, good. 01:27:29.730 --> 01:27:30.470 align:middle line:90% AUDIENCE: He commits to a cycle. 01:27:30.470 --> 01:27:30.730 align:middle line:90% YAEL T. KALAI: OK. 01:27:30.730 --> 01:27:31.647 align:middle line:90% AUDIENCE: [INAUDIBLE]. 01:27:31.647 --> 01:27:35.800 align:middle line:84% And he'll be able to [INAUDIBLE] it's a 0, right? 01:27:35.800 --> 01:27:37.800 align:middle line:84% YAEL T. KALAI: Yeah, he'll be able to-- exactly. 01:27:37.800 --> 01:27:39.175 align:middle line:84% He'll be able to answer 0, but he 01:27:39.175 --> 01:27:44.250 align:middle line:84% won't be able to answer 1 because that cycle must 01:27:44.250 --> 01:27:46.530 align:middle line:90% touch an edge. 01:27:46.530 --> 01:27:50.850 align:middle line:84% Because-- sorry, that cycle must touch a non-edge. 01:27:50.850 --> 01:27:55.960 align:middle line:84% Because if it only touched edges, there is no cycle. 01:27:55.960 --> 01:27:58.540 align:middle line:90% So that cycle, you give your pi. 01:27:58.540 --> 01:28:00.390 align:middle line:84% Now, the prover can-- the cheating prover 01:28:00.390 --> 01:28:02.710 align:middle line:90% can give whatever pi he wants. 01:28:02.710 --> 01:28:06.940 align:middle line:84% But the point is that the graph, the permuted graph, 01:28:06.940 --> 01:28:09.793 align:middle line:84% doesn't have a Hamiltonian cycle, 01:28:09.793 --> 01:28:11.710 align:middle line:84% because if G doesn't have a Hamiltonian cycle, 01:28:11.710 --> 01:28:14.370 align:middle line:84% the permuted G also doesn't have a Hamiltonian cycle. 01:28:14.370 --> 01:28:17.670 align:middle line:84% So this graph doesn't have a Hamiltonian cycle, and that 01:28:17.670 --> 01:28:20.580 align:middle line:84% means that the cycle that's here, 01:28:20.580 --> 01:28:22.830 align:middle line:84% I don't care how you generate, whatever the cycle was, 01:28:22.830 --> 01:28:25.840 align:middle line:90% it must touch a non-edge. 01:28:25.840 --> 01:28:27.390 align:middle line:90% AUDIENCE: [INAUDIBLE] 01:28:27.390 --> 01:28:29.490 align:middle line:84% YAEL T. KALAI: So the Hamiltonian cycle 01:28:29.490 --> 01:28:31.780 align:middle line:84% says, there's an edge between i1, i2. 01:28:31.780 --> 01:28:33.930 align:middle line:90% There's an edge between i2, i3. 01:28:33.930 --> 01:28:35.860 align:middle line:90% One of them cannot be edge here. 01:28:35.860 --> 01:28:39.120 align:middle line:84% It can't be that all of them are edges here because they're-- 01:28:39.120 --> 01:28:42.220 align:middle line:84% so because it doesn't have a Hamiltonian cycle. 01:28:42.220 --> 01:28:45.010 align:middle line:84% So one of them cannot be an edge here. 01:28:45.010 --> 01:28:48.520 align:middle line:84% And now, what the verifier is asking from the prover, 01:28:48.520 --> 01:28:52.270 align:middle line:84% he looks at all the i1 and i-- all the i and j 01:28:52.270 --> 01:28:53.750 align:middle line:90% that do not have an edge. 01:28:53.750 --> 01:28:55.277 align:middle line:84% And he asked them, open that edge. 01:28:55.277 --> 01:28:56.360 align:middle line:90% I want to see that it's 0. 01:28:56.360 --> 01:29:01.040 align:middle line:84% I want to see that I gave you n squared safes. 01:29:01.040 --> 01:29:03.310 align:middle line:84% So for every i and j there is a safe. 01:29:03.310 --> 01:29:06.860 align:middle line:84% And it should be 1 if there is an edge, and 0 otherwise-- 01:29:06.860 --> 01:29:09.400 align:middle line:84% I mean, if there is an edge in the Hamiltonian cycle and 0 01:29:09.400 --> 01:29:10.340 align:middle line:90% otherwise. 01:29:10.340 --> 01:29:15.970 align:middle line:84% Now, what the verifier is asking the prover, for every ij here 01:29:15.970 --> 01:29:17.980 align:middle line:84% that does not have an edge, I want 01:29:17.980 --> 01:29:20.450 align:middle line:84% you to open the safe corresponding to that edge, 01:29:20.450 --> 01:29:21.980 align:middle line:90% and I want to see a 0 there. 01:29:21.980 --> 01:29:23.480 align:middle line:84% If there's a 1 there, I'm not happy. 01:29:23.480 --> 01:29:24.820 align:middle line:90% I'm going to reject you. 01:29:24.820 --> 01:29:28.510 align:middle line:84% Because this, there should be 1's only on the Hamiltonian 01:29:28.510 --> 01:29:29.090 align:middle line:90% cycle. 01:29:29.090 --> 01:29:32.800 align:middle line:84% And these are the only places that have an edge in your graph. 01:29:32.800 --> 01:29:37.180 align:middle line:84% But the problem is, on one of these ij that 01:29:37.180 --> 01:29:40.930 align:middle line:84% don't have an edge, you'll see an edge because the Hamiltonian 01:29:40.930 --> 01:29:43.520 align:middle line:90% cycle is not all on edges. 01:29:43.520 --> 01:29:45.820 align:middle line:90% And then I'm going to catch you. 01:29:45.820 --> 01:29:47.155 align:middle line:90% Yeah? 01:29:47.155 --> 01:29:47.655 align:middle line:90% Great. 01:29:47.655 --> 01:29:52.540 align:middle line:90% 01:29:52.540 --> 01:29:55.900 align:middle line:90% Any more questions? 01:29:55.900 --> 01:29:56.630 align:middle line:90% Yeah. 01:29:56.630 --> 01:29:57.230 align:middle line:90% AUDIENCE: I'm just curious. 01:29:57.230 --> 01:29:59.780 align:middle line:84% Is there also a notion for a proof of knowledge about-- 01:29:59.780 --> 01:30:00.760 align:middle line:90% YAEL T. KALAI: Yeah. 01:30:00.760 --> 01:30:04.220 align:middle line:84% AUDIENCE: --just not just edge, so a slightly stronger 01:30:04.220 --> 01:30:08.520 align:middle line:84% that requires the prover to actually know the Hamiltonian 01:30:08.520 --> 01:30:09.020 align:middle line:90% cycle? 01:30:09.020 --> 01:30:11.320 align:middle line:84% So here the proof, would the second part 01:30:11.320 --> 01:30:15.320 align:middle line:84% say that, that only guarantees that if it's G is not a-- 01:30:15.320 --> 01:30:18.640 align:middle line:84% doesn't have a Hamiltonian cycle, that the prover cheat, 01:30:18.640 --> 01:30:21.310 align:middle line:84% prover cannot compute this [INAUDIBLE]. 01:30:21.310 --> 01:30:25.630 align:middle line:84% Isn't necessarily a converse, is it possible for the cheating 01:30:25.630 --> 01:30:28.040 align:middle line:84% prover to not know the Hamiltonian cycle, 01:30:28.040 --> 01:30:29.510 align:middle line:90% but still contains the verifier? 01:30:29.510 --> 01:30:30.320 align:middle line:90% YAEL T. KALAI: Good, no. 01:30:30.320 --> 01:30:30.550 align:middle line:90% AUDIENCE: Where the G is-- 01:30:30.550 --> 01:30:31.150 align:middle line:90% YAEL T. KALAI: Good. 01:30:31.150 --> 01:30:32.442 align:middle line:90% Great question, great question. 01:30:32.442 --> 01:30:33.400 align:middle line:90% So the question was-- 01:30:33.400 --> 01:30:36.460 align:middle line:84% or let me just answer the question. 01:30:36.460 --> 01:30:41.000 align:middle line:84% The question was, wait, we just proved here soundness, 01:30:41.000 --> 01:30:45.340 align:middle line:84% that if x is a NAND language, on one of the answers you'll fail. 01:30:45.340 --> 01:30:47.350 align:middle line:84% But actually, doesn't this protocol 01:30:47.350 --> 01:30:50.030 align:middle line:84% give you something stronger, was the question, 01:30:50.030 --> 01:30:51.200 align:middle line:90% and the answer is yes. 01:30:51.200 --> 01:30:54.100 align:middle line:84% So what do we mean by something stronger? 01:30:54.100 --> 01:30:59.290 align:middle line:84% Let's say G does have a Hamiltonian cycle. 01:30:59.290 --> 01:31:03.460 align:middle line:84% Doesn't this protocol tell us, not only 01:31:03.460 --> 01:31:05.300 align:middle line:90% that G has a Hamiltonian cycle. 01:31:05.300 --> 01:31:08.290 align:middle line:84% If you succeed, let's say you succeed probability 1 or more 01:31:08.290 --> 01:31:10.060 align:middle line:90% than half. 01:31:10.060 --> 01:31:13.780 align:middle line:84% This protocol tells us not only that G has a Hamiltonian cycle, 01:31:13.780 --> 01:31:18.170 align:middle line:84% it means that P must know the cycle. 01:31:18.170 --> 01:31:23.000 align:middle line:84% You can actually find-- you can extract the cycle from P. 01:31:23.000 --> 01:31:24.345 align:middle line:90% And the answer is yes. 01:31:24.345 --> 01:31:25.720 align:middle line:84% You can actually-- this is what's 01:31:25.720 --> 01:31:27.230 align:middle line:90% called proof of knowledge. 01:31:27.230 --> 01:31:28.698 align:middle line:90% It means that P knows. 01:31:28.698 --> 01:31:30.740 align:middle line:84% Now, you can say, what does it mean that P knows? 01:31:30.740 --> 01:31:33.490 align:middle line:84% What are we-- this is a theory class, mathematics. 01:31:33.490 --> 01:31:35.700 align:middle line:90% What does know mean? 01:31:35.700 --> 01:31:38.620 align:middle line:84% So what we mean by P knows, what we 01:31:38.620 --> 01:31:43.900 align:middle line:84% mean is that we can actually efficiently extract 01:31:43.900 --> 01:31:45.650 align:middle line:90% the cycle from P. 01:31:45.650 --> 01:31:47.430 align:middle line:90% And how do we extract the cycle? 01:31:47.430 --> 01:31:49.430 align:middle line:90% It's actually very easy. 01:31:49.430 --> 01:31:50.550 align:middle line:90% We ask him. 01:31:50.550 --> 01:31:52.110 align:middle line:90% He committed to something. 01:31:52.110 --> 01:31:53.790 align:middle line:90% He knows how to open both. 01:31:53.790 --> 01:31:54.900 align:middle line:90% That's an assumption. 01:31:54.900 --> 01:31:59.320 align:middle line:84% So first we'll ask him, open only the cycle. 01:31:59.320 --> 01:32:02.090 align:middle line:90% 01:32:02.090 --> 01:32:08.120 align:middle line:90% And then give me the pi. 01:32:08.120 --> 01:32:13.050 align:middle line:84% Once I know the pi and the cycle, I can undo-- 01:32:13.050 --> 01:32:15.050 align:middle line:90% I know what pi G and I can see-- 01:32:15.050 --> 01:32:18.650 align:middle line:84% I can actually find the Hamiltonian cycle. 01:32:18.650 --> 01:32:21.837 align:middle line:84% So it's more than just a soundness. 01:32:21.837 --> 01:32:22.920 align:middle line:90% It's a proof of knowledge. 01:32:22.920 --> 01:32:24.200 align:middle line:90% G must know. 01:32:24.200 --> 01:32:28.250 align:middle line:84% I can actually use him to extract the Hamiltonian cycle 01:32:28.250 --> 01:32:28.750 align:middle line:90% from him. 01:32:28.750 --> 01:32:31.760 align:middle line:90% 01:32:31.760 --> 01:32:34.670 align:middle line:90% Any other questions? 01:32:34.670 --> 01:32:37.530 align:middle line:84% So let's take a five-minute break. 01:32:37.530 --> 01:32:39.083 align:middle line:84% And then, after the break, I'm going 01:32:39.083 --> 01:32:41.750 align:middle line:84% to show you why this protocol is not secure in the Random Oracle 01:32:41.750 --> 01:32:42.390 align:middle line:90% Model. 01:32:42.390 --> 01:32:43.350 align:middle line:90% But we'll fix it. 01:32:43.350 --> 01:32:43.940 align:middle line:90% Don't worry. 01:32:43.940 --> 01:32:44.580 align:middle line:90% OK. 01:32:44.580 --> 01:32:46.390 align:middle line:90% Let's take a break.