[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:03.75,Default,,0000,0000,0000,,In this segment, I want to tell you about\Nanother form of encryption, called format
Dialogue: 0,0:00:03.75,0:00:07.32,Default,,0000,0000,0000,,preserving encryption. This is again\Nsomething that comes up in practice quite
Dialogue: 0,0:00:07.32,0:00:10.62,Default,,0000,0000,0000,,often, especially when it comes to\Nencrypting credit card numbers. And, so,
Dialogue: 0,0:00:10.62,0:00:14.24,Default,,0000,0000,0000,,let's see how it works. Remember that a\Ntypical credit card number is sixteen
Dialogue: 0,0:00:14.24,0:00:18.98,Default,,0000,0000,0000,,digits, broken into four blocks of four\Ndigits each. You've probably heard before
Dialogue: 0,0:00:18.98,0:00:23.42,Default,,0000,0000,0000,,that the first six digits are what's\Ncalled the BIN number, which represent the
Dialogue: 0,0:00:23.42,0:00:28.12,Default,,0000,0000,0000,,issuer ID. For example, all credit cards\Nissued by VISA always start with the digit
Dialogue: 0,0:00:28.12,0:00:34.11,Default,,0000,0000,0000,,four; all credit cards issued by\NMasterCard start with digits 51 to 55, and
Dialogue: 0,0:00:34.11,0:00:38.81,Default,,0000,0000,0000,,so on and so forth. The next nine digits\Nare actually the account number that is
Dialogue: 0,0:00:38.81,0:00:43.28,Default,,0000,0000,0000,,specific to the, to the particular\Ncustomer and the last digit is a check sum
Dialogue: 0,0:00:43.28,0:00:48.03,Default,,0000,0000,0000,,that's computed from the previous fifteen\Ndigits. So there are about 20,000 BIN
Dialogue: 0,0:00:48.03,0:00:52.85,Default,,0000,0000,0000,,numbers and so if you do the calculation\Nit turns out there are about 2 to the 42
Dialogue: 0,0:00:52.85,0:00:56.73,Default,,0000,0000,0000,,possible credit card numbers which\Ncorresponds to about 42 bits of
Dialogue: 0,0:00:56.73,0:01:01.49,Default,,0000,0000,0000,,information that you need to encode if you\Nwant to represent a credit card number
Dialogue: 0,0:01:01.49,0:01:05.100,Default,,0000,0000,0000,,compactly. Now the problem is this.\NSuppose we wanted to encrypt credit card
Dialogue: 0,0:01:05.100,0:01:10.71,Default,,0000,0000,0000,,numbers, so that when the user swipes the\Ncredit card number at the point of sale
Dialogue: 0,0:01:10.71,0:01:14.64,Default,,0000,0000,0000,,terminal, namely at the, you know,\Nthe merchant's cash register. The cash
Dialogue: 0,0:01:14.64,0:01:18.67,Default,,0000,0000,0000,,register, this is called a point of sale\Nterminal, goes ahead and encrypts the
Dialogue: 0,0:01:18.67,0:01:22.75,Default,,0000,0000,0000,,credit card number using a key k and\Nit's encrypted all the way until it goes
Dialogue: 0,0:01:22.75,0:01:27.04,Default,,0000,0000,0000,,to the acquiring bank or maybe even beyond\Nthat, maybe even all the way when it goes
Dialogue: 0,0:01:27.04,0:01:31.12,Default,,0000,0000,0000,,to Visa. Now, the problem is that these\Ncredit card numbers actually pass through
Dialogue: 0,0:01:31.12,0:01:35.30,Default,,0000,0000,0000,,many, many, many processing points. All of\Nthem expect to get basically something
Dialogue: 0,0:01:35.30,0:01:39.68,Default,,0000,0000,0000,,that looks like a credit card number as a\Nresult. So if we simply wanted to encrypt
Dialogue: 0,0:01:39.68,0:01:43.89,Default,,0000,0000,0000,,something at the end point, at one end\Npoint, and decrypt it at the other end
Dialogue: 0,0:01:43.89,0:01:48.09,Default,,0000,0000,0000,,point, it's actually not that easy because\Nif all we did was encrypt it using AES,
Dialogue: 0,0:01:48.09,0:01:52.75,Default,,0000,0000,0000,,even if we just used deterministic AES,\Nthe output of the encrypted credit card
Dialogue: 0,0:01:52.75,0:01:57.16,Default,,0000,0000,0000,,number would be 128 bit block. Sixteen\Nbytes that would be, that would need to be
Dialogue: 0,0:01:57.16,0:02:01.69,Default,,0000,0000,0000,,sent from one system to the next, until it\Nreaches its destination. But each one of
Dialogue: 0,0:02:01.69,0:02:06.11,Default,,0000,0000,0000,,these processors, then, would have to be\Nchanged, because they're all expecting to
Dialogue: 0,0:02:06.11,0:02:10.19,Default,,0000,0000,0000,,get credit card numbers. And so the\Nquestion is, can we encrypt at the cash
Dialogue: 0,0:02:10.19,0:02:14.39,Default,,0000,0000,0000,,register, such that the resulting\Nencryption itself looks like a credit card
Dialogue: 0,0:02:14.39,0:02:18.53,Default,,0000,0000,0000,,number. And as a result, none of these\Nintermediate systems would have to be
Dialogue: 0,0:02:18.53,0:02:22.94,Default,,0000,0000,0000,,changed. Only the endpoints would have to\Nbe changed. And in doing so we would
Dialogue: 0,0:02:22.94,0:02:27.40,Default,,0000,0000,0000,,actually obtain end-to-end encryption\Nwithout actually having to change a lot of
Dialogue: 0,0:02:27.40,0:02:31.97,Default,,0000,0000,0000,,software along the way. So the question\Nthen is, again, can we have this mechanism
Dialogue: 0,0:02:31.97,0:02:36.55,Default,,0000,0000,0000,,called format preserving encryption, where\Nencrypting a credit card itself produces
Dialogue: 0,0:02:36.55,0:02:40.88,Default,,0000,0000,0000,,something that looks like a credit card?\NSo that's our goal. The encrypted credit
Dialogue: 0,0:02:40.88,0:02:44.72,Default,,0000,0000,0000,,card number should look like a regular\Nvalid credit card number. So this is the
Dialogue: 0,0:02:44.72,0:02:48.77,Default,,0000,0000,0000,,goal of format preserving encryption. More\Nabstractly what it is we're trying to do,
Dialogue: 0,0:02:48.77,0:02:54.06,Default,,0000,0000,0000,,is basically build a pseudo random\Npermutation on the set zero to S minus one
Dialogue: 0,0:02:54.06,0:02:59.10,Default,,0000,0000,0000,,for any given S. So for the set of credit\Ncard numbers, S would be roughly, you
Dialogue: 0,0:02:59.10,0:03:03.97,Default,,0000,0000,0000,,know, two to the 42. In fact, it's gonna\Nbe, not exactly two to the 42. It's gonna
Dialogue: 0,0:03:03.97,0:03:08.42,Default,,0000,0000,0000,,be some funny numbers that's around two to\Nthe 42. And our goal is to build a PRP
Dialogue: 0,0:03:08.42,0:03:14.33,Default,,0000,0000,0000,,that acts exactly on the interval, zero to\NS minus one. And what we're given as input
Dialogue: 0,0:03:14.33,0:03:20.37,Default,,0000,0000,0000,,is some PRF, say, something like AES, that\Nacts on much larger blocks, say, acts on
Dialogue: 0,0:03:20.37,0:03:24.38,Default,,0000,0000,0000,,sixteen byte blocks. So we're trying to,\Nin some sense, shrink the domain of the
Dialogue: 0,0:03:24.38,0:03:29.58,Default,,0000,0000,0000,,PRF to make it fit the data that we're\Ngiven. And the question is basically how
Dialogue: 0,0:03:29.58,0:03:33.64,Default,,0000,0000,0000,,to do that. Well, once we have such a\Nconstruction we can easily use it to
Dialogue: 0,0:03:33.64,0:03:37.61,Default,,0000,0000,0000,,encrypt credit card numbers. What we would\Ndo is we would take the, a given credit
Dialogue: 0,0:03:37.61,0:03:41.94,Default,,0000,0000,0000,,card number. We would encode it such that\Nnow it's represented as a number between
Dialogue: 0,0:03:41.94,0:03:47.31,Default,,0000,0000,0000,,zero and the total number of credit card\Nnumbers. Then we would apply our PRP so we
Dialogue: 0,0:03:47.31,0:03:51.82,Default,,0000,0000,0000,,would encrypt this credit card number, you\Nknow, using construction number two from
Dialogue: 0,0:03:51.82,0:03:56.43,Default,,0000,0000,0000,,the deterministic encryption segment. And\Nthen we would map the final number back to
Dialogue: 0,0:03:56.43,0:04:00.66,Default,,0000,0000,0000,,be a regular, to look like val--, regular,\Nvalid credit card number and then send
Dialogue: 0,0:04:00.66,0:04:05.08,Default,,0000,0000,0000,,this along the way. So this is, this\Nis again non expanding encryption. The
Dialogue: 0,0:04:05.08,0:04:09.44,Default,,0000,0000,0000,,best we can do, as we said before is to\Nencrypt using a PRP except again the
Dialogue: 0,0:04:09.44,0:04:14.14,Default,,0000,0000,0000,,technical challenge is we need a PRP that\Nacts on this particular funny looking set
Dialogue: 0,0:04:14.14,0:04:19.81,Default,,0000,0000,0000,,from zero to S-1 for this prespecified\Nvalue of S. So my goal is to show you how
Dialogue: 0,0:04:19.81,0:04:23.38,Default,,0000,0000,0000,,to construct this and once we see how to\Ndo it, you will also know how to encrypt
Dialogue: 0,0:04:23.38,0:04:27.74,Default,,0000,0000,0000,,credit card number so that the resulting\Ncipher text is itself a credit card
Dialogue: 0,0:04:27.74,0:04:33.18,Default,,0000,0000,0000,,number. So the construction works in two\Nsteps. The first thing we do is we shrink
Dialogue: 0,0:04:33.18,0:04:38.55,Default,,0000,0000,0000,,our PRF from the set {0,1} to the n, say\N{0,1} to the 128 in the case of AES,
Dialogue: 0,0:04:38.55,0:04:43.96,Default,,0000,0000,0000,,to {0,1} to the t where t is the\Nclosest power of two to the value S.
Dialogue: 0,0:04:44.58,0:04:50.04,Default,,0000,0000,0000,,So say S is some crazy number around two to\Nthe 41. T would basically be then 42
Dialogue: 0,0:04:50.04,0:04:55.34,Default,,0000,0000,0000,,because that's the closest power of two\Nthat's just above the value S. So the
Dialogue: 0,0:04:55.34,0:04:59.40,Default,,0000,0000,0000,,construction is basically gonna use the\NLuby-Rackoff construction. What we need
Dialogue: 0,0:04:59.40,0:05:05.16,Default,,0000,0000,0000,,is a PRF F prime that acts on blocks of\Nsize t over two. So imagine for example
Dialogue: 0,0:05:05.16,0:05:10.10,Default,,0000,0000,0000,,in the credit card case, t would be 42\Nbecause two to the 42 we said is the
Dialogue: 0,0:05:10.30,0:05:15.13,Default,,0000,0000,0000,,closest power of two that's bigger than,\Nthan, than S. S is the number of credit,
Dialogue: 0,0:05:15.13,0:05:20.39,Default,,0000,0000,0000,,total number of credit cards. Then we would\Nneed a PRF now that acts on 21-bit
Dialogue: 0,0:05:20.39,0:05:25.83,Default,,0000,0000,0000,,inputs. So one way to do that is simply to\Ntake the AES block cipher, treat it as a
Dialogue: 0,0:05:25.83,0:05:30.44,Default,,0000,0000,0000,,PRF on 128-bit inputs, and then simply\Ntruncate the output to the least
Dialogue: 0,0:05:30.44,0:05:35.24,Default,,0000,0000,0000,,significant 21 bits. Okay, so we were\Ngiven a 21 bit value. We would append
Dialogue: 0,0:05:35.24,0:05:40.36,Default,,0000,0000,0000,,zeros to it so that we get 128 bits as a\Nresult. We would apply AES to that and
Dialogue: 0,0:05:40.36,0:05:45.02,Default,,0000,0000,0000,,then we would truncate back to 21 bits.\NNow I should tell you that that's actually
Dialogue: 0,0:05:45.02,0:05:48.72,Default,,0000,0000,0000,,a simple way to do it but it's actually\Nnot the best way to do it. There are
Dialogue: 0,0:05:48.72,0:05:54.18,Default,,0000,0000,0000,,actually better ways to truncate a PRF on\Nn bits to a PRF on t over two bits.
Dialogue: 0,0:05:54.18,0:05:58.45,Default,,0000,0000,0000,,But for our pur--, for the purposes of this\Nsegment, the truncation method I just said
Dialogue: 0,0:05:58.63,0:06:03.11,Default,,0000,0000,0000,,is good enough. So let's just use that\Nparticular method. Okay, so now, we've
Dialogue: 0,0:06:03.11,0:06:09.28,Default,,0000,0000,0000,,converted our AES block cipher into a PRF\Non t over two bits, say, on 21 bits. But
Dialogue: 0,0:06:09.28,0:06:14.11,Default,,0000,0000,0000,,what we really want is a PRP. And so what\Nwe'll do is we'll plug our new PRF, F prime,
Dialogue: 0,0:06:14.11,0:06:17.94,Default,,0000,0000,0000,,directly into the Luby-Rackoff\Nconstruction. If you remember, this is
Dialogue: 0,0:06:17.94,0:06:22.49,Default,,0000,0000,0000,,basically a Feistel construction. We saw\Nthis when we talked about DES. It's a,
Dialogue: 0,0:06:22.49,0:06:27.01,Default,,0000,0000,0000,,Luby-Rackoff used three rounds, and we\Nknow that this converts a secure PRF into
Dialogue: 0,0:06:27.01,0:06:31.96,Default,,0000,0000,0000,,a secure PRP on twice the block size. In\Nother words, we started from a secure PRF
Dialogue: 0,0:06:31.96,0:06:36.97,Default,,0000,0000,0000,,on 21 bits, and that will give us, and\NLuby-Rackoff will give us a secure PRF on
Dialogue: 0,0:06:36.97,0:06:41.42,Default,,0000,0000,0000,,42 bits, which is what we wanted. Now, I\Nshould tell you that the error parameters
Dialogue: 0,0:06:41.42,0:06:45.53,Default,,0000,0000,0000,,in the Luby-Rackoff construction are not as\Ngood as they could be. And, in fact, a
Dialogue: 0,0:06:45.53,0:06:49.69,Default,,0000,0000,0000,,better thing to do is to use seven rounds\Nof Feistel. So in other words, we'll do
Dialogue: 0,0:06:49.69,0:06:54.78,Default,,0000,0000,0000,,this seven times; every time we'll use a\Ndifferent key. So you notice, here, we're
Dialogue: 0,0:06:54.78,0:06:59.32,Default,,0000,0000,0000,,only using three keys. We should be using,\Nwe should be doing this seven times using
Dialogue: 0,0:06:59.32,0:07:03.84,Default,,0000,0000,0000,,seven different keys. And then there's a\Nnice result, due to Patarin, that
Dialogue: 0,0:07:03.84,0:07:06.100,Default,,0000,0000,0000,,shows that the seven-round construction\Nbasically has as good an error
Dialogue: 0,0:07:06.100,0:07:11.31,Default,,0000,0000,0000,,terms as possible. So the error terms in\Nthe security theorem will basically be two
Dialogue: 0,0:07:11.31,0:07:15.98,Default,,0000,0000,0000,,to the T. Okay. So now we have a pseudo\Nrandom permutation that operates on close
Dialogue: 0,0:07:15.98,0:07:21.53,Default,,0000,0000,0000,,power of two to the value of S. But that's\Nnot good enough. We actually want to get a
Dialogue: 0,0:07:21.53,0:07:26.70,Default,,0000,0000,0000,,pseudo random permutation on the set zero\Nto S minus one. So step two will take us
Dialogue: 0,0:07:26.70,0:07:30.77,Default,,0000,0000,0000,,down from {0,1} to the T, to the actual\Nset zero to the S minus one that we're
Dialogue: 0,0:07:30.77,0:07:35.14,Default,,0000,0000,0000,,interested in. And this construction is,\Nagain, really, really cute, so let me show
Dialogue: 0,0:07:35.14,0:07:39.07,Default,,0000,0000,0000,,you how it works. So, again, we're given\Nthis PRP that operates on a power of two.
Dialogue: 0,0:07:39.07,0:07:44.36,Default,,0000,0000,0000,,And we wanna go down to a PRP that\Noperates on something slightly smaller.
Dialogue: 0,0:07:44.36,0:07:49.24,Default,,0000,0000,0000,,Okay, so here's on the construction works.\NBasically we're given input X in the set
Dialogue: 0,0:07:49.24,0:07:53.15,Default,,0000,0000,0000,,zero to S minus one that we want. And what\Nwe're going to do is we're going to
Dialogue: 0,0:07:53.15,0:07:57.44,Default,,0000,0000,0000,,iterate the following procedure again\Nand again. So first of all we map X into
Dialogue: 0,0:07:57.44,0:08:02.48,Default,,0000,0000,0000,,this temporary variable Y. And now we're\Njust gonna encrypt the input X and put the
Dialogue: 0,0:08:02.48,0:08:07.21,Default,,0000,0000,0000,,result into Y. If Y is inside of our\Ntarget set, we stop and we output Y. If
Dialogue: 0,0:08:07.21,0:08:12.46,Default,,0000,0000,0000,,not we iterate this again and again and\Nagain and again and again until finally Y
Dialogue: 0,0:08:12.46,0:08:16.70,Default,,0000,0000,0000,,falls into our target set and then we\Noutput that value. So in a picture, let me
Dialogue: 0,0:08:16.70,0:08:22.51,Default,,0000,0000,0000,,explain how this works. So we start from a\Npoint in our target set. And now, now we
Dialogue: 0,0:08:22.51,0:08:27.27,Default,,0000,0000,0000,,apply the, the function E and we might be\Nmapped into this point outside our target
Dialogue: 0,0:08:27.27,0:08:30.87,Default,,0000,0000,0000,,set, so we're not gonna stop. So now we\Napply the function E again and we might
Dialogue: 0,0:08:30.87,0:08:35.05,Default,,0000,0000,0000,,be mapped into this point and now we apply\Nthe function E again and now all of a
Dialogue: 0,0:08:35.05,0:08:39.12,Default,,0000,0000,0000,,sudden we map into this point, and then we\Nstop, and that's our output. Okay, so
Dialogue: 0,0:08:39.12,0:08:44.20,Default,,0000,0000,0000,,that's how we map points between from zero\Nto S minus one, to other points in the
Dialogue: 0,0:08:44.20,0:08:48.49,Default,,0000,0000,0000,,zero to S minus one. It should be pretty\Nclear that this is invertible. To invert,
Dialogue: 0,0:08:48.49,0:08:52.47,Default,,0000,0000,0000,,all I'll do is I'll just decrypt and walk,\Nkind of, in the opposite direction. So
Dialogue: 0,0:08:52.47,0:08:56.34,Default,,0000,0000,0000,,I'll decrypt, and then decrypt, and then\Ndecrypt, until finally, I fall into the
Dialogue: 0,0:08:56.34,0:09:00.42,Default,,0000,0000,0000,,set, zero to S minus one. And that gives\Nme the inverse of the point that I wanted
Dialogue: 0,0:09:00.42,0:09:04.62,Default,,0000,0000,0000,,to. So this is, in fact, a PRP. The\Nquestion is whether it's a secure PRP, and
Dialogue: 0,0:09:04.62,0:09:08.74,Default,,0000,0000,0000,,we'll see that in just a minute. But before \Nthat, let me ask you, how many iterations
Dialogue: 0,0:09:08.74,0:09:13.32,Default,,0000,0000,0000,,do you expect that we're gonna need? And \NI wanna remind you again, before I ask you
Dialogue: 0,0:09:13.32,0:09:19.64,Default,,0000,0000,0000,,that question, that, in fact, S is less than \Ntwo to the T, but is more than two to the T-1.
Dialogue: 0,0:09:19.64,0:09:25.09,Default,,0000,0000,0000,,So in particular S is greater than two to \Nthe T over two. And my question to you
Dialogue: 0,0:09:25.09,0:09:29.66,Default,,0000,0000,0000,,now is how many iterations are we gonna \Nneed, on average, until this process converges?
Dialogue: 0,0:09:32.91,0:09:35.08,Default,,0000,0000,0000,,So the answer is we're going to need two iterations,
Dialogue: 0,0:09:35.08,0:09:38.98,Default,,0000,0000,0000,,so really just a small\Nconstant number of iterations. And so this
Dialogue: 0,0:09:38.98,0:09:43.16,Default,,0000,0000,0000,,will give us a very, very efficient\Nmechanism that will move us down from
Dialogue: 0,0:09:43.16,0:09:48.57,Default,,0000,0000,0000,,{0,1} to the T to zero to the S-1. So now\Nwhen we talk about security, it turns out
Dialogue: 0,0:09:48.57,0:09:53.21,Default,,0000,0000,0000,,this step here is tight. In other words,\Nthere is really no additional security
Dialogue: 0,0:09:53.21,0:09:59.25,Default,,0000,0000,0000,,cost to going down from two to the T to\Nzero to S-1. And the reason that's true,
Dialogue: 0,0:09:59.25,0:10:02.73,Default,,0000,0000,0000,,it's actually again a very cute theorem\Nto prove, but I, I won't do it here. Maybe
Dialogue: 0,0:10:02.73,0:10:07.62,Default,,0000,0000,0000,,I'll leave it as an exercise for you guys\Nto argue. Which says that if you give me
Dialogue: 0,0:10:07.62,0:10:11.92,Default,,0000,0000,0000,,any two sets Y and X, where Y is contained\Ninside of X, then applying the
Dialogue: 0,0:10:11.92,0:10:16.52,Default,,0000,0000,0000,,transformation that we just saw to a\Nrandom permutation from X to X actually
Dialogue: 0,0:10:16.52,0:10:21.34,Default,,0000,0000,0000,,gives a random permutation from Y to Y. So\Nthis means that if we started with a truly
Dialogue: 0,0:10:21.34,0:10:25.58,Default,,0000,0000,0000,,random permutation on X, you'll end up\Nwith a truly random permutation on Y. And
Dialogue: 0,0:10:25.58,0:10:29.44,Default,,0000,0000,0000,,since, well, the permutation we're\Nstarting with is indistinguishable from
Dialogue: 0,0:10:29.44,0:10:33.37,Default,,0000,0000,0000,,random on X, we'll end up with a\Npermutation that's indistinguishable from
Dialogue: 0,0:10:33.37,0:10:37.76,Default,,0000,0000,0000,,random on Y. Okay, so this is a very tight\Nconstruction and as I said, the first step
Dialogue: 0,0:10:37.76,0:10:42.00,Default,,0000,0000,0000,,actually is basically, the analysis is the\Nsame as the Luby-Rackoff analysis. In
Dialogue: 0,0:10:42.00,0:10:46.19,Default,,0000,0000,0000,,fact, it's better to use as I said, the\NPatarin analysis using seven rounds. So
Dialogue: 0,0:10:46.19,0:10:50.42,Default,,0000,0000,0000,,actually here, there's a bit of cost in\Nsecurity. But, overall, we get a
Dialogue: 0,0:10:50.42,0:10:55.56,Default,,0000,0000,0000,,construction that is a secure PRP for\Nactually, not such good security
Dialogue: 0,0:10:55.56,0:10:59.99,Default,,0000,0000,0000,,parameters, but nevertheless, this is a\Ngood secure PRP that we can construct that
Dialogue: 0,0:10:59.99,0:11:04.64,Default,,0000,0000,0000,,actually will operate on the range zero to\NS minus one. This in turn will allow us to
Dialogue: 0,0:11:04.64,0:11:08.97,Default,,0000,0000,0000,,encrypt credit card numbers such that the\Ncipher text looks like a credit card
Dialogue: 0,0:11:08.97,0:11:13.18,Default,,0000,0000,0000,,number. And again, I want to emphasize\Nthat there's no integrity here. The best
Dialogue: 0,0:11:13.18,0:11:17.12,Default,,0000,0000,0000,,we can achieve here is just \Ndeterministic CPA security. No cipher text
Dialogue: 0,0:11:17.12,0:11:21.25,Default,,0000,0000,0000,,integrity, and no randomness at all. Okay.\NSo this concludes this module. And as
Dialogue: 0,0:11:21.25,0:11:25.62,Default,,0000,0000,0000,,usual I want to point to a few reading\Nmaterials that you can take a look at if
Dialogue: 0,0:11:25.62,0:11:29.99,Default,,0000,0000,0000,,you're interested in learning more about\Nanything that we discussed in this module.
Dialogue: 0,0:11:29.99,0:11:34.26,Default,,0000,0000,0000,,So first of all, the HKDF construction\Nthat we talked about for key derivation is
Dialogue: 0,0:11:34.26,0:11:38.95,Default,,0000,0000,0000,,described in a paper from 2010 by Hugo\NKrawczyk. Deterministic encryption, The
Dialogue: 0,0:11:38.95,0:11:44.48,Default,,0000,0000,0000,,SIV mode that we described is discussed in\Nthis paper over here. The EME mode that we
Dialogue: 0,0:11:44.48,0:11:49.63,Default,,0000,0000,0000,,described that allows us to build a, a\Nwider block pseudo random permutation is
Dialogue: 0,0:11:49.63,0:11:54.40,Default,,0000,0000,0000,,described in this paper here by Halevi and\NRogaway. Tweakable block ciphers that
Dialogue: 0,0:11:54.40,0:11:59.24,Default,,0000,0000,0000,,actually led to the XDS mode of operation\Nthat's used for disk encryption is
Dialogue: 0,0:11:59.24,0:12:04.70,Default,,0000,0000,0000,,described in this paper here. And finally,\Na format preserving encryption is described
Dialogue: 0,0:12:04.70,0:12:09.72,Default,,0000,0000,0000,,in this last paper that I point to over\Nhere. Okay so this concludes this module.
Dialogue: 0,0:12:09.72,0:12:13.83,Default,,0000,0000,0000,,And in the next module we gonna start\Nlooking at how to do key exchange.