WEBVTT 00:00:00.000 --> 00:00:01.460 align:middle line:90% [SQUEAKING] 00:00:01.460 --> 00:00:03.380 align:middle line:90% [RUSTLING] 00:00:03.380 --> 00:00:05.780 align:middle line:90% [CLICKING] 00:00:05.780 --> 00:00:11.080 align:middle line:90% 00:00:11.080 --> 00:00:15.600 align:middle line:84% ROBERT TOWNSEND: This is lecture 9 on encryption. 00:00:15.600 --> 00:00:18.400 align:middle line:90% Be prepared. 00:00:18.400 --> 00:00:24.120 align:middle line:84% There's a bit of math in this, but the main goal 00:00:24.120 --> 00:00:27.920 align:middle line:84% is the conceptualization of the problem. 00:00:27.920 --> 00:00:36.120 align:middle line:84% So we've got encryption is a tool in and of itself, 00:00:36.120 --> 00:00:39.240 align:middle line:84% and it can, therefore, be separated from the ledgers 00:00:39.240 --> 00:00:40.520 align:middle line:90% and so on. 00:00:40.520 --> 00:00:42.220 align:middle line:90% I have a slide on that. 00:00:42.220 --> 00:00:48.080 align:middle line:84% And then we'll come to three interrelated concepts, 00:00:48.080 --> 00:00:54.800 align:middle line:84% encoded message systems, hashes, and cryptographic puzzles. 00:00:54.800 --> 00:00:59.080 align:middle line:84% And then I'll circle back to modern encryption, which 00:00:59.080 --> 00:01:02.240 align:middle line:84% uses public and private keys, giving you 00:01:02.240 --> 00:01:06.080 align:middle line:90% example of cyclic rings. 00:01:06.080 --> 00:01:08.980 align:middle line:84% And then we'll go into fully homomorphic encryption, 00:01:08.980 --> 00:01:13.560 align:middle line:84% multiparty computation, and zero-knowledge proofs 00:01:13.560 --> 00:01:18.280 align:middle line:84% in terms of what they are and some notation. 00:01:18.280 --> 00:01:21.640 align:middle line:84% I have been threatening to go back periodically 00:01:21.640 --> 00:01:28.680 align:middle line:84% to Bitcoin, which keeps popping up in various of the lectures. 00:01:28.680 --> 00:01:30.600 align:middle line:84% In this case, we'll now hopefully 00:01:30.600 --> 00:01:35.640 align:middle line:84% have enough of the tools to understand the data storage 00:01:35.640 --> 00:01:39.220 align:middle line:84% system in so-called Merkle trees, 00:01:39.220 --> 00:01:43.200 align:middle line:84% or hashed trees associated with Bitcoin 00:01:43.200 --> 00:01:46.720 align:middle line:84% and the use of proof-of-work algorithm 00:01:46.720 --> 00:01:51.880 align:middle line:84% to randomize who is the validator. 00:01:51.880 --> 00:01:58.490 align:middle line:84% And finally, I'll summarize how these FHE, Fully Homomorphic 00:01:58.490 --> 00:02:00.210 align:middle line:84% Encryption, multiparty computation, 00:02:00.210 --> 00:02:03.130 align:middle line:84% and zero-knowledge proofs fit together in terms 00:02:03.130 --> 00:02:08.330 align:middle line:90% of when they are needed or not. 00:02:08.330 --> 00:02:12.010 align:middle line:84% So the point of this slide is something 00:02:12.010 --> 00:02:16.090 align:middle line:84% I mentioned last time, that programmed contracts are 00:02:16.090 --> 00:02:18.530 align:middle line:84% distinct from distributed ledgers. 00:02:18.530 --> 00:02:22.490 align:middle line:84% We can use encryption for both, and it's 00:02:22.490 --> 00:02:26.330 align:middle line:84% the third leg, in the sense, that we've covered already, 00:02:26.330 --> 00:02:29.770 align:middle line:84% distributed ledgers and smart contracts. 00:02:29.770 --> 00:02:34.330 align:middle line:84% Encryption can be used as part of the validation protocol. 00:02:34.330 --> 00:02:37.810 align:middle line:84% Validation of the ledgers allows the financial counts 00:02:37.810 --> 00:02:42.030 align:middle line:84% to be altered with transfers of money and assets, 00:02:42.030 --> 00:02:45.970 align:middle line:84% but done in a secure way because it will be encrypted, 00:02:45.970 --> 00:02:51.010 align:middle line:84% hence, no trust is necessary, and this 00:02:51.010 --> 00:02:55.530 align:middle line:84% will create immutable and readily indexed records. 00:02:55.530 --> 00:02:57.730 align:middle line:90% So that's the ledger part of it. 00:02:57.730 --> 00:03:00.810 align:middle line:84% As part of the programming of contracts, 00:03:00.810 --> 00:03:03.410 align:middle line:84% we can deal with all kinds of obstacles 00:03:03.410 --> 00:03:07.290 align:middle line:84% to trade-- private information, limited communication, 00:03:07.290 --> 00:03:11.370 align:middle line:84% limited commitment, confidential data. 00:03:11.370 --> 00:03:15.170 align:middle line:84% So the data need to be secure, and it 00:03:15.170 --> 00:03:19.450 align:middle line:84% can be costly to store and retrieve data potentially. 00:03:19.450 --> 00:03:24.690 align:middle line:84% So encryption is a way to implement optimized solutions 00:03:24.690 --> 00:03:30.610 align:middle line:84% for two or more multilateral agents who want to use or solve 00:03:30.610 --> 00:03:33.130 align:middle line:84% a mechanism design problem, but they 00:03:33.130 --> 00:03:35.010 align:middle line:84% want to keep the messages they're 00:03:35.010 --> 00:03:38.730 align:middle line:90% sending back and forth secret. 00:03:38.730 --> 00:03:43.210 align:middle line:84% They want, again, the data to be secure and immutable. 00:03:43.210 --> 00:03:46.370 align:middle line:84% They want to be able to commit to the arrangements 00:03:46.370 --> 00:03:48.770 align:middle line:84% and commit to the way they're implemented 00:03:48.770 --> 00:03:53.210 align:middle line:84% without any inconsistencies even if one-- 00:03:53.210 --> 00:03:55.390 align:middle line:84% or if you can wrap your mind around it, 00:03:55.390 --> 00:04:00.380 align:middle line:84% if there were two, even if both potentially want to renege. 00:04:00.380 --> 00:04:02.380 align:middle line:90% So that's the big picture. 00:04:02.380 --> 00:04:07.380 align:middle line:84% Now let's go to the communication problem 00:04:07.380 --> 00:04:11.560 align:middle line:84% and basically think about encrypting messages. 00:04:11.560 --> 00:04:14.380 align:middle line:84% So there will be-- and I'm going to do this 00:04:14.380 --> 00:04:18.079 align:middle line:84% as kind of an overview and go through the other concepts, 00:04:18.079 --> 00:04:22.260 align:middle line:84% and then we'll circle back to some helpful notation. 00:04:22.260 --> 00:04:29.300 align:middle line:84% So a public key is an object in the context of a exactly 00:04:29.300 --> 00:04:33.100 align:middle line:84% specified mathematical space, and the public key 00:04:33.100 --> 00:04:37.860 align:middle line:84% is used to encrypt messages so that what one sees 00:04:37.860 --> 00:04:39.380 align:middle line:90% are ciphertext. 00:04:39.380 --> 00:04:40.940 align:middle line:90% Gobbledygook. 00:04:40.940 --> 00:04:44.740 align:middle line:90% The ciphertexts are public. 00:04:44.740 --> 00:04:47.820 align:middle line:84% There's no attempt to conceal them. 00:04:47.820 --> 00:04:53.180 align:middle line:84% The private key is used only for decryption of the messages. 00:04:53.180 --> 00:04:57.740 align:middle line:84% And the algorithms make it virtually impossible 00:04:57.740 --> 00:05:02.220 align:middle line:84% to decipher an encrypted message without the private key that was 00:05:02.220 --> 00:05:05.940 align:middle line:90% used as part of generating it. 00:05:05.940 --> 00:05:11.220 align:middle line:84% There's an analogy here associated with prime numbers, 00:05:11.220 --> 00:05:13.540 align:middle line:84% and I'll keep coming back to this. 00:05:13.540 --> 00:05:18.140 align:middle line:84% And actually, it will be part of the mathematics in the end, 00:05:18.140 --> 00:05:22.020 align:middle line:84% that if you have two prime numbers, and the number-- 00:05:22.020 --> 00:05:25.100 align:middle line:84% those primes are large enough, it 00:05:25.100 --> 00:05:29.820 align:middle line:84% is very difficult to decompose into the underlying 00:05:29.820 --> 00:05:32.300 align:middle line:90% primes from the product. 00:05:32.300 --> 00:05:37.360 align:middle line:84% And if you're thinking of 3 plus 5, 00:05:37.360 --> 00:05:43.100 align:middle line:84% that doesn't seem terribly hard, but as the numbers get 00:05:43.100 --> 00:05:48.180 align:middle line:84% larger and larger, it gets more and more challenging. 00:05:48.180 --> 00:05:51.300 align:middle line:84% So anyway, the analogy here is the private key 00:05:51.300 --> 00:05:55.490 align:middle line:84% is like one of the two factors that were used for the product, 00:05:55.490 --> 00:05:59.350 align:middle line:84% and it's pretty straightforward, computationally much easier 00:05:59.350 --> 00:06:03.110 align:middle line:84% to verify that you have a solution once 00:06:03.110 --> 00:06:05.790 align:middle line:90% one of the factors. 00:06:05.790 --> 00:06:10.270 align:middle line:84% So there's a word in here, algorithms on designated spaces 00:06:10.270 --> 00:06:13.470 align:middle line:90% make it virtually impossible. 00:06:13.470 --> 00:06:18.150 align:middle line:84% That's a scary word because actually, you could 00:06:18.150 --> 00:06:20.990 align:middle line:90% get lucky and decipher things. 00:06:20.990 --> 00:06:23.470 align:middle line:90% It's just the odds are low. 00:06:23.470 --> 00:06:25.910 align:middle line:84% And also, as you'll see, it does-- 00:06:25.910 --> 00:06:28.990 align:middle line:90% it is a computational issue. 00:06:28.990 --> 00:06:34.870 align:middle line:84% So some of these better-known ways of encrypting are 00:06:34.870 --> 00:06:42.790 align:middle line:84% vulnerable to quantum computing, and we'll touch on that as we-- 00:06:42.790 --> 00:06:46.350 align:middle line:84% so that it's so not so hard after all. 00:06:46.350 --> 00:06:48.050 align:middle line:90% OK, so that's messages. 00:06:48.050 --> 00:06:50.030 align:middle line:90% What are hash function? 00:06:50.030 --> 00:06:52.750 align:middle line:84% A cryptographic hash function is an algorithm 00:06:52.750 --> 00:06:57.650 align:middle line:84% that takes an arbitrary amount of an input in size and context 00:06:57.650 --> 00:07:02.070 align:middle line:84% and produces a fixed-size output called a hash. 00:07:02.070 --> 00:07:03.190 align:middle line:90% Some properties. 00:07:03.190 --> 00:07:07.950 align:middle line:84% A given input always generates the same hash value. 00:07:07.950 --> 00:07:12.710 align:middle line:84% The enciphered text is the same if the input is the same. 00:07:12.710 --> 00:07:18.830 align:middle line:84% And likewise, a hash cannot be deciphered except by random 00:07:18.830 --> 00:07:21.350 align:middle line:90% guessing. 00:07:21.350 --> 00:07:24.750 align:middle line:84% So a good hash would be one that makes 00:07:24.750 --> 00:07:28.330 align:middle line:84% it very hard to reconstruct the original input from the output. 00:07:28.330 --> 00:07:32.430 align:middle line:84% This is called one-way function or non-reversibility. 00:07:32.430 --> 00:07:38.650 align:middle line:84% With just one change in one bit of the original input, 00:07:38.650 --> 00:07:43.670 align:middle line:84% the output-- the hashed output changes significantly 00:07:43.670 --> 00:07:45.130 align:middle line:90% and unpredictably. 00:07:45.130 --> 00:07:48.430 align:middle line:90% 00:07:48.430 --> 00:07:55.110 align:middle line:84% So any tinkering is detected because you can compare one hash 00:07:55.110 --> 00:08:00.008 align:middle line:84% to a claimed identical copy, and if it used a different input, 00:08:00.008 --> 00:08:02.050 align:middle line:84% it will be different, and I'll come back to that. 00:08:02.050 --> 00:08:06.030 align:middle line:84% This anti-tinkering is called the diffusion or avalanche 00:08:06.030 --> 00:08:06.770 align:middle line:90% effect. 00:08:06.770 --> 00:08:09.950 align:middle line:90% 00:08:09.950 --> 00:08:12.650 align:middle line:84% And that's going from the hash backwards. 00:08:12.650 --> 00:08:16.950 align:middle line:84% Likewise from the inputs, if you had two different inputs 00:08:16.950 --> 00:08:20.750 align:middle line:84% to the hash, then it should be hard to find 00:08:20.750 --> 00:08:24.150 align:middle line:84% two different inputs that gave the same hash. 00:08:24.150 --> 00:08:30.230 align:middle line:84% Now that reminds me to say that the power of this thing 00:08:30.230 --> 00:08:33.710 align:middle line:84% is that the hash is of extraordinarily low dimension 00:08:33.710 --> 00:08:37.070 align:middle line:84% relative to the inputs that are being used. 00:08:37.070 --> 00:08:40.210 align:middle line:84% And as you'll see, this is how Bitcoin, for example, 00:08:40.210 --> 00:08:44.110 align:middle line:84% is able to keep track of all these transactions 00:08:44.110 --> 00:08:47.150 align:middle line:90% since the genesis state. 00:08:47.150 --> 00:08:53.480 align:middle line:84% So it almost seems impossible, but it's 00:08:53.480 --> 00:09:00.920 align:middle line:84% based on algorithms that are very hard to disentangle. 00:09:00.920 --> 00:09:03.040 align:middle line:84% And non-predictability means the input 00:09:03.040 --> 00:09:05.340 align:middle line:84% isn't going to tell you anything about the output. 00:09:05.340 --> 00:09:10.280 align:middle line:84% So Sam generated these examples in the last few days 00:09:10.280 --> 00:09:13.720 align:middle line:90% to try to be concrete. 00:09:13.720 --> 00:09:14.980 align:middle line:90% Here's the text. 00:09:14.980 --> 00:09:18.680 align:middle line:84% This is an example document that's going to be hashed. 00:09:18.680 --> 00:09:24.020 align:middle line:84% The quick brown fox jumped over the lazy dog. 00:09:24.020 --> 00:09:28.040 align:middle line:84% You put it in this standardized hash function 00:09:28.040 --> 00:09:32.840 align:middle line:90% and you get this ciphertext. 00:09:32.840 --> 00:09:35.120 align:middle line:84% But suppose you slipped and there's 00:09:35.120 --> 00:09:42.920 align:middle line:84% a little typo in this word over, and you get-- 00:09:42.920 --> 00:09:44.800 align:middle line:84% you can scan this for a while and try 00:09:44.800 --> 00:09:48.660 align:middle line:84% to see some similarity in the ciphertext, 00:09:48.660 --> 00:09:50.740 align:middle line:84% but there is none, that's the point. 00:09:50.740 --> 00:09:53.167 align:middle line:90% 00:09:53.167 --> 00:09:55.000 align:middle line:84% AUDIENCE: But the reason it's not invertible 00:09:55.000 --> 00:09:58.920 align:middle line:84% is because we don't know what this function is exactly doing 00:09:58.920 --> 00:10:01.680 align:middle line:90% as people as us, outsiders? 00:10:01.680 --> 00:10:03.522 align:middle line:84% Or why is it not invertible, right? 00:10:03.522 --> 00:10:05.480 align:middle line:84% Well, it's actually not invertible in the sense 00:10:05.480 --> 00:10:09.560 align:middle line:84% that there's many things that map to the same output. 00:10:09.560 --> 00:10:12.360 align:middle line:84% ROBERT TOWNSEND: I mean, you'll see some math momentarily. 00:10:12.360 --> 00:10:16.020 align:middle line:84% It's like basically private and public keys, 00:10:16.020 --> 00:10:18.700 align:middle line:84% and you can know a lot as the public keys, 00:10:18.700 --> 00:10:20.900 align:middle line:84% but the private key is randomly drawn, 00:10:20.900 --> 00:10:25.640 align:middle line:84% so unless you're lucky at guessing 00:10:25.640 --> 00:10:28.960 align:middle line:84% and you don't know the random key, 00:10:28.960 --> 00:10:34.200 align:middle line:84% then it's computationally almost impossible. 00:10:34.200 --> 00:10:37.920 align:middle line:84% Here's an example of hashing an accounting statement 00:10:37.920 --> 00:10:41.680 align:middle line:84% as representative database, two people. 00:10:41.680 --> 00:10:45.000 align:middle line:84% They're always Bob and Alice, it seems, 00:10:45.000 --> 00:10:47.470 align:middle line:84% with their balances and their ID numbers, 00:10:47.470 --> 00:10:50.660 align:middle line:90% and that generates this-- 00:10:50.660 --> 00:10:53.450 align:middle line:84% and these are all of the same length. 00:10:53.450 --> 00:10:55.670 align:middle line:84% I mean, hashes can be longer than this, 00:10:55.670 --> 00:10:59.370 align:middle line:90% but this is illustrative. 00:10:59.370 --> 00:10:59.870 align:middle line:90% OK. 00:10:59.870 --> 00:11:05.890 align:middle line:84% So hashes are like a signature system, too, for messages 00:11:05.890 --> 00:11:08.770 align:middle line:90% and for documents, data sets. 00:11:08.770 --> 00:11:12.930 align:middle line:84% If you have the original data set stored away on a server, 00:11:12.930 --> 00:11:18.890 align:middle line:84% then you hash it up and state exactly how it was hashed, 00:11:18.890 --> 00:11:21.730 align:middle line:90% and it's public. 00:11:21.730 --> 00:11:26.530 align:middle line:84% The hash version is public, but doesn't reveal the data. 00:11:26.530 --> 00:11:30.410 align:middle line:84% Now, a new person comes along who does have permission 00:11:30.410 --> 00:11:33.530 align:middle line:84% to look at the data, wants to make sure 00:11:33.530 --> 00:11:37.010 align:middle line:84% that the candidate file they're about to use with real data 00:11:37.010 --> 00:11:40.390 align:middle line:84% is actually the data file-- the original data file 00:11:40.390 --> 00:11:44.370 align:middle line:84% and it hasn't been corrupted or altered. 00:11:44.370 --> 00:11:47.510 align:middle line:84% So if the original data are assigned by this unique hash, 00:11:47.510 --> 00:11:52.650 align:middle line:84% then the candidate file can be hashed up and compared 00:11:52.650 --> 00:12:00.010 align:middle line:84% pretty readily to the original, so you could spot discrepancies. 00:12:00.010 --> 00:12:03.210 align:middle line:84% And relatedly, it's like sealing something, 00:12:03.210 --> 00:12:08.530 align:middle line:90% like stamping a document. 00:12:08.530 --> 00:12:12.170 align:middle line:84% You can-- again, by analogy with prime numbers, 00:12:12.170 --> 00:12:14.810 align:middle line:84% when they're multiplied together, 00:12:14.810 --> 00:12:18.010 align:middle line:84% it's really hard-- it's the hash, 00:12:18.010 --> 00:12:22.810 align:middle line:84% and say it's impossible to factor, then you have a document 00:12:22.810 --> 00:12:26.130 align:middle line:84% and you seal it with this product of primes. 00:12:26.130 --> 00:12:28.770 align:middle line:84% So someone comes along and says they created 00:12:28.770 --> 00:12:31.530 align:middle line:84% the document, that's my signature, 00:12:31.530 --> 00:12:36.150 align:middle line:84% and they give a validator an external third party 00:12:36.150 --> 00:12:38.450 align:middle line:90% one of the two factors. 00:12:38.450 --> 00:12:44.530 align:middle line:84% And now it's relatively easy for the external party to verify-- 00:12:44.530 --> 00:12:48.250 align:middle line:84% to totally factor the seal, as it were, 00:12:48.250 --> 00:12:51.530 align:middle line:90% and verify that it's the same. 00:12:51.530 --> 00:12:56.930 align:middle line:84% So by stamping it, the author of the document 00:12:56.930 --> 00:13:01.370 align:middle line:84% or the owner of the data is making a commitment 00:13:01.370 --> 00:13:03.250 align:middle line:90% to authorship. 00:13:03.250 --> 00:13:06.730 align:middle line:84% So in this case, you don't actually have to decompose it. 00:13:06.730 --> 00:13:10.090 align:middle line:84% If it shows up with a seal, then you 00:13:10.090 --> 00:13:13.790 align:middle line:84% could take it as given that it's going to work. 00:13:13.790 --> 00:13:20.450 align:middle line:84% The verifier could potentially, but not necessarily always 00:13:20.450 --> 00:13:27.530 align:middle line:84% verify the seal is authentic, that the document is authentic. 00:13:27.530 --> 00:13:28.790 align:middle line:90% So it's a commitment. 00:13:28.790 --> 00:13:32.410 align:middle line:84% You can think of it as solving a commitment problem. 00:13:32.410 --> 00:13:35.130 align:middle line:84% If you have a timeline of the creation of things 00:13:35.130 --> 00:13:39.290 align:middle line:84% along the way, and then use later by third parties 00:13:39.290 --> 00:13:43.980 align:middle line:84% and so on, you can't go back and say, oh, oops, 00:13:43.980 --> 00:13:46.460 align:middle line:90% that wasn't really my document. 00:13:46.460 --> 00:13:50.920 align:middle line:84% The third part essentially we've already mentioned, 00:13:50.920 --> 00:13:53.980 align:middle line:84% but it's good to think about it separately. 00:13:53.980 --> 00:13:56.780 align:middle line:90% Cryptographic puzzles. 00:13:56.780 --> 00:13:59.980 align:middle line:84% The problem could be hard, but not too hard, 00:13:59.980 --> 00:14:05.980 align:middle line:84% to solve the puzzle, and you can control the degree of hardness, 00:14:05.980 --> 00:14:10.420 align:middle line:84% and it is then subsequently solved by trial and error, 00:14:10.420 --> 00:14:13.560 align:middle line:84% but how many trials on average and so on 00:14:13.560 --> 00:14:17.700 align:middle line:84% and how much time it would take is, again, subject to control. 00:14:17.700 --> 00:14:20.620 align:middle line:90% So prime numbers are like that. 00:14:20.620 --> 00:14:23.660 align:middle line:84% They could be large, but not too large. 00:14:23.660 --> 00:14:28.900 align:middle line:84% It takes time and energy to-- and computational power 00:14:28.900 --> 00:14:32.340 align:middle line:90% to factor the product. 00:14:32.340 --> 00:14:37.380 align:middle line:84% So you can parameterize the difficulty. 00:14:37.380 --> 00:14:41.660 align:middle line:84% And that is one of the better-known parts of Bitcoin's 00:14:41.660 --> 00:14:43.700 align:middle line:84% validation protocol, and I'll come back 00:14:43.700 --> 00:14:51.420 align:middle line:84% to that about three-quarters of the way through this lecture. 00:14:51.420 --> 00:14:55.460 align:middle line:84% But a little bit more on factoring primes. 00:14:55.460 --> 00:14:57.400 align:middle line:84% First of all, in a subsequent slide, 00:14:57.400 --> 00:14:59.060 align:middle line:84% there's something about two numbers 00:14:59.060 --> 00:15:01.420 align:middle line:90% being called relatively prime. 00:15:01.420 --> 00:15:03.520 align:middle line:84% That means they're kind of prime for each other. 00:15:03.520 --> 00:15:07.420 align:middle line:84% They only share-- they don't share a common denominator 00:15:07.420 --> 00:15:09.020 align:middle line:90% other than unity. 00:15:09.020 --> 00:15:14.500 align:middle line:84% The main point here is wrap your mind about large prime numbers. 00:15:14.500 --> 00:15:25.900 align:middle line:84% 3,457,631 and, looking at digits, 4,563,000, et cetera, 00:15:25.900 --> 00:15:30.820 align:middle line:90% are each prime numbers. 00:15:30.820 --> 00:15:35.620 align:middle line:84% And if you multiply them together, 00:15:35.620 --> 00:15:39.870 align:middle line:84% you get this guy, which, if I did it correctly earlier 00:15:39.870 --> 00:15:44.310 align:middle line:84% this morning, is a billion-something. 00:15:44.310 --> 00:15:46.730 align:middle line:90% I mean, it's kind of amusing. 00:15:46.730 --> 00:15:50.590 align:middle line:84% Like, there is something known as the largest known 00:15:50.590 --> 00:15:51.650 align:middle line:90% prime number. 00:15:51.650 --> 00:15:54.230 align:middle line:90% 00:15:54.230 --> 00:16:02.950 align:middle line:84% And presumably it's not the last one, but that was the latest-- 00:16:02.950 --> 00:16:07.030 align:middle line:84% and it's all related to computational demands 00:16:07.030 --> 00:16:09.750 align:middle line:84% to, say, find a new prime, or in this case, 00:16:09.750 --> 00:16:13.070 align:middle line:84% decompose these products and so on. 00:16:13.070 --> 00:16:16.910 align:middle line:90% Now decompose has to do with-- 00:16:16.910 --> 00:16:21.150 align:middle line:84% is not this-- if you claim you have a solution, then 00:16:21.150 --> 00:16:24.070 align:middle line:84% you can verify that it is a solution. 00:16:24.070 --> 00:16:28.750 align:middle line:84% Finding a prime factorization of a given number with n digits 00:16:28.750 --> 00:16:34.470 align:middle line:84% is believed to be of exponential complexity, 00:16:34.470 --> 00:16:37.710 align:middle line:84% although that's not known for sure. 00:16:37.710 --> 00:16:44.390 align:middle line:84% The latest known algorithm is 10 to the power square root 00:16:44.390 --> 00:16:48.210 align:middle line:84% of n log n, essentially exponential, 00:16:48.210 --> 00:16:53.030 align:middle line:84% but the verification procedure, when you have a solution 00:16:53.030 --> 00:16:57.390 align:middle line:84% to verify that it is a solution, that's polynomial. 00:16:57.390 --> 00:17:01.390 align:middle line:84% So it's easier to verify stuff once you have a guess 00:17:01.390 --> 00:17:08.430 align:middle line:84% than it is to do the actual factoring to begin with. 00:17:08.430 --> 00:17:11.349 align:middle line:84% So again, the problem of factoring large integers 00:17:11.349 --> 00:17:15.310 align:middle line:84% is believed to be of exponential complexity. 00:17:15.310 --> 00:17:18.109 align:middle line:84% The current RSA encryption method 00:17:18.109 --> 00:17:24.170 align:middle line:84% is premised on that hypothesis, so it's not a known fact, 00:17:24.170 --> 00:17:25.710 align:middle line:90% you might say. 00:17:25.710 --> 00:17:29.710 align:middle line:84% It's just there's no evidence to the contrary yet. 00:17:29.710 --> 00:17:33.870 align:middle line:84% If we could find a way to factor large integers 00:17:33.870 --> 00:17:38.840 align:middle line:84% in polynomial time, then RSA-encrypted messages 00:17:38.840 --> 00:17:43.560 align:middle line:84% would be readily decrypted, deciphered. 00:17:43.560 --> 00:17:48.000 align:middle line:84% So this is the spirit of getting into the vulnerability 00:17:48.000 --> 00:17:54.740 align:middle line:84% of these algorithms in terms of the premises that underlie them, 00:17:54.740 --> 00:18:00.200 align:middle line:84% but also ultimately quantum computing. 00:18:00.200 --> 00:18:03.680 align:middle line:90% So back to the big picture. 00:18:03.680 --> 00:18:07.960 align:middle line:84% Encryption, in this case, thinking about messages, 00:18:07.960 --> 00:18:12.280 align:middle line:84% we may take it for granted now, but it's relatively recent 00:18:12.280 --> 00:18:19.960 align:middle line:84% that we have this breakthrough due to Whit Diffie's ideas. 00:18:19.960 --> 00:18:26.560 align:middle line:84% Previously, the same key machine that scrambled the message 00:18:26.560 --> 00:18:30.320 align:middle line:84% would also be the way to decipher it. 00:18:30.320 --> 00:18:32.800 align:middle line:84% I mean, for me, I always think of World War II 00:18:32.800 --> 00:18:36.780 align:middle line:84% and the enemies were encrypting messages, 00:18:36.780 --> 00:18:40.600 align:middle line:84% and there was a big value in getting the cipher 00:18:40.600 --> 00:18:45.440 align:middle line:84% machine off the enemy boat because then you 00:18:45.440 --> 00:18:48.200 align:middle line:90% could use it to-- 00:18:48.200 --> 00:18:53.640 align:middle line:84% and that's the deciphering machine, say, 00:18:53.640 --> 00:18:58.800 align:middle line:84% then you could decipher all the messages. 00:18:58.800 --> 00:19:01.400 align:middle line:90% But the breakthrough here is-- 00:19:01.400 --> 00:19:03.240 align:middle line:84% I guess that's what it says here. 00:19:03.240 --> 00:19:05.200 align:middle line:84% The very tools that eavesdroppers 00:19:05.200 --> 00:19:09.480 align:middle line:84% lusted after, the decryption keys were passed from person 00:19:09.480 --> 00:19:13.440 align:middle line:84% to person, they existed in two places, 00:19:13.440 --> 00:19:19.360 align:middle line:84% so it was very, very hard to basically keep them non-public. 00:19:19.360 --> 00:19:22.720 align:middle line:84% But under Whiffie's design, this deciphering 00:19:22.720 --> 00:19:25.580 align:middle line:84% is done by the public key and it is public. 00:19:25.580 --> 00:19:28.520 align:middle line:84% Everybody can know it, it's published. 00:19:28.520 --> 00:19:31.400 align:middle line:90% Widely disseminated. 00:19:31.400 --> 00:19:33.540 align:middle line:84% So instead of keeping everything secret, 00:19:33.540 --> 00:19:35.340 align:middle line:90% almost everything is public. 00:19:35.340 --> 00:19:39.720 align:middle line:84% All the encrypted ciphertexts are presumed to be public. 00:19:39.720 --> 00:19:42.520 align:middle line:84% The functional forms and spaces used for encryption 00:19:42.520 --> 00:19:48.000 align:middle line:84% are public, but not, of course, the messages themselves, 00:19:48.000 --> 00:19:51.820 align:middle line:84% which need to be kept secure, and in particular, 00:19:51.820 --> 00:20:01.000 align:middle line:84% not the private key, which has to do with the decryption. 00:20:01.000 --> 00:20:05.680 align:middle line:84% So public key for encryption, private key for deciphering. 00:20:05.680 --> 00:20:09.800 align:middle line:84% So finally, let's get to a little-- 00:20:09.800 --> 00:20:13.520 align:middle line:84% I myself have trouble understanding things 00:20:13.520 --> 00:20:17.280 align:middle line:84% if I don't see a bit of the math, so let 00:20:17.280 --> 00:20:22.520 align:middle line:90% me share with you some of that. 00:20:22.520 --> 00:20:27.440 align:middle line:84% So if we have a group of objects, say group G, 00:20:27.440 --> 00:20:34.490 align:middle line:84% we can take two any elements and add them or multiply them. 00:20:34.490 --> 00:20:39.050 align:middle line:84% So addition and multiplication are binary operations 00:20:39.050 --> 00:20:41.810 align:middle line:90% on two elements of a space. 00:20:41.810 --> 00:20:44.090 align:middle line:84% In well-defined spaces, any two elements 00:20:44.090 --> 00:20:48.610 align:middle line:84% can be added together or multiplied together. 00:20:48.610 --> 00:20:53.770 align:middle line:84% As long as certain key properties are satisfied, then 00:20:53.770 --> 00:20:57.530 align:middle line:84% this space G is referred to as a ring. 00:20:57.530 --> 00:21:00.530 align:middle line:84% The properties are going to be familiar 00:21:00.530 --> 00:21:03.970 align:middle line:84% for the binary operation of addition. 00:21:03.970 --> 00:21:09.450 align:middle line:84% It has to be associative, so you can put parentheses 00:21:09.450 --> 00:21:11.070 align:middle line:90% around stuff in different order. 00:21:11.070 --> 00:21:13.970 align:middle line:84% Commutative, you can just reverse A, D, D, 00:21:13.970 --> 00:21:19.450 align:middle line:84% A, have an identity element-- this is for addition, so it's 00:21:19.450 --> 00:21:25.010 align:middle line:84% like subtraction, the inverse to get the 0 element. 00:21:25.010 --> 00:21:28.770 align:middle line:84% And for multiplication, the operator 00:21:28.770 --> 00:21:31.610 align:middle line:84% must be left- and right-distributed. 00:21:31.610 --> 00:21:36.210 align:middle line:84% Again, associative in some cases, whatever that means, 00:21:36.210 --> 00:21:39.990 align:middle line:84% is commutative and have an identity element, which is 1. 00:21:39.990 --> 00:21:47.790 align:middle line:84% So again, you think of inverses, 5 times 1/5 gives you 1. 00:21:47.790 --> 00:21:50.250 align:middle line:84% So an inverse is something that will map back 00:21:50.250 --> 00:21:54.090 align:middle line:84% to this if you find it to this identity element. 00:21:54.090 --> 00:21:57.510 align:middle line:84% I mumbled something just now about "in some cases." 00:21:57.510 --> 00:21:59.370 align:middle line:84% It's really important to remember, 00:21:59.370 --> 00:22:03.790 align:middle line:84% there isn't just one space that people use there. 00:22:03.790 --> 00:22:08.170 align:middle line:84% An encryption technique consists of specifying, in this case, 00:22:08.170 --> 00:22:13.430 align:middle line:84% rings with their elements and so on, and their use. 00:22:13.430 --> 00:22:17.210 align:middle line:84% So maybe you just need additive encryption 00:22:17.210 --> 00:22:20.530 align:middle line:84% and not multiplicative encryption. 00:22:20.530 --> 00:22:22.370 align:middle line:90% But I'll show you one. 00:22:22.370 --> 00:22:28.230 align:middle line:84% And this is a finite number of integers 1, 2, dot-dot-dot, n. 00:22:28.230 --> 00:22:34.660 align:middle line:84% Zn, or Z sub n, is the notation for a set of a finite integers 00:22:34.660 --> 00:22:39.800 align:middle line:84% of order n with the provision that two integers, when added, 00:22:39.800 --> 00:22:41.660 align:middle line:90% would give you a number. 00:22:41.660 --> 00:22:46.900 align:middle line:84% If that sum is larger than n, you divide by the sum. 00:22:46.900 --> 00:22:50.820 align:middle line:84% You divide the sum by n and you get the remainder. 00:22:50.820 --> 00:22:53.460 align:middle line:90% That's a modulus n or mod n 00:22:53.460 --> 00:22:57.700 align:middle line:84% And I have-- but I haven't read very thoroughly, 00:22:57.700 --> 00:23:03.340 align:middle line:84% a document which is, what is this obsession with remainders? 00:23:03.340 --> 00:23:05.260 align:middle line:84% It seems like a lot of encryption 00:23:05.260 --> 00:23:10.180 align:middle line:84% is all about the properties of remaining elements 00:23:10.180 --> 00:23:11.520 align:middle line:90% after you divide. 00:23:11.520 --> 00:23:14.380 align:middle line:90% 00:23:14.380 --> 00:23:16.720 align:middle line:84% And you can think of them as a nuisance, 00:23:16.720 --> 00:23:19.600 align:middle line:84% like when you're dividing something by longhand, 00:23:19.600 --> 00:23:22.780 align:middle line:84% it's like, oh, now I have to add a whole other thing 00:23:22.780 --> 00:23:24.660 align:middle line:90% and do it all over again. 00:23:24.660 --> 00:23:29.780 align:middle line:84% So it's computationally-- that's where the computational aspects 00:23:29.780 --> 00:23:31.000 align:middle line:90% start entering in. 00:23:31.000 --> 00:23:32.480 align:middle line:90% Multiplication is the same. 00:23:32.480 --> 00:23:36.120 align:middle line:84% Take any two elements of G termed 00:23:36.120 --> 00:23:39.220 align:middle line:84% the order, the order of a group G 00:23:39.220 --> 00:23:41.700 align:middle line:84% is the number of elements in G, and it's 00:23:41.700 --> 00:23:44.820 align:middle line:90% a finite number, as above. 00:23:44.820 --> 00:23:48.140 align:middle line:84% And a generator of group G is an element of G 00:23:48.140 --> 00:23:51.660 align:middle line:84% which, when multiplied successively 00:23:51.660 --> 00:23:53.520 align:middle line:84% under the multiplication operator, 00:23:53.520 --> 00:23:56.380 align:middle line:90% generates the entire space. 00:23:56.380 --> 00:24:00.700 align:middle line:84% So we're going to do the multiplication operator r 00:24:00.700 --> 00:24:02.820 align:middle line:90% times-- 00:24:02.820 --> 00:24:06.340 align:middle line:84% if we do the multiplication operation r 00:24:06.340 --> 00:24:12.020 align:middle line:84% times on an arbitrary element of h, of G, 00:24:12.020 --> 00:24:16.820 align:middle line:84% then we can use this notation h to the power r, which 00:24:16.820 --> 00:24:19.820 align:middle line:84% means h, this particular element of G, 00:24:19.820 --> 00:24:24.620 align:middle line:84% is multiplied by itself successively r times. 00:24:24.620 --> 00:24:28.940 align:middle line:84% Now, G is not necessarily this h. 00:24:28.940 --> 00:24:31.620 align:middle line:90% h is any element in the group. 00:24:31.620 --> 00:24:34.880 align:middle line:84% G is a particular element that's the generator, 00:24:34.880 --> 00:24:36.740 align:middle line:84% and there could be more than one. 00:24:36.740 --> 00:24:40.520 align:middle line:90% So Sam created this example. 00:24:40.520 --> 00:24:43.380 align:middle line:90% So this is a cyclic ring. 00:24:43.380 --> 00:24:45.720 align:middle line:90% The order of the group is 11. 00:24:45.720 --> 00:24:50.020 align:middle line:84% There are 11 elements in this group, including 0. 00:24:50.020 --> 00:24:57.300 align:middle line:84% And the generator is 6, and the modulus is 11. 00:24:57.300 --> 00:25:06.100 align:middle line:84% So basically, you take 6 and multiply it-- 00:25:06.100 --> 00:25:13.000 align:middle line:84% don't multiply it. r equals 1, so 6 to the 1 is 6, 00:25:13.000 --> 00:25:16.980 align:middle line:90% so you get 6 back. 00:25:16.980 --> 00:25:21.220 align:middle line:90% If r is equal to 2-- 00:25:21.220 --> 00:25:21.920 align:middle line:90% sorry. 00:25:21.920 --> 00:25:24.660 align:middle line:90% 00:25:24.660 --> 00:25:25.710 align:middle line:90% Yeah. 00:25:25.710 --> 00:25:28.270 align:middle line:90% Then 6 times 6 is 36. 00:25:28.270 --> 00:25:34.550 align:middle line:84% 36 divided by 11 leaves a remainder of 3. 00:25:34.550 --> 00:25:38.110 align:middle line:84% So for r equal 2, n is equal to 3. 00:25:38.110 --> 00:25:41.150 align:middle line:84% So the outer circumference of this 00:25:41.150 --> 00:25:44.630 align:middle line:84% are the remainders after you take the modulus 00:25:44.630 --> 00:25:49.190 align:middle line:90% of the powered object. 00:25:49.190 --> 00:25:52.070 align:middle line:84% And the interior is the number of times 00:25:52.070 --> 00:25:56.190 align:middle line:84% you're multiplying by itself successfully. 00:25:56.190 --> 00:25:59.630 align:middle line:84% Now, looking at this representation-- 00:25:59.630 --> 00:26:02.070 align:middle line:90% oh, and why is it a ring? 00:26:02.070 --> 00:26:07.030 align:middle line:84% Because for various values of r, you 00:26:07.030 --> 00:26:10.670 align:middle line:90% will get all of the 10 objects. 00:26:10.670 --> 00:26:12.910 align:middle line:84% That mean 0 is kind of a trivial object 00:26:12.910 --> 00:26:16.010 align:middle line:84% here, so don't worry too much about it. 00:26:16.010 --> 00:26:21.310 align:middle line:84% You get all the underlying elements in G. 00:26:21.310 --> 00:26:24.390 align:middle line:84% And then he's staring at this, it's 00:26:24.390 --> 00:26:32.230 align:middle line:84% like, well, it's one to one, so how obscure is it? 00:26:32.230 --> 00:26:35.670 align:middle line:84% This is back to the cipher machine. 00:26:35.670 --> 00:26:40.270 align:middle line:84% If you know the code that generated this circle, 00:26:40.270 --> 00:26:44.510 align:middle line:84% and under Duffie's design, you would know the ring 00:26:44.510 --> 00:26:48.250 align:middle line:84% and the generator key and everything else, 00:26:48.250 --> 00:26:52.130 align:middle line:84% and if you saw this so-called randomized output, 00:26:52.130 --> 00:26:54.670 align:middle line:84% you could completely decipher it. 00:26:54.670 --> 00:26:58.650 align:middle line:84% Now one thought from that was, yes, 00:26:58.650 --> 00:27:02.310 align:middle line:84% but we're going to be encrypting and trying 00:27:02.310 --> 00:27:07.190 align:middle line:84% to decipher things for h, not G, but nevertheless, I 00:27:07.190 --> 00:27:11.270 align:middle line:84% think some of the intuition carried over because then we 00:27:11.270 --> 00:27:14.070 align:middle line:84% find this, ElGamal, which is what we're looking at, 00:27:14.070 --> 00:27:18.910 align:middle line:84% cryptography, keeping the private key secret when 00:27:18.910 --> 00:27:21.530 align:middle line:84% the order of the cyclic is small-- 00:27:21.530 --> 00:27:24.880 align:middle line:84% so not so many elements-- is impossible. 00:27:24.880 --> 00:27:27.320 align:middle line:84% An attacker could easily brute-force 00:27:27.320 --> 00:27:31.480 align:middle line:84% calculate the private key by trying out all possible values 00:27:31.480 --> 00:27:35.400 align:middle line:84% within the group order, and that's 00:27:35.400 --> 00:27:39.520 align:middle line:90% called baby step, giant step. 00:27:39.520 --> 00:27:41.400 align:middle line:90% I don't know why. 00:27:41.400 --> 00:27:46.200 align:middle line:84% It sounds like someone's on the moon. 00:27:46.200 --> 00:27:47.640 align:middle line:90% But anyway. 00:27:47.640 --> 00:27:53.040 align:middle line:84% So it's crucial that the cyclic group be a very large order, 00:27:53.040 --> 00:27:54.780 align:middle line:90% have a lot of elements. 00:27:54.780 --> 00:27:58.960 align:middle line:84% So again, this thing about integers and primes 00:27:58.960 --> 00:28:01.040 align:middle line:90% keeps coming back. 00:28:01.040 --> 00:28:06.480 align:middle line:84% Things have to be big here for this stuff to be hard to solve. 00:28:06.480 --> 00:28:11.280 align:middle line:84% So as a review, partly, when this repetition operator 00:28:11.280 --> 00:28:15.840 align:middle line:84% r is random and concealed, then with the modulus, outcomes 00:28:15.840 --> 00:28:18.920 align:middle line:84% from repeated operations, put one back 00:28:18.920 --> 00:28:24.080 align:middle line:84% into a random and unpredictable element of the ring, 00:28:24.080 --> 00:28:28.880 align:middle line:84% and rings with generator G are called cyclic rings. 00:28:28.880 --> 00:28:33.800 align:middle line:84% So for notation, r is the private key and h 00:28:33.800 --> 00:28:36.560 align:middle line:90% of r is the public key. 00:28:36.560 --> 00:28:41.560 align:middle line:84% So h is known, but r is kept private. 00:28:41.560 --> 00:28:45.440 align:middle line:84% Well, sorry, h of r is known, but r is kept private. 00:28:45.440 --> 00:28:49.020 align:middle line:84% So the space G with these operations and its modulus, 00:28:49.020 --> 00:28:52.560 align:middle line:84% its order, and the generator are all understood 00:28:52.560 --> 00:28:57.320 align:middle line:84% are public in addition to the public key. 00:28:57.320 --> 00:29:03.200 align:middle line:84% So that's an example in notation. 00:29:03.200 --> 00:29:10.800 align:middle line:84% So let's see how it works with incoming messages. 00:29:10.800 --> 00:29:13.060 align:middle line:90% OK. 00:29:13.060 --> 00:29:16.960 align:middle line:84% So there's three components to doing this-- 00:29:16.960 --> 00:29:22.050 align:middle line:84% the key generation, the encryption, and the deciphering. 00:29:22.050 --> 00:29:25.970 align:middle line:90% So there's Alice and Bob. 00:29:25.970 --> 00:29:30.970 align:middle line:84% And Alice is the one who's going to receive the message from Bob. 00:29:30.970 --> 00:29:34.410 align:middle line:90% Alice generates a key pair. 00:29:34.410 --> 00:29:42.210 align:middle line:84% She chooses a cyclic group G with q elements and a generator 00:29:42.210 --> 00:29:47.410 align:middle line:84% g, and this has good properties, like it has an additive element. 00:29:47.410 --> 00:29:52.410 align:middle line:84% She chooses an integer x randomly from the set of numbers 00:29:52.410 --> 00:29:56.490 align:middle line:84% up to the order of the group minus 1, 00:29:56.490 --> 00:30:00.870 align:middle line:90% and computes h equal g to the x. 00:30:00.870 --> 00:30:07.290 align:middle line:84% So h here becomes the public key. 00:30:07.290 --> 00:30:12.050 align:middle line:84% And in fact, all of this is published, not just h, but also 00:30:12.050 --> 00:30:15.996 align:middle line:84% the group, the order, and the generator. 00:30:15.996 --> 00:30:19.070 align:middle line:84% And Alice secures her private key. 00:30:19.070 --> 00:30:23.410 align:middle line:84% And for that to work, she's got to keep it secret. 00:30:23.410 --> 00:30:27.110 align:middle line:84% Don't hand it to a third party, put it on a server, 00:30:27.110 --> 00:30:29.250 align:middle line:90% et cetera, et cetera. 00:30:29.250 --> 00:30:32.050 align:middle line:90% OK, so encryption. 00:30:32.050 --> 00:30:36.450 align:middle line:84% Bob wants to send a private message to Alice 00:30:36.450 --> 00:30:40.770 align:middle line:90% using Alice's public key. 00:30:40.770 --> 00:30:45.890 align:middle line:84% So the message m that Bob wants to send 00:30:45.890 --> 00:30:48.910 align:middle line:84% is mapped into the underlying space G, 00:30:48.910 --> 00:30:51.110 align:middle line:84% and that's not supposed to be hard to do. 00:30:51.110 --> 00:30:58.190 align:middle line:84% That's like ASCII and binary and Greek and everything else. 00:30:58.190 --> 00:31:02.490 align:middle line:84% You can go back and forth to the representation of objects. 00:31:02.490 --> 00:31:06.810 align:middle line:84% In this case, mapping it into G itself. 00:31:06.810 --> 00:31:13.930 align:middle line:84% Then Bob now chooses another random number, y. 00:31:13.930 --> 00:31:19.490 align:middle line:84% Again from no larger than q minus 1. 00:31:19.490 --> 00:31:24.450 align:middle line:84% And Bob computes using h, which is known, h to the y, 00:31:24.450 --> 00:31:29.690 align:middle line:84% something called a secret-- or a shared secret. 00:31:29.690 --> 00:31:33.770 align:middle line:84% You could initially think that if Bob has chosen this 00:31:33.770 --> 00:31:38.390 align:middle line:84% at random, then it's not even going to be shared with Alice, 00:31:38.390 --> 00:31:45.330 align:middle line:84% but again, the point of this is that part of Alice's process 00:31:45.330 --> 00:31:52.290 align:middle line:84% to decipher the message m will reveal the secret to Alice. 00:31:52.290 --> 00:31:57.770 align:middle line:84% OK, so Bob chooses this random object, randomly chosen 00:31:57.770 --> 00:31:59.680 align:middle line:90% object y. 00:31:59.680 --> 00:32:03.530 align:middle line:90% h to the y is the secret s. 00:32:03.530 --> 00:32:08.210 align:middle line:84% Bob sends two ciphertexts to Alice. 00:32:08.210 --> 00:32:11.490 align:middle line:84% g, the generator, to this random value 00:32:11.490 --> 00:32:19.160 align:middle line:84% y, and also sends the message multiplied with the secret. 00:32:19.160 --> 00:32:23.180 align:middle line:90% 00:32:23.180 --> 00:32:26.860 align:middle line:90% So Bob gets a vector. 00:32:26.860 --> 00:32:32.420 align:middle line:84% Two ciphertexts-- oh, sorry, Alice gets two ciphertexts. 00:32:32.420 --> 00:32:37.420 align:middle line:84% So Alice takes those ciphertexts and she has her private key. 00:32:37.420 --> 00:32:40.040 align:middle line:90% Note, Bob never saw it. 00:32:40.040 --> 00:32:43.580 align:middle line:90% 00:32:43.580 --> 00:32:47.880 align:middle line:84% The first thing is, Alice can compute the secret. 00:32:47.880 --> 00:32:50.300 align:middle line:90% How is that possible? 00:32:50.300 --> 00:32:56.780 align:middle line:84% She has the ciphertext from Bob, which is g to the y. 00:32:56.780 --> 00:33:04.120 align:middle line:84% So c1 to the x is g to the power y times x-- 00:33:04.120 --> 00:33:06.180 align:middle line:84% and I'll come back to this in a minute, 00:33:06.180 --> 00:33:11.580 align:middle line:90% but h here was g to the x. 00:33:11.580 --> 00:33:16.260 align:middle line:84% So this g to the xy is h to the y. 00:33:16.260 --> 00:33:18.440 align:middle line:84% Now a little bit of a comment here. 00:33:18.440 --> 00:33:21.260 align:middle line:90% 00:33:21.260 --> 00:33:29.380 align:middle line:84% In this representation of the encrypted space, 00:33:29.380 --> 00:33:34.020 align:middle line:84% it looks like you can do the usual operations 00:33:34.020 --> 00:33:37.420 align:middle line:90% on the powers of some-- 00:33:37.420 --> 00:33:42.960 align:middle line:84% but it's not necessarily true that in our normal spaces, 00:33:42.960 --> 00:33:47.540 align:middle line:84% g to the x raised to another power where the whole object is 00:33:47.540 --> 00:33:50.360 align:middle line:84% being raised is just the product of the two powers. 00:33:50.360 --> 00:33:54.640 align:middle line:84% That's not true, but it is true in these encrypted spaces. 00:33:54.640 --> 00:33:57.740 align:middle line:90% 00:33:57.740 --> 00:34:02.600 align:middle line:84% So lest we lose the thread of this, 00:34:02.600 --> 00:34:07.220 align:middle line:84% Bob has sent the ciphertext to Alice. 00:34:07.220 --> 00:34:14.210 align:middle line:84% Alice takes the c1 ciphertext and actually computes s. 00:34:14.210 --> 00:34:17.909 align:middle line:90% 00:34:17.909 --> 00:34:21.409 align:middle line:84% So at this point, Alice actually knows y 00:34:21.409 --> 00:34:25.030 align:middle line:84% because she knows h and is seeing 00:34:25.030 --> 00:34:27.429 align:middle line:90% that part of the ciphertext. 00:34:27.429 --> 00:34:32.630 align:middle line:84% But next, Alice computes s inverse because she knows s, 00:34:32.630 --> 00:34:35.870 align:middle line:84% and every element in G has an inverse. 00:34:35.870 --> 00:34:39.790 align:middle line:84% So Alice can decipher the message 00:34:39.790 --> 00:34:43.070 align:middle line:84% just by taking the second ciphertext 00:34:43.070 --> 00:34:48.190 align:middle line:84% and post multiplying by the inverse. 00:34:48.190 --> 00:34:52.750 align:middle line:84% So c2, the second ciphertext is m to the s. 00:34:52.750 --> 00:34:59.293 align:middle line:84% So c2 to the s inverse is just m times ss inverse, and you get m. 00:34:59.293 --> 00:35:01.210 align:middle line:84% All right, it's a bit tedious on the one hand, 00:35:01.210 --> 00:35:08.750 align:middle line:84% but at least you can get a good sense of how the encryption 00:35:08.750 --> 00:35:13.190 align:middle line:84% system is working-- in this case, allowing Bob, 00:35:13.190 --> 00:35:16.950 align:middle line:84% using the published public part of the key from Alice, 00:35:16.950 --> 00:35:22.330 align:middle line:84% to send Alice a secret message that she can decipher, 00:35:22.330 --> 00:35:27.770 align:middle line:84% but no one else would know because, again, 00:35:27.770 --> 00:35:30.190 align:middle line:90% Bob is randomly choosing-- 00:35:30.190 --> 00:35:32.770 align:middle line:84% it doesn't say that line by line, 00:35:32.770 --> 00:35:37.510 align:middle line:84% but Bob randomly chose y, so Bob has his version 00:35:37.510 --> 00:35:41.830 align:middle line:90% of a secret private key. 00:35:41.830 --> 00:35:43.390 align:middle line:90% OK. 00:35:43.390 --> 00:35:45.430 align:middle line:90% Signatures. 00:35:45.430 --> 00:35:49.330 align:middle line:84% This has to do with getting ready to do outgoing messages. 00:35:49.330 --> 00:35:52.670 align:middle line:84% Interestingly, incoming messages to Alice 00:35:52.670 --> 00:35:58.910 align:middle line:84% are easier, so be forewarned, than dealing 00:35:58.910 --> 00:36:01.070 align:middle line:90% with these outgoing messages. 00:36:01.070 --> 00:36:04.710 align:middle line:84% So Alice wants to send something and she wants to sign it. 00:36:04.710 --> 00:36:09.390 align:middle line:84% That would allow verifiability of her identity-- 00:36:09.390 --> 00:36:15.080 align:middle line:84% she is Alice, and the message content came from Alice, 00:36:15.080 --> 00:36:17.600 align:middle line:84% so she's committed to be the author, 00:36:17.600 --> 00:36:19.960 align:middle line:90% and having sent the message. 00:36:19.960 --> 00:36:23.080 align:middle line:84% So again, no reneging if this works. 00:36:23.080 --> 00:36:26.320 align:middle line:84% Her identity is known, and the fact that she sent this message 00:36:26.320 --> 00:36:27.480 align:middle line:90% will be known. 00:36:27.480 --> 00:36:30.200 align:middle line:84% Not necessarily-- but anyway, this 00:36:30.200 --> 00:36:32.600 align:middle line:90% is the way a signature works. 00:36:32.600 --> 00:36:34.060 align:middle line:90% The message is kind of separate. 00:36:34.060 --> 00:36:38.120 align:middle line:84% We're going to focus on signing the signature part here. 00:36:38.120 --> 00:36:42.600 align:middle line:84% So private keys are used to generate a digital signature 00:36:42.600 --> 00:36:45.680 align:middle line:84% for the outgoing message such that it 00:36:45.680 --> 00:36:48.680 align:middle line:84% can be verified who knows the signer's 00:36:48.680 --> 00:36:50.140 align:middle line:90% corresponding public key. 00:36:50.140 --> 00:36:52.520 align:middle line:84% So that's similar to what we just did. 00:36:52.520 --> 00:36:56.040 align:middle line:84% The public key is public and everybody knows it. 00:36:56.040 --> 00:36:59.100 align:middle line:84% And the receiver can verify the origin of the message, 00:36:59.100 --> 00:37:01.480 align:middle line:90% authentication from Alice. 00:37:01.480 --> 00:37:04.040 align:middle line:84% The sender cannot falsely claim they have not signed 00:37:04.040 --> 00:37:06.560 align:middle line:90% the message, non-repudiation. 00:37:06.560 --> 00:37:08.720 align:middle line:84% And the message has not been modified 00:37:08.720 --> 00:37:11.440 align:middle line:90% since it was signed, integrity. 00:37:11.440 --> 00:37:15.720 align:middle line:84% So those are all really nice, strong properties. 00:37:15.720 --> 00:37:17.980 align:middle line:84% AUDIENCE: For the previous encryption we just saw, 00:37:17.980 --> 00:37:21.960 align:middle line:84% we didn't-- we only needed a group and one operation 00:37:21.960 --> 00:37:24.840 align:middle line:90% and to exchange the powers? 00:37:24.840 --> 00:37:32.560 align:middle line:84% So that comes from associative or something from the group? 00:37:32.560 --> 00:37:33.560 align:middle line:90% I don't know. 00:37:33.560 --> 00:37:37.400 align:middle line:84% ROBERT TOWNSEND: That's what was in the notation, yes. 00:37:37.400 --> 00:37:39.700 align:middle line:84% AUDIENCE: So-- but then those are the only properties 00:37:39.700 --> 00:37:40.700 align:middle line:90% we really needed, right? 00:37:40.700 --> 00:37:41.500 align:middle line:90% We didn't need-- 00:37:41.500 --> 00:37:43.542 align:middle line:84% ROBERT TOWNSEND: I think it's probably true, yes. 00:37:43.542 --> 00:37:47.880 align:middle line:84% I haven't thought about that, only a subset of the properties. 00:37:47.880 --> 00:37:51.560 align:middle line:84% I mean, there was kind of a hint of that at the beginning. 00:37:51.560 --> 00:37:54.640 align:middle line:84% Let e represent the additive element. 00:37:54.640 --> 00:37:56.360 align:middle line:84% AUDIENCE: Oh Yeah, it only needs one, OK. 00:37:56.360 --> 00:37:57.732 align:middle line:90% ROBERT TOWNSEND: Yeah. 00:37:57.732 --> 00:37:59.440 align:middle line:84% AUDIENCE: And then exchanging the powers, 00:37:59.440 --> 00:38:04.960 align:middle line:84% and then I guess we also need it to be commutative? 00:38:04.960 --> 00:38:06.080 align:middle line:90% ROBERT TOWNSEND: Yeah. 00:38:06.080 --> 00:38:08.940 align:middle line:90% AUDIENCE: Where do you do that? 00:38:08.940 --> 00:38:12.323 align:middle line:90% 00:38:12.323 --> 00:38:14.740 align:middle line:84% ROBERT TOWNSEND: I don't know, it's not quite commutative. 00:38:14.740 --> 00:38:15.782 align:middle line:90% I mean, this thing here-- 00:38:15.782 --> 00:38:16.740 align:middle line:90% AUDIENCE: I mean, yeah. 00:38:16.740 --> 00:38:18.200 align:middle line:90% Maybe it's just associativity. 00:38:18.200 --> 00:38:20.980 align:middle line:84% It doesn't matter what order you do the operations. 00:38:20.980 --> 00:38:22.240 align:middle line:90% ROBERT TOWNSEND: Yeah. 00:38:22.240 --> 00:38:24.680 align:middle line:84% AUDIENCE: Or maybe it also needs to be-- 00:38:24.680 --> 00:38:25.680 align:middle line:90% I don't know. 00:38:25.680 --> 00:38:26.805 align:middle line:90% ROBERT TOWNSEND: All right. 00:38:26.805 --> 00:38:28.152 align:middle line:90% But, I mean, I'm agreeing that-- 00:38:28.152 --> 00:38:29.360 align:middle line:90% AUDIENCE: Not everything is-- 00:38:29.360 --> 00:38:30.277 align:middle line:90% ROBERT TOWNSEND: Yeah. 00:38:30.277 --> 00:38:39.000 align:middle line:90% 00:38:39.000 --> 00:38:41.880 align:middle line:90% OK. 00:38:41.880 --> 00:38:47.420 align:middle line:84% So this is the Schnorr signature scheme for outgoing messages. 00:38:47.420 --> 00:38:51.340 align:middle line:84% And as I said, it's a little bit more complicated, 00:38:51.340 --> 00:38:53.200 align:middle line:90% but we'll give it a go. 00:38:53.200 --> 00:38:57.420 align:middle line:84% In this case, we're going to have three phases to it. 00:38:57.420 --> 00:39:01.680 align:middle line:84% Parameter generation, then a more familiar phase 00:39:01.680 --> 00:39:05.120 align:middle line:84% about generating keys, and then-- 00:39:05.120 --> 00:39:06.730 align:middle line:90% actually four. 00:39:06.730 --> 00:39:13.810 align:middle line:84% Assigning part and a verification part. 00:39:13.810 --> 00:39:17.970 align:middle line:84% So the parameter generation, you choose 00:39:17.970 --> 00:39:23.570 align:middle line:90% a length of N and a prime-- 00:39:23.570 --> 00:39:26.250 align:middle line:90% N-bit prime number p. 00:39:26.250 --> 00:39:28.890 align:middle line:84% See, these primes are actually here. 00:39:28.890 --> 00:39:35.290 align:middle line:84% We choose a cryptographic hash function, H. It has more-- 00:39:35.290 --> 00:39:37.350 align:middle line:90% it's longer than what we need. 00:39:37.350 --> 00:39:40.570 align:middle line:84% We're only going to need the first N bits of it-- 00:39:40.570 --> 00:39:43.790 align:middle line:90% and this ended up with Bitcoin. 00:39:43.790 --> 00:39:47.410 align:middle line:84% Perhaps for this reason, I'm not sure. 00:39:47.410 --> 00:39:55.490 align:middle line:84% We're going to choose a generator g less than the number 00:39:55.490 --> 00:40:00.850 align:middle line:84% p, the prime number p of the cyclic group of integers modulo 00:40:00.850 --> 00:40:01.690 align:middle line:90% q. 00:40:01.690 --> 00:40:03.390 align:middle line:84% This is a little bit of a complication 00:40:03.390 --> 00:40:05.650 align:middle line:84% and I'm not going to even attempt 00:40:05.650 --> 00:40:09.330 align:middle line:84% to explain why it's needed, but before, we 00:40:09.330 --> 00:40:11.850 align:middle line:84% were just in one space with a certain order 00:40:11.850 --> 00:40:14.170 align:middle line:84% and a certain modulus, and here, we 00:40:14.170 --> 00:40:16.150 align:middle line:90% have two objects going for us. 00:40:16.150 --> 00:40:20.350 align:middle line:84% We have p and q, and they're different from each other. 00:40:20.350 --> 00:40:22.890 align:middle line:90% 00:40:22.890 --> 00:40:30.010 align:middle line:84% And all of this can be shared among the users of the system 00:40:30.010 --> 00:40:31.630 align:middle line:90% for key generation. 00:40:31.630 --> 00:40:34.170 align:middle line:90% 00:40:34.170 --> 00:40:36.010 align:middle line:90% We do the following. 00:40:36.010 --> 00:40:38.410 align:middle line:90% We choose a random-- 00:40:38.410 --> 00:40:42.110 align:middle line:84% randomly choose an integer from this set 1, 00:40:42.110 --> 00:40:48.410 align:middle line:84% dot-dot-dot, up to p minus 2, and then not surprisingly, 00:40:48.410 --> 00:40:53.890 align:middle line:84% we choose g, the generator, to this power A 00:40:53.890 --> 00:40:55.910 align:middle line:90% where A is randomly chosen. 00:40:55.910 --> 00:40:58.610 align:middle line:84% So A is looking like a private key. 00:40:58.610 --> 00:41:03.210 align:middle line:90% It's modulus p, not q. 00:41:03.210 --> 00:41:07.780 align:middle line:84% And so as a summary, although I hate this notation, 00:41:07.780 --> 00:41:13.646 align:middle line:90% the secret key SK is little a. 00:41:13.646 --> 00:41:26.300 align:middle line:84% And the public key of this scheme is g to the a modulo p. 00:41:26.300 --> 00:41:28.040 align:middle line:90% Why do I dislike it? 00:41:28.040 --> 00:41:30.880 align:middle line:84% Because this looks like the private key, 00:41:30.880 --> 00:41:34.020 align:middle line:90% but it's the public key. 00:41:34.020 --> 00:41:37.380 align:middle line:84% The private part is the secret key. 00:41:37.380 --> 00:41:39.820 align:middle line:90% Anyway, just a nuisance. 00:41:39.820 --> 00:41:41.300 align:middle line:90% OK. 00:41:41.300 --> 00:41:42.680 align:middle line:90% So the signing. 00:41:42.680 --> 00:41:46.500 align:middle line:90% 00:41:46.500 --> 00:41:48.840 align:middle line:84% There's a message m, and as I said, 00:41:48.840 --> 00:41:52.220 align:middle line:84% that's a bit separate here, but on the outer envelope, 00:41:52.220 --> 00:41:56.040 align:middle line:84% you might say, Alice does signing in the following way, 00:41:56.040 --> 00:41:59.020 align:middle line:90% and let's just jump down here. 00:41:59.020 --> 00:42:03.260 align:middle line:84% Alice picks a random number k, and she 00:42:03.260 --> 00:42:06.980 align:middle line:84% does the usual thing, which is the generator to the power of k 00:42:06.980 --> 00:42:16.660 align:middle line:84% mod p is here denoted as h as we have been doing before. 00:42:16.660 --> 00:42:24.100 align:middle line:84% So it's effectively as if Alice is sending 00:42:24.100 --> 00:42:28.820 align:middle line:84% some randomized object to Bob h, which 00:42:28.820 --> 00:42:32.820 align:middle line:84% looks like a public key for purposes of signing. 00:42:32.820 --> 00:42:39.860 align:middle line:84% Now Bob gets this thing and Bob picks something else, a c, 00:42:39.860 --> 00:42:46.500 align:middle line:84% a constant, from the set 1 through q of integers, 00:42:46.500 --> 00:42:49.520 align:middle line:84% and Bob sends that back to Alice. 00:42:49.520 --> 00:42:52.300 align:middle line:90% 00:42:52.300 --> 00:42:57.540 align:middle line:84% So then Alice takes c, that she just got from Bob, 00:42:57.540 --> 00:43:01.440 align:middle line:84% pre-multiplies by a, which is her private key. 00:43:01.440 --> 00:43:04.180 align:middle line:90% 00:43:04.180 --> 00:43:07.520 align:middle line:84% Adds k to it and takes the modulus q. 00:43:07.520 --> 00:43:10.460 align:middle line:90% 00:43:10.460 --> 00:43:12.160 align:middle line:90% And sends that to Bob. 00:43:12.160 --> 00:43:15.380 align:middle line:90% 00:43:15.380 --> 00:43:19.900 align:middle line:84% So if all these steps are followed in this way, 00:43:19.900 --> 00:43:23.440 align:middle line:84% Bob can verify the signature as follows. 00:43:23.440 --> 00:43:30.060 align:middle line:90% 00:43:30.060 --> 00:43:35.780 align:middle line:84% I mean, Bob got s from Alice, so he 00:43:35.780 --> 00:43:41.420 align:middle line:84% can take g, the publicly known generator, to this power s, 00:43:41.420 --> 00:43:44.660 align:middle line:84% and he knows what that is because he 00:43:44.660 --> 00:43:48.700 align:middle line:84% has knowledge of every bit of it-- every piece of it. 00:43:48.700 --> 00:43:54.980 align:middle line:84% The question is whether the public key that 00:43:54.980 --> 00:44:01.910 align:middle line:84% was part of the scheme, when raised to c, multiplied 00:44:01.910 --> 00:44:10.750 align:middle line:84% by h, which he-- which Bob got from Alice in the first step, 00:44:10.750 --> 00:44:16.830 align:middle line:84% is equal to this object on the left-hand side. 00:44:16.830 --> 00:44:19.990 align:middle line:84% Back to the thinking of the big picture. 00:44:19.990 --> 00:44:28.070 align:middle line:84% Bob knows all these objects as a outcome of this messaging that's 00:44:28.070 --> 00:44:29.450 align:middle line:90% going back and forth. 00:44:29.450 --> 00:44:32.470 align:middle line:90% 00:44:32.470 --> 00:44:33.890 align:middle line:90% Are these things equal? 00:44:33.890 --> 00:44:37.950 align:middle line:84% Well, if all these steps were followed, then g to the s 00:44:37.950 --> 00:44:42.810 align:middle line:84% is just g to the what s is, ac plus k. 00:44:42.810 --> 00:44:45.670 align:middle line:90% 00:44:45.670 --> 00:44:50.550 align:middle line:84% And over here, this public key raised to the power c 00:44:50.550 --> 00:44:53.790 align:middle line:84% is like g to the a raised to the power c, which 00:44:53.790 --> 00:45:01.310 align:middle line:84% is like a product, and times h, but again, h 00:45:01.310 --> 00:45:08.190 align:middle line:84% was given by the first step that Alice did somewhere here. 00:45:08.190 --> 00:45:12.590 align:middle line:84% Alice signed it as h equals g to the k. 00:45:12.590 --> 00:45:17.350 align:middle line:90% So Bob knows that, too. 00:45:17.350 --> 00:45:21.470 align:middle line:84% And so you can now almost trivially see 00:45:21.470 --> 00:45:24.010 align:middle line:84% that these two objects are equal to each other. 00:45:24.010 --> 00:45:29.230 align:middle line:90% 00:45:29.230 --> 00:45:35.150 align:middle line:84% OK, that's the most tedious thing we're going to do today. 00:45:35.150 --> 00:45:37.910 align:middle line:84% I'm a stubborn guy on some dimensions. 00:45:37.910 --> 00:45:41.010 align:middle line:84% I insist on going through the math 00:45:41.010 --> 00:45:46.650 align:middle line:84% so that we understand that this, more concretely, 00:45:46.650 --> 00:45:51.610 align:middle line:84% exactly how this algorithm is working in terms of signatures 00:45:51.610 --> 00:45:55.410 align:middle line:84% rather than just claiming that it works. 00:45:55.410 --> 00:45:58.960 align:middle line:90% 00:45:58.960 --> 00:46:01.320 align:middle line:84% So this signature scheme will always 00:46:01.320 --> 00:46:06.840 align:middle line:84% be accepted by the receiver of the message. 00:46:06.840 --> 00:46:09.480 align:middle line:84% In this case, again, Alice is sending it to Bob, 00:46:09.480 --> 00:46:14.320 align:middle line:84% and Bob knows it must be Alice because only Alice could have 00:46:14.320 --> 00:46:16.080 align:middle line:84% encrypted things in such a way as 00:46:16.080 --> 00:46:20.360 align:middle line:84% to send it back to him that would have made this equation 00:46:20.360 --> 00:46:20.900 align:middle line:90% hold. 00:46:20.900 --> 00:46:25.640 align:middle line:90% 00:46:25.640 --> 00:46:28.600 align:middle line:90% OK. 00:46:28.600 --> 00:46:33.840 align:middle line:84% Well so far, we've been talking about sets of integers modulo 00:46:33.840 --> 00:46:37.180 align:middle line:84% stuff, granted, of large dimension. 00:46:37.180 --> 00:46:41.120 align:middle line:84% But it turns out that this is driven by the concern 00:46:41.120 --> 00:46:43.200 align:middle line:84% that these schemes could eventually 00:46:43.200 --> 00:46:48.080 align:middle line:84% be broken by quantum computers, the encryption community 00:46:48.080 --> 00:46:51.080 align:middle line:90% has turned to polynomials. 00:46:51.080 --> 00:46:54.680 align:middle line:90% So this part is the same. 00:46:54.680 --> 00:46:58.020 align:middle line:90% It was Z a minute ago. 00:46:58.020 --> 00:47:01.040 align:middle line:84% Z to the n, this is like F to the q, 00:47:01.040 --> 00:47:04.020 align:middle line:84% are these sets of integers that always include 0. 00:47:04.020 --> 00:47:10.240 align:middle line:84% In this case, when q is 1, F2 is basically 0, 1. 00:47:10.240 --> 00:47:17.040 align:middle line:84% F11, we kind of saw that a moment ago, 0 plus the first 10 00:47:17.040 --> 00:47:21.440 align:middle line:90% integers, F23, et cetera. 00:47:21.440 --> 00:47:25.480 align:middle line:90% So we choose a field. 00:47:25.480 --> 00:47:30.480 align:middle line:84% And then these numbers in a given field 00:47:30.480 --> 00:47:35.360 align:middle line:84% become the coefficients for a polynomial. 00:47:35.360 --> 00:47:38.960 align:middle line:84% So this, for example, is a polynomial 00:47:38.960 --> 00:47:44.480 align:middle line:84% where the largest power is n minus 1, 00:47:44.480 --> 00:47:48.620 align:middle line:84% and it has a constant term out here. 00:47:48.620 --> 00:47:57.690 align:middle line:84% So it has n terms, but n minus 1 powers. 00:47:57.690 --> 00:48:02.490 align:middle line:84% And then these numbers, the little a's, are basically 00:48:02.490 --> 00:48:09.850 align:middle line:84% going to be determined by objects drawn from these fields. 00:48:09.850 --> 00:48:12.530 align:middle line:90% And where's the modulus? 00:48:12.530 --> 00:48:15.170 align:middle line:84% It's not so obvious from this slide, 00:48:15.170 --> 00:48:23.350 align:middle line:84% but you could have a polynomial like this one and multiply it, 00:48:23.350 --> 00:48:26.690 align:middle line:84% and we're going to get a much larger power, 00:48:26.690 --> 00:48:31.130 align:middle line:84% but the modulus is going to be another polynomial, like x 00:48:31.130 --> 00:48:33.550 align:middle line:90% to the n plus 1. 00:48:33.550 --> 00:48:35.490 align:middle line:84% So this is going to reduce the power, 00:48:35.490 --> 00:48:39.570 align:middle line:84% keep control over the highest power in the polynomial 00:48:39.570 --> 00:48:41.070 align:middle line:90% by virtue of division. 00:48:41.070 --> 00:48:44.490 align:middle line:90% 00:48:44.490 --> 00:48:48.050 align:middle line:84% What's not on the slide here, although I was reviewing it 00:48:48.050 --> 00:48:52.290 align:middle line:84% this morning, is something called ring learning with error, 00:48:52.290 --> 00:48:56.010 align:middle line:84% and it builds on these polynomial schemes. 00:48:56.010 --> 00:49:00.290 align:middle line:84% So you have small polynomials, and you also 00:49:00.290 --> 00:49:02.970 align:middle line:90% have random polynomials. 00:49:02.970 --> 00:49:13.810 align:middle line:84% And you start generating the sums of polynomials with these-- 00:49:13.810 --> 00:49:20.110 align:middle line:84% have in addition the addition of these randomly chosen terms. 00:49:20.110 --> 00:49:22.850 align:middle line:90% 00:49:22.850 --> 00:49:27.130 align:middle line:84% And it gets out of control really quickly. 00:49:27.130 --> 00:49:29.930 align:middle line:84% And in particular, computationally it kind of 00:49:29.930 --> 00:49:33.210 align:middle line:84% gets out of control depending on how many operations 00:49:33.210 --> 00:49:36.650 align:middle line:84% you're doing because you're throwing an error term, error 00:49:36.650 --> 00:49:40.610 align:middle line:90% polynomial into every operation. 00:49:40.610 --> 00:49:45.250 align:middle line:84% And so you could start with the error term 00:49:45.250 --> 00:49:49.730 align:middle line:84% being small, just enough to cloud up the true answer, 00:49:49.730 --> 00:49:53.750 align:middle line:84% but it can compound itself and get bigger and bigger. 00:49:53.750 --> 00:49:57.950 align:middle line:84% So a lot of the modern encryption, as I understand it, 00:49:57.950 --> 00:50:02.050 align:middle line:84% is ways to put bounds on the size of the error term. 00:50:02.050 --> 00:50:04.930 align:middle line:84% Sometimes they use the word "bootstrapping" 00:50:04.930 --> 00:50:09.010 align:middle line:84% to mean they kind of stop the process and start taking out 00:50:09.010 --> 00:50:13.310 align:middle line:84% some of the accumulated error and then they start it up again 00:50:13.310 --> 00:50:14.970 align:middle line:90% and so on. 00:50:14.970 --> 00:50:16.610 align:middle line:84% So hopefully you're happy that I'm not 00:50:16.610 --> 00:50:19.370 align:middle line:90% going through all of that. 00:50:19.370 --> 00:50:24.170 align:middle line:84% But the outcome of doing this is to generate 00:50:24.170 --> 00:50:29.090 align:middle line:84% something which is quantum-proof, quantum 00:50:29.090 --> 00:50:30.850 align:middle line:90% computing-proof. 00:50:30.850 --> 00:50:35.370 align:middle line:84% And an intuition for that has to do with having 00:50:35.370 --> 00:50:39.290 align:middle line:90% multiple generations. 00:50:39.290 --> 00:50:43.270 align:middle line:84% Depending on the power term of the polynomial, 00:50:43.270 --> 00:50:49.050 align:middle line:84% you could think, for example, of having multiple agents 00:50:49.050 --> 00:50:51.920 align:middle line:84% in control of each one of the coefficients. 00:50:51.920 --> 00:50:55.180 align:middle line:84% So even if you crack the code on one of them, 00:50:55.180 --> 00:50:59.800 align:middle line:84% you haven't got all the other ones. 00:50:59.800 --> 00:51:02.380 align:middle line:90% 00:51:02.380 --> 00:51:05.820 align:middle line:84% So it's a kind of a decentralization that, 00:51:05.820 --> 00:51:08.420 align:middle line:84% for reasons I don't really understand, 00:51:08.420 --> 00:51:11.900 align:middle line:90% survives quantum computing. 00:51:11.900 --> 00:51:14.000 align:middle line:90% OK. 00:51:14.000 --> 00:51:16.660 align:middle line:84% Next, some more general concepts, 00:51:16.660 --> 00:51:18.580 align:middle line:90% homomorphic encryption. 00:51:18.580 --> 00:51:21.940 align:middle line:84% OK, so the basic idea with homomorphic encryption 00:51:21.940 --> 00:51:24.540 align:middle line:84% is, again, the mathematics, you have 00:51:24.540 --> 00:51:27.660 align:middle line:84% an isomorphism between two structures, 00:51:27.660 --> 00:51:31.780 align:middle line:84% a mapping from one to the other; and the reverse, 00:51:31.780 --> 00:51:33.980 align:middle line:90% the other to one. 00:51:33.980 --> 00:51:37.580 align:middle line:84% You have direct and inverse mappings. 00:51:37.580 --> 00:51:40.380 align:middle line:84% If the two structures are algebraic, 00:51:40.380 --> 00:51:43.660 align:middle line:84% these isomorphic mappings are termed homomorphic 00:51:43.660 --> 00:51:47.860 align:middle line:84% if it's one to one, so that every element in the domain 00:51:47.860 --> 00:51:53.220 align:middle line:84% has a representive in the range and vice versa. 00:51:53.220 --> 00:51:56.960 align:middle line:84% So isomorphic mappings can preserve relationships, 00:51:56.960 --> 00:52:00.460 align:middle line:84% and that's going to allow us go from the true underlying message 00:52:00.460 --> 00:52:05.940 align:middle line:84% spaces to encrypted spaces being able to do operations 00:52:05.940 --> 00:52:09.900 align:middle line:84% on the encrypted space even you don't know what the objects are 00:52:09.900 --> 00:52:12.700 align:middle line:90% and preserve the outcome. 00:52:12.700 --> 00:52:16.220 align:middle line:84% In particular, then, in terms of notation, 00:52:16.220 --> 00:52:20.700 align:middle line:84% we have, say, a message little m, 00:52:20.700 --> 00:52:23.500 align:middle line:84% and the mechanism design problem wants 00:52:23.500 --> 00:52:30.260 align:middle line:84% to operate it with a function f, like a risk-sharing contract 00:52:30.260 --> 00:52:31.160 align:middle line:90% or whatever. 00:52:31.160 --> 00:52:35.140 align:middle line:90% 00:52:35.140 --> 00:52:37.900 align:middle line:84% But the sender of the message may 00:52:37.900 --> 00:52:44.080 align:middle line:84% be worried that she'll reveal something, so it gets encrypted. 00:52:44.080 --> 00:52:48.830 align:middle line:84% Encrypted value of m now operates on the encrypted value. 00:52:48.830 --> 00:52:52.310 align:middle line:84% It turns out that with this isomorphism, 00:52:52.310 --> 00:52:55.790 align:middle line:84% it's equivalent with the encrypted value of f of m. 00:52:55.790 --> 00:53:01.310 align:middle line:84% Both sides of this equation are in the encrypted space. 00:53:01.310 --> 00:53:05.870 align:middle line:84% So here, you wait till you have f and you encrypt it, 00:53:05.870 --> 00:53:12.230 align:middle line:84% or our real goal is to encrypt m, have f operate on it. 00:53:12.230 --> 00:53:15.270 align:middle line:84% Because it's already encrypted, f of the encrypted value 00:53:15.270 --> 00:53:18.070 align:middle line:90% will be in the encrypted space. 00:53:18.070 --> 00:53:24.550 align:middle line:84% Thinking-- so this is true under homomorphic-- 00:53:24.550 --> 00:53:29.350 align:middle line:84% fully homomorphic encryption, another way to look at it 00:53:29.350 --> 00:53:34.770 align:middle line:84% is to decipher the left-hand side. 00:53:34.770 --> 00:53:38.510 align:middle line:90% 00:53:38.510 --> 00:53:44.430 align:middle line:84% So if you take m, encrypt it so it's private, 00:53:44.430 --> 00:53:47.670 align:middle line:84% have f operate on it in the smart contract, 00:53:47.670 --> 00:53:49.250 align:middle line:90% you get an encrypted number. 00:53:49.250 --> 00:53:54.350 align:middle line:84% You then decipher that number, and it's 00:53:54.350 --> 00:53:57.690 align:middle line:84% like an inverse operator, you're going to get-- 00:53:57.690 --> 00:54:01.470 align:middle line:90% 00:54:01.470 --> 00:54:02.890 align:middle line:90% let's look at it this way. 00:54:02.890 --> 00:54:08.710 align:middle line:84% If you decipher the encrypted value of f of m, 00:54:08.710 --> 00:54:12.410 align:middle line:84% you're going to get f of m as the answer at the end. 00:54:12.410 --> 00:54:18.950 align:middle line:84% So you'll see f of m, but you won't see m. 00:54:18.950 --> 00:54:20.510 align:middle line:84% ElGamal, we've been going through, 00:54:20.510 --> 00:54:24.790 align:middle line:84% is an example of homomorphic encryption. 00:54:24.790 --> 00:54:28.230 align:middle line:90% What is multi-party computation? 00:54:28.230 --> 00:54:34.630 align:middle line:84% Also called secret sharing or secure sharing. 00:54:34.630 --> 00:54:38.810 align:middle line:84% It refers specifically to having multiple participants. 00:54:38.810 --> 00:54:44.010 align:middle line:84% In this case, you may recognize these names, Andrew, Susan, 00:54:44.010 --> 00:54:45.150 align:middle line:90% Vinod. 00:54:45.150 --> 00:54:47.990 align:middle line:90% Andrew is Andrew Low. 00:54:47.990 --> 00:54:51.230 align:middle line:90% Vinod, last name is escaping me. 00:54:51.230 --> 00:54:53.590 align:middle line:90% So it's not deep science. 00:54:53.590 --> 00:55:00.510 align:middle line:84% S's denote the private data, the secret, so to speak. 00:55:00.510 --> 00:55:04.950 align:middle line:84% And the x's are these randomly chosen numbers that 00:55:04.950 --> 00:55:08.710 align:middle line:90% cloud up what the s really is. 00:55:08.710 --> 00:55:12.230 align:middle line:84% I don't know whether it's a good or bad example. 00:55:12.230 --> 00:55:18.270 align:middle line:84% The secret sharing, people refer to people in a room, 00:55:18.270 --> 00:55:23.110 align:middle line:84% they're all really filthy rich, and they really 00:55:23.110 --> 00:55:25.470 align:middle line:84% want to know who the richest one is, 00:55:25.470 --> 00:55:31.830 align:middle line:84% but they don't want to reveal their wealth. 00:55:31.830 --> 00:55:35.270 align:middle line:90% So anyway. 00:55:35.270 --> 00:55:38.950 align:middle line:84% So Andrew clouds up his wealth-- or his line item 00:55:38.950 --> 00:55:41.290 align:middle line:90% on a balance sheet by x. 00:55:41.290 --> 00:55:44.080 align:middle line:84% He sends it to Susan in this order. 00:55:44.080 --> 00:55:48.280 align:middle line:84% Susan takes that output, which is obscure to her due to the x, 00:55:48.280 --> 00:55:53.160 align:middle line:84% and adds in her secret information, and a new noise, 00:55:53.160 --> 00:55:56.960 align:middle line:84% and so on up the chain it gets to the last person who 00:55:56.960 --> 00:56:01.320 align:middle line:84% builds on the previous sum to add his or her-- 00:56:01.320 --> 00:56:04.720 align:middle line:84% his, in this case, secret plus noise. 00:56:04.720 --> 00:56:07.880 align:middle line:84% And then-- so you have the sum of secrets 00:56:07.880 --> 00:56:10.720 align:middle line:84% and the sum of noises at this point. 00:56:10.720 --> 00:56:13.520 align:middle line:90% Then it goes back to Andrew. 00:56:13.520 --> 00:56:16.060 align:middle line:84% So Andrew says, well, I don't know what this object is, 00:56:16.060 --> 00:56:20.800 align:middle line:84% but I'll take out of it the noise that I put into it. 00:56:20.800 --> 00:56:24.800 align:middle line:84% And then Susan takes out of it the noise she put into it. 00:56:24.800 --> 00:56:27.980 align:middle line:84% And you end up with Vinod at the end, 00:56:27.980 --> 00:56:32.180 align:middle line:84% who can publish the result, which-- 00:56:32.180 --> 00:56:34.900 align:middle line:84% because all the noises are now eliminated, 00:56:34.900 --> 00:56:40.480 align:middle line:90% is the sum of the secrets. 00:56:40.480 --> 00:56:46.120 align:middle line:84% It is the average wealth, so to speak, of people in the room, 00:56:46.120 --> 00:56:49.920 align:middle line:84% it's just this last number that Vinod publishes 00:56:49.920 --> 00:56:52.600 align:middle line:84% divided by n, n being the number of people here 00:56:52.600 --> 00:56:53.968 align:middle line:90% to get the average. 00:56:53.968 --> 00:56:55.260 align:middle line:90% AUDIENCE: How do you know who-- 00:56:55.260 --> 00:56:57.510 align:middle line:84% ROBERT TOWNSEND: Yeah, I should have said the average. 00:56:57.510 --> 00:57:01.440 align:middle line:90% 00:57:01.440 --> 00:57:03.120 align:middle line:84% Well, at least you'd know if you're 00:57:03.120 --> 00:57:04.503 align:middle line:90% above or below the average. 00:57:04.503 --> 00:57:05.420 align:middle line:90% AUDIENCE: That's true. 00:57:05.420 --> 00:57:07.960 align:middle line:90% 00:57:07.960 --> 00:57:09.880 align:middle line:90% ROBERT TOWNSEND: OK. 00:57:09.880 --> 00:57:12.260 align:middle line:90% Now, this isn't costless. 00:57:12.260 --> 00:57:15.120 align:middle line:84% There's a lot of back-and-forth messages going 00:57:15.120 --> 00:57:19.200 align:middle line:90% on here among these agents. 00:57:19.200 --> 00:57:24.600 align:middle line:84% And in practice, it looks simple because we're not doing it 00:57:24.600 --> 00:57:26.920 align:middle line:90% in encrypted spaces, but-- 00:57:26.920 --> 00:57:27.420 align:middle line:90% OK. 00:57:27.420 --> 00:57:31.560 align:middle line:90% So this we did, MPC we just did. 00:57:31.560 --> 00:57:35.560 align:middle line:84% Just want to say, you can operate on F2, 00:57:35.560 --> 00:57:37.520 align:middle line:90% you'd have a function g. 00:57:37.520 --> 00:57:42.090 align:middle line:84% You have m producing f, and then some g 00:57:42.090 --> 00:57:45.770 align:middle line:84% composed on f, and that's what you really want, 00:57:45.770 --> 00:57:48.230 align:middle line:90% and you encrypt it. 00:57:48.230 --> 00:57:51.010 align:middle line:84% So this would be the outcome of an encrypted space, 00:57:51.010 --> 00:57:55.250 align:middle line:84% and that could be generated by, for example, having m encrypted 00:57:55.250 --> 00:57:58.870 align:middle line:84% into f and then operating on g, or, if you want, 00:57:58.870 --> 00:58:00.650 align:middle line:84% you could just have f of m running 00:58:00.650 --> 00:58:03.810 align:middle line:84% on the side in some private survey 00:58:03.810 --> 00:58:06.750 align:middle line:84% and then encrypt that and have g operating. 00:58:06.750 --> 00:58:09.950 align:middle line:84% All three of these things are the same object, 00:58:09.950 --> 00:58:11.670 align:middle line:84% so when you start deciphering them, 00:58:11.670 --> 00:58:14.450 align:middle line:84% because these objects are in encrypted space, 00:58:14.450 --> 00:58:22.530 align:middle line:84% you get, for example, g of f m back without having ever seen m. 00:58:22.530 --> 00:58:26.770 align:middle line:84% And I will say that next time, I'll go through examples-- 00:58:26.770 --> 00:58:31.250 align:middle line:84% economic applications, auctions and risk-sharing 00:58:31.250 --> 00:58:34.130 align:middle line:84% with private values and so on to see 00:58:34.130 --> 00:58:37.970 align:middle line:84% how multi-party computation and homomorphic encryption 00:58:37.970 --> 00:58:39.270 align:middle line:90% end up getting used. 00:58:39.270 --> 00:58:39.770 align:middle line:90% OK. 00:58:39.770 --> 00:58:44.450 align:middle line:84% Finally, zero-knowledge proofs is another concept. 00:58:44.450 --> 00:58:47.410 align:middle line:84% How can a prover convince a verifier 00:58:47.410 --> 00:58:50.810 align:middle line:84% that she or he knows something without ever revealing what 00:58:50.810 --> 00:58:54.370 align:middle line:90% that knowledge actually is? 00:58:54.370 --> 00:58:57.170 align:middle line:84% And that could be needed when we have pre-existing accounts 00:58:57.170 --> 00:59:00.370 align:middle line:84% on ledgers and wish to keep some secrets, 00:59:00.370 --> 00:59:03.610 align:middle line:84% like transfers among the ledgers. 00:59:03.610 --> 00:59:06.210 align:middle line:84% I'll come back to that in the last slide. 00:59:06.210 --> 00:59:09.170 align:middle line:84% So the idea here was zero-knowledge proof 00:59:09.170 --> 00:59:13.630 align:middle line:84% is for the one, party prover, to convince the other one, 00:59:13.630 --> 00:59:17.490 align:middle line:84% the verifier, that the prover knows something 00:59:17.490 --> 00:59:23.050 align:middle line:84% without ever revealing exactly what that knowledge is. 00:59:23.050 --> 00:59:27.810 align:middle line:84% The worry is not about the prover, 00:59:27.810 --> 00:59:31.490 align:middle line:84% the worry is the verifier, if she or he learns something 00:59:31.490 --> 00:59:37.410 align:middle line:84% in the process, could do something evil 00:59:37.410 --> 00:59:40.500 align:middle line:90% with that information. 00:59:40.500 --> 00:59:46.100 align:middle line:84% There's an example here, but it's a bit misleading 00:59:46.100 --> 00:59:50.660 align:middle line:84% because, in effect, it's like giving up your secret key, which 00:59:50.660 --> 00:59:54.260 align:middle line:84% is more meant to be here to say this is not 00:59:54.260 --> 00:59:56.740 align:middle line:84% as straightforward to come up with these zero-knowledge 00:59:56.740 --> 00:59:57.580 align:middle line:90% proofs. 00:59:57.580 --> 00:59:59.780 align:middle line:90% There are two examples. 00:59:59.780 --> 01:00:08.620 align:middle line:84% One is there's a pen which the prover knows is a special pen, 01:00:08.620 --> 01:00:12.940 align:middle line:84% and the prover can actually see something 01:00:12.940 --> 01:00:16.340 align:middle line:84% on the pen that's obscure to the verifier. 01:00:16.340 --> 01:00:19.860 align:middle line:84% And there are two pens, one with the special markings 01:00:19.860 --> 01:00:25.060 align:middle line:84% that the verifier can't see and the other one is bogus. 01:00:25.060 --> 01:00:28.660 align:middle line:84% And so the prover says, I know which is the real pen. 01:00:28.660 --> 01:00:31.580 align:middle line:84% And so the pens are given to the verifier, 01:00:31.580 --> 01:00:38.260 align:middle line:84% and he or she changes the order or not in her hand, 01:00:38.260 --> 01:00:42.100 align:middle line:84% and puts them out and shows them to the prover, 01:00:42.100 --> 01:00:44.220 align:middle line:90% and the prover picks-- 01:00:44.220 --> 01:00:46.940 align:middle line:84% I mean, I'm sorry, I should have said the start of this thing 01:00:46.940 --> 01:00:50.740 align:middle line:84% is that the prover says that's the special pen, 01:00:50.740 --> 01:00:54.420 align:middle line:84% and the verifier says, OK, I have to take your word for it, 01:00:54.420 --> 01:00:56.780 align:middle line:84% then shows the pens, and it is the one 01:00:56.780 --> 01:00:58.600 align:middle line:90% that was previously designated. 01:00:58.600 --> 01:01:03.820 align:middle line:84% Now that could have happened by chance, 50/50, 01:01:03.820 --> 01:01:07.340 align:middle line:84% that the left hand actually was the hand holding the special 01:01:07.340 --> 01:01:07.880 align:middle line:90% pen. 01:01:07.880 --> 01:01:12.260 align:middle line:84% So they do it again and again each time. 01:01:12.260 --> 01:01:14.640 align:middle line:84% The verifier does not know anything more, 01:01:14.640 --> 01:01:16.200 align:middle line:90% it's an independent experiment. 01:01:16.200 --> 01:01:17.980 align:middle line:84% But you can see, asymptotically, she 01:01:17.980 --> 01:01:20.660 align:middle line:84% would get convinced that the prover really 01:01:20.660 --> 01:01:24.840 align:middle line:84% knows which is the right pen, but she never ends up knowing. 01:01:24.840 --> 01:01:28.420 align:middle line:90% 01:01:28.420 --> 01:01:33.140 align:middle line:84% Another example has to do with coloring nodes 01:01:33.140 --> 01:01:38.780 align:middle line:84% in a network in such a way that any edge connecting two nodes 01:01:38.780 --> 01:01:40.880 align:middle line:84% is supposed to be of a different color 01:01:40.880 --> 01:01:43.020 align:middle line:90% and you only have three colors. 01:01:43.020 --> 01:01:44.580 align:middle line:90% So this turns out-- 01:01:44.580 --> 01:01:47.360 align:middle line:84% I don't know if you covered this in your CS classes. 01:01:47.360 --> 01:01:51.600 align:middle line:84% This is a well-known hard problem, 01:01:51.600 --> 01:01:54.140 align:middle line:84% but someone claims to have the solution. 01:01:54.140 --> 01:01:57.500 align:middle line:84% So again, it's like, OK, here's-- 01:01:57.500 --> 01:02:01.300 align:middle line:84% I have my map, you get to pick two nodes. 01:02:01.300 --> 01:02:07.748 align:middle line:84% So then that is revealed, and the edge is there, 01:02:07.748 --> 01:02:09.040 align:middle line:90% but they're of different color. 01:02:09.040 --> 01:02:11.940 align:middle line:84% OK, so maybe that was a fluky part 01:02:11.940 --> 01:02:14.160 align:middle line:84% of the network that was colored correctly, 01:02:14.160 --> 01:02:19.100 align:middle line:84% and so you do it again independently a different edge. 01:02:19.100 --> 01:02:21.980 align:middle line:84% The colors are changed in the process 01:02:21.980 --> 01:02:24.020 align:middle line:84% every time because once you have the solution, 01:02:24.020 --> 01:02:28.060 align:middle line:84% you can color pink versus yellow, doesn't matter. 01:02:28.060 --> 01:02:33.140 align:middle line:84% And so the verifier gets convinced. 01:02:33.140 --> 01:02:39.790 align:middle line:84% Another-- it's called zk, zero-knowledge, proof 01:02:39.790 --> 01:02:48.510 align:middle line:84% is associated with Neha, who's over at DCI, 01:02:48.510 --> 01:02:53.670 align:middle line:84% and this applies for ledgers, are one of our favorite objects. 01:02:53.670 --> 01:02:59.190 align:middle line:84% So these are transactions on ledgers among Goldman Sachs, JP 01:02:59.190 --> 01:03:02.870 align:middle line:84% Morgan, and Barclays, transfers from one 01:03:02.870 --> 01:03:06.710 align:middle line:84% account to another, except that none of these three guys 01:03:06.710 --> 01:03:11.110 align:middle line:84% wants to reveal all of this, not even to the regulators. 01:03:11.110 --> 01:03:15.990 align:middle line:84% Say the regulators only want to make sure that transactions 01:03:15.990 --> 01:03:20.270 align:middle line:84% are balanced, that the sum of what came in 01:03:20.270 --> 01:03:23.610 align:middle line:84% minus the sum of what went out from one of these accounts 01:03:23.610 --> 01:03:25.710 align:middle line:90% is zero. 01:03:25.710 --> 01:03:29.030 align:middle line:90% They're not double-spending. 01:03:29.030 --> 01:03:31.670 align:middle line:90% So how do you-- 01:03:31.670 --> 01:03:36.590 align:middle line:84% v is the value of each one of these transactions. 01:03:36.590 --> 01:03:38.230 align:middle line:84% Each one of those transactions is 01:03:38.230 --> 01:03:43.670 align:middle line:84% going to get obscured with two generators, g and h. 01:03:43.670 --> 01:03:47.570 align:middle line:84% One, g, takes the value v as the power. 01:03:47.570 --> 01:03:52.230 align:middle line:84% The other one, h, takes r as a arbitrarily chosen random number 01:03:52.230 --> 01:03:55.630 align:middle line:84% from ElGamal-type considerations. 01:03:55.630 --> 01:04:01.050 align:middle line:84% And this product to powers is called a commitment. 01:04:01.050 --> 01:04:04.150 align:middle line:90% It's a Pedersen commitment. 01:04:04.150 --> 01:04:09.470 align:middle line:84% And in more detail, you have a cyclic ring-- sound familiar? 01:04:09.470 --> 01:04:11.070 align:middle line:84% With a certain number of elements. 01:04:11.070 --> 01:04:15.310 align:middle line:84% g and h are both generators in that group G. 01:04:15.310 --> 01:04:19.430 align:middle line:84% And a commitment to these values that 01:04:19.430 --> 01:04:25.070 align:middle line:84% are transformed to lie in the space G 01:04:25.070 --> 01:04:28.110 align:middle line:84% is done, again, by taking these products. 01:04:28.110 --> 01:04:33.900 align:middle line:84% A very useful property is that it's additively homomorphic. 01:04:33.900 --> 01:04:40.880 align:middle line:84% So in this case, it's specificly limited. 01:04:40.880 --> 01:04:44.040 align:middle line:84% They can get what they want with additivity, 01:04:44.040 --> 01:04:45.620 align:middle line:90% so what's going on here? 01:04:45.620 --> 01:04:51.560 align:middle line:84% So you take these commitments, you 01:04:51.560 --> 01:04:54.400 align:middle line:84% take the product of two transactions-- 01:04:54.400 --> 01:04:58.720 align:middle line:90% that's another ciphertext. 01:04:58.720 --> 01:05:03.000 align:middle line:84% It's a commitment to the sum of the values, not the values 01:05:03.000 --> 01:05:04.480 align:middle line:90% individually. 01:05:04.480 --> 01:05:08.840 align:middle line:84% It's randomized by the sum of the random numbers. 01:05:08.840 --> 01:05:13.580 align:middle line:84% Basically commitment 1 is g to the v1, h to the r1; 01:05:13.580 --> 01:05:16.680 align:middle line:84% commitment 2 is g to the v2 h to the r2. 01:05:16.680 --> 01:05:20.040 align:middle line:84% You multiply those commitments together, 01:05:20.040 --> 01:05:24.640 align:middle line:84% which is equivalent with adding the powers. 01:05:24.640 --> 01:05:28.200 align:middle line:84% So you get the sum of the v's and the sum of the r's. 01:05:28.200 --> 01:05:34.280 align:middle line:84% Now you could reveal the sum of the r's to the regulator, 01:05:34.280 --> 01:05:38.760 align:middle line:84% who would then be able to back out the sum of the values. 01:05:38.760 --> 01:05:43.360 align:middle line:84% Revealing the sum doesn't reveal the individual numbers. 01:05:43.360 --> 01:05:46.280 align:middle line:84% So the underlying individual transaction values 01:05:46.280 --> 01:05:49.640 align:middle line:84% are still concealed, but the regulator 01:05:49.640 --> 01:05:55.320 align:middle line:84% can be assured that there is no double-spending. 01:05:55.320 --> 01:05:59.880 align:middle line:84% OK, so I promised to go back to Bitcoin. 01:05:59.880 --> 01:06:07.200 align:middle line:84% And again, we've got the picture of the Merkle tree 01:06:07.200 --> 01:06:09.980 align:middle line:90% of these values. 01:06:09.980 --> 01:06:13.520 align:middle line:84% So it's a block that are chained together. 01:06:13.520 --> 01:06:19.060 align:middle line:84% The blocks have a header on the top of, say, the structure. 01:06:19.060 --> 01:06:21.200 align:middle line:84% The rest of it has to do with the transactions, 01:06:21.200 --> 01:06:22.900 align:middle line:90% the number, the count. 01:06:22.900 --> 01:06:26.580 align:middle line:84% The header actually contains a lot of the information. 01:06:26.580 --> 01:06:32.500 align:middle line:84% It has the previous block ID, a timestamp, a nonce-- 01:06:32.500 --> 01:06:37.560 align:middle line:84% I'll come back to that, and a difficulty. 01:06:37.560 --> 01:06:40.020 align:middle line:84% Again, we're using the hashing part. 01:06:40.020 --> 01:06:42.640 align:middle line:90% I alluded to this earlier. 01:06:42.640 --> 01:06:45.960 align:middle line:84% So you have all these individual transactions. 01:06:45.960 --> 01:06:49.960 align:middle line:84% Each hash, you take the hash of the sum of the two of them, 01:06:49.960 --> 01:06:53.080 align:middle line:84% another hash, and you make your way back 01:06:53.080 --> 01:06:59.080 align:middle line:84% to the latest route of all of it, 01:06:59.080 --> 01:07:03.200 align:middle line:90% all in a manageable database. 01:07:03.200 --> 01:07:06.120 align:middle line:84% The leaves here are the transactions. 01:07:06.120 --> 01:07:08.680 align:middle line:84% Each node consists of hash of the children 01:07:08.680 --> 01:07:11.240 align:middle line:90% as you go back down the tree. 01:07:11.240 --> 01:07:14.640 align:middle line:84% And changing any transaction in any one of these blocks 01:07:14.640 --> 01:07:20.560 align:middle line:84% would change the route by virtue of the hash. 01:07:20.560 --> 01:07:22.960 align:middle line:90% So where is the nonce? 01:07:22.960 --> 01:07:25.840 align:middle line:84% This hashing-- actually, double-hashing, 01:07:25.840 --> 01:07:29.210 align:middle line:84% you take the block header and you hash it up twice, 01:07:29.210 --> 01:07:34.810 align:middle line:84% and you end up with something-- a 250-bit block ID. 01:07:34.810 --> 01:07:42.530 align:middle line:84% And the nonce is one of the objects in the block header, 01:07:42.530 --> 01:07:45.570 align:middle line:90% so it will change. 01:07:45.570 --> 01:07:50.690 align:middle line:84% If it changes, it changes the double hash. 01:07:50.690 --> 01:07:57.930 align:middle line:84% This nonce controls who wins the deciphering contest. 01:07:57.930 --> 01:08:02.450 align:middle line:84% Say the criterion for winning is that the number, 01:08:02.450 --> 01:08:04.530 align:middle line:84% after all-- the hashing should be smaller 01:08:04.530 --> 01:08:08.490 align:middle line:90% than a certain number. 01:08:08.490 --> 01:08:17.569 align:middle line:90% So for example, 2 to the 187. 01:08:17.569 --> 01:08:24.130 align:middle line:84% Now what is the likelihood of a 256-bit number being that small? 01:08:24.130 --> 01:08:29.290 align:middle line:84% The answer is, it doesn't happen very often. 01:08:29.290 --> 01:08:31.210 align:middle line:90% And the math of it is-- 01:08:31.210 --> 01:08:33.210 align:middle line:90% from Sam is right here. 01:08:33.210 --> 01:08:37.750 align:middle line:84% What does it mean for something to be a 250-bit length? 01:08:37.750 --> 01:08:43.010 align:middle line:84% It just means 2 to the power i for each term i, 1. 01:08:43.010 --> 01:08:44.330 align:middle line:90% 2 to the 1-- 01:08:44.330 --> 01:08:47.330 align:middle line:84% 2 to the 0, 2 to the 1, 2 to the 2, et cetera, et cetera, 01:08:47.330 --> 01:08:51.410 align:middle line:84% and then add it all up at the end, that is equivalent with 2 01:08:51.410 --> 01:08:56.770 align:middle line:90% to the 256 if every bit was 1. 01:08:56.770 --> 01:09:00.609 align:middle line:84% If every bit there turned out to be a 0, 01:09:00.609 --> 01:09:03.130 align:middle line:90% then you end up back in 0. 01:09:03.130 --> 01:09:07.410 align:middle line:84% So how do we get the first 187 bits to be 0? 01:09:07.410 --> 01:09:11.290 align:middle line:84% That's not going to happen very often. 01:09:11.290 --> 01:09:13.810 align:middle line:90% You can ignore this last line. 01:09:13.810 --> 01:09:16.310 align:middle line:84% Deb and I were exchanging slides. 01:09:16.310 --> 01:09:19.130 align:middle line:90% 01:09:19.130 --> 01:09:21.370 align:middle line:84% So hopefully that helps a little bit 01:09:21.370 --> 01:09:25.300 align:middle line:84% in terms of controlling the degree of difficulty 01:09:25.300 --> 01:09:30.979 align:middle line:84% in Bitcoin in validating the transactions. 01:09:30.979 --> 01:09:37.580 align:middle line:84% They're all randomly putting in these numbers in such a way 01:09:37.580 --> 01:09:41.680 align:middle line:84% as to try to get the resulting output to be relatively small, 01:09:41.680 --> 01:09:44.000 align:middle line:84% and that doesn't happen very often, 01:09:44.000 --> 01:09:46.240 align:middle line:90% so it's all trial and error. 01:09:46.240 --> 01:09:49.100 align:middle line:90% 01:09:49.100 --> 01:09:56.040 align:middle line:84% To summarize today a bit, this is something Nicholas found, 01:09:56.040 --> 01:09:57.580 align:middle line:90% it's really quite helpful. 01:09:57.580 --> 01:10:02.560 align:middle line:84% Can sensitive data be revealed after being used in a process? 01:10:02.560 --> 01:10:06.020 align:middle line:84% If the answer is sensitive data could be revealed, 01:10:06.020 --> 01:10:09.300 align:middle line:84% then you can use commit-reveal-type encryption 01:10:09.300 --> 01:10:12.180 align:middle line:90% such as the Pedersen commitment. 01:10:12.180 --> 01:10:13.820 align:middle line:84% Willing to reveal the sum of things, 01:10:13.820 --> 01:10:16.340 align:middle line:90% but not the individual values. 01:10:16.340 --> 01:10:20.500 align:middle line:84% On the other hand, if the answer is can some sensitive data be 01:10:20.500 --> 01:10:25.020 align:middle line:84% revealed is no, then the new question is, can the use of data 01:10:25.020 --> 01:10:29.620 align:middle line:84% entirely consist of a series of proof statements, like is it 01:10:29.620 --> 01:10:32.660 align:middle line:90% true that we have this value f? 01:10:32.660 --> 01:10:36.900 align:middle line:84% Is it true or false when x is the confidential data 01:10:36.900 --> 01:10:38.760 align:middle line:90% and f of s is the statement? 01:10:38.760 --> 01:10:43.300 align:middle line:84% Is it true that f of x, this value, 01:10:43.300 --> 01:10:45.160 align:middle line:90% is that the true value or not? 01:10:45.160 --> 01:10:49.300 align:middle line:84% It's a true/false statement, it's binary. 01:10:49.300 --> 01:10:53.620 align:middle line:84% So that could-- if that is the answer to the second question, 01:10:53.620 --> 01:10:59.100 align:middle line:84% is yes, then you can use zero-knowledge proofs. 01:10:59.100 --> 01:11:04.060 align:middle line:84% On the other hand, if the answer is no, then the new question is, 01:11:04.060 --> 01:11:08.100 align:middle line:84% can the use of data be managed by a single entity? 01:11:08.100 --> 01:11:11.060 align:middle line:84% And if the answer to that is yes, 01:11:11.060 --> 01:11:14.820 align:middle line:84% then you can use homomorphic encryption. 01:11:14.820 --> 01:11:19.340 align:middle line:84% But if the answer to-- no, it can't be a single entity, 01:11:19.340 --> 01:11:22.830 align:middle line:84% then you have to split the data up into several-- 01:11:22.830 --> 01:11:26.350 align:middle line:84% among several entities and you need multi-party computation 01:11:26.350 --> 01:11:29.350 align:middle line:90% for that. 01:11:29.350 --> 01:11:32.670 align:middle line:84% So here, you can see, depending on what you're trying to do 01:11:32.670 --> 01:11:35.470 align:middle line:84% and what the conditions of the application are, 01:11:35.470 --> 01:11:39.670 align:middle line:84% whether you can get by with Pedersen commitments, 01:11:39.670 --> 01:11:45.510 align:middle line:84% or zero-knowledge proofs, or homomorphic encryption, or-- 01:11:45.510 --> 01:11:50.350 align:middle line:84% and whether you need multi-party computation. 01:11:50.350 --> 01:11:52.750 align:middle line:90% OK. 01:11:52.750 --> 01:11:53.430 align:middle line:90% OK. 01:11:53.430 --> 01:11:57.430 align:middle line:84% So I'm over by about three minutes. 01:11:57.430 --> 01:11:58.710 align:middle line:90% Thank you for your patience. 01:11:58.710 --> 01:12:03.050 align:middle line:84% Again, I do understand this is a lot of material, 01:12:03.050 --> 01:12:07.750 align:middle line:84% but that is an overview of modern-day encryption. 01:12:07.750 --> 01:12:10.510 align:middle line:90% I hope you found it helpful. 01:12:10.510 --> 01:12:12.190 align:middle line:84% And next time, we'll actually use it 01:12:12.190 --> 01:12:14.210 align:middle line:90% in some economic applications. 01:12:14.210 --> 01:12:16.020 align:middle line:90% Thank you. 01:12:16.020 --> 01:12:22.000 align:middle line:90%