[00:00.000 --> 00:03.540]  Peter Wayner speaking about overcoming Big Brother.
[00:07.340 --> 00:10.820]  Okay, I'd like to... I am Peter Wayner and I would like to thank everyone for coming.
[00:11.060 --> 00:18.100]  I really enjoy coming to the HOPE conferences because there's such a crackling, unsettled kind of intelligence that pervades the place.
[00:19.780 --> 00:30.600]  And what I'm really going to be talking about is kind of a way we can repurpose encryption technology to build databases that do useful work without having any useful information in them.
[00:31.120 --> 00:36.320]  And we titled it with the building an anti-Big Brother to kind of get a little bit of a flashy spin to it.
[00:38.860 --> 00:43.360]  One of the other terms I kind of use to describe this are translucent databases and we'll get to that in a few minutes.
[00:44.300 --> 00:47.340]  So here's kind of the big problem that I think we have.
[00:48.580 --> 00:54.180]  And this is something I've discussed with a lot of people over the years and this is what led me to kind of spend some time looking at it.
[00:54.180 --> 01:00.400]  And the problem is that, you know, these databases have this sensitive information in them.
[01:00.500 --> 01:04.900]  They have like prescription records, you have salary records, credit card numbers, schedules.
[01:05.460 --> 01:08.000]  You know, information that can be abused in all these different kind of ways.
[01:08.140 --> 01:10.200]  And the problem is that there are a lot of weak links.
[01:10.740 --> 01:18.660]  And so even though if you are the system administrator or trying to work as hard as you can, there are lots of problems that are beyond your means.
[01:18.660 --> 01:27.360]  So maybe the operating system that you're building your system upon has holes or a back door or maybe the database has a hole.
[01:27.820 --> 01:32.400]  Or sometimes the problem is an insider that's in your organization that's abusing the information.
[01:33.760 --> 01:35.340]  And this is a real problem.
[01:36.180 --> 01:38.720]  People, you know, abuse things all the time.
[01:38.840 --> 01:42.860]  I was talking to a friend of mine and he was lamenting the fact and he wanted to know whether he should call the police.
[01:42.860 --> 01:49.500]  Because his competitors were in their offices negotiating some hard-fought deal and they weren't getting very far.
[01:50.060 --> 02:04.320]  And while they took a break and his team decamped to their offices and they left the competitors in the conference room, the guys plugged into the network and downloaded everything off their server because these guys thought, well, you know, no one's ever going to break in.
[02:04.820 --> 02:09.300]  So, you know, physical security is a problem even when you're inside your parameter.
[02:09.300 --> 02:15.660]  And so you develop this parameter and you think that you're going to keep everybody out and you've got these firewalls and you've got this fortress.
[02:15.940 --> 02:18.520]  And even then you have problems with abuse inside.
[02:20.040 --> 02:23.100]  So, I started looking at this problem and I started talking to people.
[02:24.160 --> 02:28.320]  And I was having this debate with this guy and he said, well, you know, this is just inherent.
[02:28.500 --> 02:30.420]  It's part of the way the world is.
[02:30.540 --> 02:46.400]  You know, if you want to build the system, if you want to give people services, if you want to keep track of their prescriptions, if you want to keep their credit card in file so they can do a one-click order, if you want to do anything for people, you've got to have these databases and there's just no two ways about it.
[02:47.180 --> 02:50.480]  And I started thinking about that and I started wondering, you know, is that really true?
[02:51.120 --> 03:00.780]  And, you know, when you start playing around with science, you start playing around with mathematics, sometimes you can come up with really interesting results if you can kind of flip assumptions on their head.
[03:00.780 --> 03:04.160]  And this is kind of what people did when they first looked at public key cryptography.
[03:04.360 --> 03:13.160]  I remember talking to Ralph Merkel about this and he said, well, you know, I wondered, is there any reason why you have to encrypt with one key and decrypt with the same key?
[03:13.720 --> 03:17.860]  And he couldn't prove that and so he came up with public key cryptography.
[03:18.320 --> 03:22.160]  And I think that...so I started looking at this and I was wondering, well, is there any way you can get around it?
[03:23.020 --> 03:28.860]  And the more I looked at it, I came to the conclusion that you can and you can kind of use a lot of the old tricks that are in our bag.
[03:28.860 --> 03:30.800]  You just have to think about using them in a different way.
[03:31.100 --> 03:41.540]  And so what I want to try to do is go through a few simple examples that I hope will inspire you to kind of redesign your systems so they kind of have this kind of translucent nature.
[03:42.020 --> 03:47.180]  And what you'll end up with will be kind of, I think, something that's more secure, more useful for everyone.
[03:47.720 --> 03:50.720]  And in a sense, you can have your cake and eat it too.
[03:56.610 --> 04:00.470]  So I've tried to come up with a bunch of different metaphors for describing how you can do this.
[04:00.470 --> 04:07.190]  And I think the kind of old-school way of designing your...or protecting your data is to build this fortress around it.
[04:07.310 --> 04:13.550]  And then, you know, you've got your walls and you've got your...you harden your firewall as best you can.
[04:13.550 --> 04:16.570]  And then you've got, you know, you've got your retinal scanners.
[04:16.630 --> 04:20.570]  And you just keep putting all these layers and layers to protect that one hard disk in the center of things.
[04:21.170 --> 04:27.470]  Now, the way I thought about it is that maybe you can do all this without having any useful information on that hard disk at all.
[04:27.470 --> 04:31.770]  So, in essence, you are kind of...you're not building a fortress.
[04:31.950 --> 04:35.110]  You're building this neutral switch that doesn't know what's coursing through it.
[04:35.190 --> 04:37.330]  You have this network that's very dumb.
[04:37.570 --> 04:42.950]  But somehow, the people, the clients on the edges, the users, are going to get the information they need.
[04:42.990 --> 04:44.590]  They're going to get the services that they require.
[04:44.770 --> 04:45.950]  And it's all going to work out.
[04:46.450 --> 04:55.390]  So, in essence, the information is kind of diffused into this mathematical space instead of being kept in one very concrete physical place, which is that hard disk.
[04:58.320 --> 05:02.840]  Okay, so there are three different...there are five different ways that I've kind of come up with doing this.
[05:02.900 --> 05:05.060]  And they're all variations on standard crypto themes.
[05:05.640 --> 05:16.240]  But they are to scramble the data, which is to put it through a kind of standard encryption function like AES or to use, you know, whatever your favorite encryption function is or a public key for that matter.
[05:16.240 --> 05:20.500]  And the second one is perhaps to blur the data just enough.
[05:20.680 --> 05:28.940]  So, instead of completely scrambling it so it's unintelligible, you blur it so it's not useful to people who might abuse it.
[05:28.960 --> 05:36.460]  But it still retains enough of the kind of outline that it's still useful for people who want to use it for legitimate purposes.
[05:37.260 --> 05:44.800]  The third technique is to kind of camouflage the data so only the right person can pick out the legitimate values from the fake values.
[05:45.400 --> 05:49.660]  The fourth one is to misdirect the attacker and make it harder for them to figure out what's correct.
[05:49.900 --> 05:51.740]  And the fifth one is to split the data.
[05:51.940 --> 05:56.960]  So, these are kind of standard functions where you can arrange it for the data to be in two or three or n different locations.
[05:57.180 --> 06:09.200]  And the only way that an attacker can arrange to...can abuse the information is if they reconstitute the information by breaking into all n locations at the same time.
[06:11.680 --> 06:15.260]  And I'm going to go through and I'm going to concentrate mainly on the first couple of them.
[06:15.460 --> 06:23.180]  I think the latter ones are a little bit more straightforward and so I kind of covered them in the book I wrote about this, but I don't think they're as germane to the topic here.
[06:25.200 --> 06:35.580]  Okay, so the first thing I wanted to say is that designing these kind of translucent databases, and translucent databases is the term I kind of came up to apply to all of this, is something of an art.
[06:35.580 --> 06:44.000]  So, there are a lot of different approaches and I think I could have a debate with many different people about what's the right solution to use in one case.
[06:44.650 --> 06:46.820]  You may or may not want to use different ones.
[06:47.000 --> 06:48.340]  And there's often a trade-off.
[06:48.580 --> 06:56.840]  If you turn up the security, you often turn down the usability, or you kind of...you're going to have to kind of trade these things off.
[06:56.980 --> 07:01.740]  And there's a lot of fun available to designers when they're working through this.
[07:02.840 --> 07:05.800]  I think one of the more interesting details are kind of the side bits.
[07:05.920 --> 07:10.060]  I've often given this talk to Java programmers because I've always thought that Java is a very useful tool.
[07:10.700 --> 07:17.540]  And it's now coming to the...we're now reaching a point where JavaScript is just as useful, if not more useful.
[07:17.920 --> 07:19.720]  And it's a completely different technology.
[07:19.960 --> 07:26.720]  But if you work at...if you kind of program to these platforms, it's very easy for all the work to be done at the client.
[07:26.720 --> 07:30.300]  And all the encryption and the scrambling to be done at the client in someone's browser.
[07:31.020 --> 07:37.160]  And by the time it even leaves the machine, it's completely scrambled and the entire network is protected.
[07:37.420 --> 07:40.320]  So you don't need to worry about putting these firewalls in the right place.
[07:40.320 --> 07:43.580]  You don't need to worry about someone getting inside your perimeter.
[07:43.780 --> 07:45.040]  Because there is no perimeter.
[07:45.180 --> 07:46.320]  It all stops at the browser.
[07:50.360 --> 07:54.180]  Okay, so the first...the kind of...the first tool that you need to know about...
[07:54.180 --> 07:55.600]  the first solution.
[07:55.820 --> 07:58.300]  And I think it's pretty much an obvious one.
[07:58.540 --> 08:02.600]  But it's...I found it to be more and more useful the more I looked at it.
[08:02.680 --> 08:06.060]  And I first started playing with it, and I said, well, you know, that's kind of interesting.
[08:06.220 --> 08:09.860]  And then the more I've used it, I became to realize it's kind of like duct tape.
[08:10.240 --> 08:15.400]  And Ralph Merkel, who's done a lot of work with hash functions, kind of calls them the duct tape of cryptography.
[08:15.820 --> 08:17.200]  And that's what I found too.
[08:17.320 --> 08:20.180]  You can use it in an incredibly wide range of places.
[08:21.160 --> 08:22.680]  And it does a great job.
[08:24.340 --> 08:26.980]  So, the duct tape here is called a one-way function.
[08:27.300 --> 08:28.720]  And I don't know how much math you guys know.
[08:28.860 --> 08:33.760]  But a one-way function is like this equation that you can do in one direction, but not the other.
[08:34.200 --> 08:40.620]  So, if you think about kind of elementary school arithmetic, you know how to do addition and you know how to do subtraction.
[08:40.740 --> 08:43.120]  And subtraction kind of reverses addition.
[08:43.500 --> 08:51.220]  So, you try to imagine that there's going to be some function out there like addition function for which we don't know of a way to go backwards, which is that subtraction.
[08:51.620 --> 08:53.360]  And it turns out that these are exist.
[08:53.780 --> 08:55.100]  These functions do exist.
[08:55.520 --> 09:00.860]  So, that means that if someone gives you f of x, which is how a mathematician might talk about it, it's very hard to find x.
[09:01.940 --> 09:13.600]  And kind of a corollary definition, and I'm only mentioning in this case people are into math in the audience, is that, you know, it's very, it's also very hard to find two distinct values of x and y, so that f of x equals f of y.
[09:16.620 --> 09:30.040]  And these one-way functions have lots of practical values, and not only are they hard to reverse, and we're going to use that difficulty for all of our security, and we're going to base our security on it, but they also look like random values.
[09:30.040 --> 09:31.980]  And it turns out this is useful in a lot of different ways.
[09:32.180 --> 09:40.240]  I often try to make the claim that these translucent databases are more efficient because they often lay out the tables better.
[09:40.480 --> 09:46.100]  And the values are more equally distributed, so the indexing function of databases can work better.
[09:46.420 --> 09:52.640]  So I don't know whether that's, if it's much of an effect, but it's kind of interesting.
[09:52.940 --> 09:58.300]  So these one-way functions usually look like complete random garbage that comes out.
[09:58.640 --> 10:01.360]  And that can be useful in a lot of different ways.
[10:05.370 --> 10:10.170]  Okay, let me just say before I go on and show you an example that there are ways that you can have your...
[10:10.170 --> 10:12.590]  you know, once again, you can have your cake and eat it too.
[10:12.750 --> 10:24.370]  If you want to have a one-way function, but you sometimes maybe want to go backwards, and you sometimes want to figure out what someone typed into that one-way function, you can build them with trap doors in them.
[10:25.050 --> 10:32.330]  And this is kind of the original metaphor that people use to describe public key cryptography, and it's useful in this situation too.
[10:32.470 --> 10:37.670]  And the only caveat I can offer you is that if you put that trap door in there, all of a sudden you have to protect it.
[10:37.790 --> 10:40.190]  And you have to worry that perhaps it might be abused.
[10:42.970 --> 10:48.150]  So, you know, we can... you can do everything here and have your back door if you need it.
[10:51.590 --> 10:57.420]  Okay, so let me talk about the kind of the practical ways that one might go about using a one-way function.
[10:57.580 --> 11:00.320]  And it turns out that you can just download some source code from the web.
[11:00.790 --> 11:03.350]  There's a great function called SHA, which the U.S. government built.
[11:05.330 --> 11:18.490]  And although some people had some conspiracy theories about what these guys were doing back in the 70s, no one's really found any problems with the latest function, which is this one called SHA, which is short for Secure Hash Algorithm.
[11:19.580 --> 11:25.990]  Now, when I use it on the rest of the slides, I just use the word, the letter H, which to describe a kind of hash, generic hash function.
[11:26.210 --> 11:31.760]  But what you do is that this function is just a big blender for data.
[11:31.960 --> 11:35.420]  And you take your file, you toss it in, and out comes 20 bytes.
[11:36.020 --> 11:41.440]  And those 20 bytes are not going to look like the 20 bytes that you toss in if you put in a slightly different file.
[11:41.640 --> 11:46.990]  And every time you make a little change in that file, there's going to be a change in the 20 bytes that come out.
[11:47.660 --> 11:50.560]  And the question is, how do we use those 20 bytes?
[11:50.830 --> 11:55.440]  So, I'm going to show you some simple ways that you might use those 20 bytes to come up with pseudonyms for people.
[11:55.610 --> 11:58.470]  And so, these are going to be simple pseudonyms that you can use in your database.
[11:59.370 --> 12:06.140]  And I think that they're practical and useful, and yet they protect, you know, people's identities or their personal information.
[12:07.680 --> 12:15.080]  So, I don't know how many of you guys are programmers, but I'll just mention a few little details along the way, you know, for implementation reasons.
[12:15.080 --> 12:17.700]  You know, you don't need to keep all 20 bytes that came out.
[12:17.920 --> 12:19.180]  They're all equally random.
[12:19.320 --> 12:22.040]  You could just keep the first four bytes or even the first couple of bits.
[12:22.610 --> 12:27.940]  And you can toss multiple files in there and you can arrange things and you can concatenate data.
[12:28.110 --> 12:31.830]  And you just pour the whole thing into this blender and out comes this result.
[12:33.660 --> 12:41.680]  And one of the kind of features that I like to use is to put this key at the beginning of every hashing operation.
[12:41.680 --> 12:48.350]  And what this does is it kind of creates a kind of custom hash function that only you can generate because only you know that key.
[12:48.590 --> 12:51.700]  So, you can kind of key these things and it has some interesting results.
[12:53.320 --> 13:04.560]  So, I'm not going to be able to talk about it now, but if you have time afterwards, you should ask me about the list of disco songs and how you can hide secret information in just this list of your favorite disco songs using this technique.
[13:06.670 --> 13:10.110]  Okay, so now I should give some props to the people who've worked on this over the past.
[13:10.320 --> 13:16.180]  I mean, when I started looking at this idea, I was thinking, gosh, you know, this would be a really great area to do some research in.
[13:16.920 --> 13:20.940]  And it became clear that people have been looking at this idea in many different facets over the years.
[13:20.940 --> 13:30.380]  And in my mind, like the Unix password function is one of the first good translucent databases that's out there.
[13:30.420 --> 13:34.470]  So, I think many of you guys probably know how the Unix password function works.
[13:35.550 --> 13:39.470]  And for that matter, the ones that are built into NT or the Mac OS.
[13:39.970 --> 13:47.380]  And what the operating system does is instead of storing the password itself, it stores the hash of the password.
[13:47.750 --> 13:53.330]  And what this means is if someone breaks into the lowest level of the operating system, they're not going to be able to figure out someone's password.
[13:53.560 --> 13:55.700]  They're just going to see this kind of random noise.
[13:57.470 --> 14:06.260]  And I'm going to show you in a few slides how you can use that to protect people's library browsing records or, you know, their shopping records or anything like that.
[14:06.820 --> 14:12.110]  And we're just going to use the same technique that people have been using over the years for protecting passwords.
[14:19.880 --> 14:24.200]  Okay, so here's the question is, can a store track what customers buy without spying on them?
[14:24.520 --> 14:29.000]  And I have a habit of just referring to Amazon in this case.
[14:29.140 --> 14:33.820]  And the reason I don't feel, I don't want to pick on Amazon because I think they're really a great company.
[14:35.320 --> 14:40.260]  But the reason I end up choosing them is because I think they have the most feature, one of the more feature rich environments out there.
[14:40.260 --> 14:51.660]  And they've run into problems with privacy advocates because people look at Amazon and they get a little bit worried because they say, Amazon knows exactly what I bought, when I bought it, it knows my credit card, it knows all this information about me.
[14:52.080 --> 14:57.060]  And I personally think a company like Amazon should be really worried about the information it keeps.
[14:57.840 --> 15:02.580]  One of the first times I was teaching a course on this topic, I had the...
[15:02.580 --> 15:09.180]  It ended up being a silver lining because it's, I think, one of the great examples about why this kind of technology is necessary.
[15:09.180 --> 15:14.020]  But I came out that morning and my neighbor's car had been broken into and someone had stolen his stereo.
[15:14.460 --> 15:17.860]  And then I looked up the street and we kind of have a communal street where everyone parks.
[15:18.940 --> 15:23.980]  My car had also been broken into and although they tried to steal the stereo, they didn't get it.
[15:24.560 --> 15:27.520]  But I'll tell you that the glass was much more valuable than...
[15:27.520 --> 15:30.600]  It cost much more to replace the glass than the stereo would cost to replace.
[15:30.860 --> 15:32.300]  So now we leave our car open.
[15:36.460 --> 15:37.620]  But anyway, so...
[15:37.620 --> 15:40.040]  So we were sitting there and, you know, I have two kids.
[15:40.040 --> 15:42.180]  We have a minivan and it's an old minivan.
[15:42.180 --> 15:43.360]  So it doesn't...
[15:43.360 --> 15:48.220]  It's not as cool as Emanuel's telephone truck, but it's in that vintage.
[15:48.740 --> 15:51.760]  And so I was thinking, why would someone try to steal our stereo?
[15:52.000 --> 15:54.800]  And then I was talking to my friend across the street who also has a couple of kids.
[15:54.920 --> 15:57.300]  And he just has, was driving like a Nissan Altima.
[15:57.300 --> 16:02.100]  And there are some BMWs down the street and there's some, there's some much nicer cars in the neighborhood.
[16:02.420 --> 16:05.300]  And we were kind of commiserating, wondering why would someone pick on us?
[16:05.800 --> 16:10.240]  And then I remembered that just a few months earlier, he had installed a new stereo from Crutchfield.
[16:10.440 --> 16:11.640]  And bought it from Crutchfield.
[16:11.820 --> 16:13.860]  And I had bought a new stereo from Crutchfield.
[16:14.560 --> 16:17.120]  And I thought, well that, that still doesn't mean anything.
[16:17.140 --> 16:20.220]  Because how would they know where, you know, whose car it was from?
[16:20.340 --> 16:25.480]  And then I remembered if you go to Crutchfield, they've got a really nice high, high touch website.
[16:25.480 --> 16:29.860]  Where before you can even order something, you have to tell them what make and model your car is.
[16:29.980 --> 16:32.100]  You don't have to tell them the color, but they can figure that out.
[16:32.440 --> 16:36.100]  And they tell you whether this, this little nice stereo is going to fit in your dash or not.
[16:36.440 --> 16:38.980]  So, I have no idea what happened.
[16:39.360 --> 16:44.820]  But the most plausible explanation I can have for why our two cars were the only ones targeted on that street.
[16:44.960 --> 16:48.680]  Is that there's someone who has access to Crutchfield's database and was selling a list to people.
[16:48.680 --> 16:51.960]  Saying, here are some nice new stereos that are installed.
[16:52.640 --> 16:58.040]  And, you know, if you happen to, you know, if you're looking for stereo, here's a good place to go pick one up.
[16:59.080 --> 17:05.540]  So, I tell that story a lot of times just to motivate it that these, this information in this database is valuable.
[17:05.760 --> 17:09.360]  Everyone says, you know, well, you know, what do you care if someone knows what stereo you bought?
[17:09.360 --> 17:14.180]  But, you know, I know that it cost me $300, $400 to replace the glass on my car.
[17:14.620 --> 17:18.160]  Because, perhaps, the database wasn't as secure as it could be.
[17:20.180 --> 17:23.720]  Okay, so, what I'm proposing is a very simple solution.
[17:23.720 --> 17:27.020]  And I think it goes a long way to solving a lot of the problems.
[17:27.260 --> 17:31.680]  Is instead of storing information under someone's name, you store that under the hash of the name.
[17:33.040 --> 17:40.180]  So, here's a, here's a kind of table at the bottom that kind of looks like a, some store for some crazy clothes store.
[17:40.480 --> 17:44.020]  And you notice down here, let me, let me highlight it.
[17:44.840 --> 17:48.620]  This is, this is the hash of the user's name instead of the user's name.
[17:48.880 --> 17:55.240]  So, you still got the other information like what I bought, these touring chinos or navigating chinos or whatever, and the color and the size.
[17:55.660 --> 17:59.100]  But, you don't actually have the person's name itself.
[18:00.200 --> 18:01.900]  Now, what's the value to that?
[18:02.060 --> 18:05.020]  Well, let's start thinking about what you could still do with that database.
[18:05.400 --> 18:08.860]  There are some things you can't do, which is know who bought what, where, when.
[18:09.120 --> 18:17.240]  So, if a, if a stereo store had used this to protect my stereo records, I would be, there's a good chance they wouldn't be able to find out where I lived if they hashed my address.
[18:17.860 --> 18:21.400]  But, what is true is I can come in and I can look at my past records.
[18:21.640 --> 18:24.640]  So, it turns out that that stereo in the car has gone bad.
[18:25.020 --> 18:26.620]  And I need to order a replacement.
[18:26.620 --> 18:30.480]  I could go to the website and I can still type in my name.
[18:30.740 --> 18:34.940]  I can compute the hash using JavaScript or wherever it is in the browser.
[18:34.960 --> 18:35.840]  I can compute the hash.
[18:35.980 --> 18:38.280]  And I can look at everything I've bought in the past.
[18:38.540 --> 18:42.640]  So, the store is still giving me those services where I'm able to look at my past orders.
[18:42.840 --> 18:45.860]  I'm able to figure out what was the serial number for the product.
[18:45.880 --> 18:48.120]  I can deal with warranty servicing.
[18:48.640 --> 18:52.520]  But the store doesn't know my name and the store can't go in the other direction.
[18:52.700 --> 18:53.960]  Because we've got this one-way function.
[18:54.240 --> 18:57.260]  I can compute the one-way function in the direction that's useful for me.
[18:57.460 --> 19:00.420]  But anybody who's broken into the store computer can't go backwards.
[19:02.180 --> 19:04.560]  So, I think that this is a really useful feature.
[19:04.720 --> 19:08.980]  And I think it would be helpful for a lot of stores if they kept their information like this.
[19:22.920 --> 19:28.520]  Now, yeah, the hash ends up being the key that becomes what people use.
[19:28.980 --> 19:33.100]  And what I often do when I've built some of these systems is I end up doing the hash right at the browser.
[19:33.340 --> 19:36.120]  So, by the time it leaves the browser, you know, the name never...
[19:36.560 --> 19:38.400]  Your name never leaves the browser in the clear.
[19:39.760 --> 19:40.120]  So...
[19:41.160 --> 19:41.560]  So...
[19:41.560 --> 19:44.480]  That means that you do not store all addresses.
[19:45.920 --> 19:46.320]  So...
[19:46.980 --> 19:47.380]  Because...
[19:47.380 --> 19:51.260]  You have to store them in the clear or you have to pass them in 5.5.
[19:52.380 --> 19:54.900]  Ah, but we will get to that in a few minutes.
[19:55.200 --> 19:57.300]  But there are a number of different ways you can deal with that.
[19:58.800 --> 19:59.200]  Um...
[20:00.520 --> 20:12.100]  What he just asked was, you know, does this mean that you can't store something practical like addresses because you either have to store it in the clear so you can use it, or if you hash it up, it means that the person is going to have to type it the next time.
[20:12.420 --> 20:20.800]  So, one of the nice features that if you go to a great website like Amazon is that they've got all your addresses stored there and you just say, ship it to me here.
[20:20.940 --> 20:25.280]  And his point was, well, they can't do that for you anymore because it's all hashed into gobbledygook.
[20:26.820 --> 20:27.180]  Um...
[20:27.180 --> 20:28.240]  There are other ways you can do it.
[20:28.300 --> 20:32.540]  What you can do is you can end up using the hash as a key to encrypt the data.
[20:32.880 --> 20:39.540]  So, what I would propose, if I were to design a website for a place like Amazon, is I wouldn't store their address.
[20:39.540 --> 20:41.880]  I would store their address encrypted with this...
[20:42.800 --> 20:44.680]  with a different way of hashing up your name.
[20:44.820 --> 20:45.940]  And I can show you that in a sec...
[20:45.940 --> 20:48.760]  I think I've got a slide in a few seconds that shows that.
[20:49.220 --> 20:49.840]  But, um...
[20:50.760 --> 20:51.940]  And in that way, you will...
[20:53.100 --> 20:54.720]  you can decrypt it at that time.
[20:54.860 --> 21:00.900]  And then once you ship the package, I would suggest that it would be prudent for the store to delete the information and forget it.
[21:02.040 --> 21:03.280]  And, you know, if they do...
[21:03.280 --> 21:05.900]  If they're a responsible store, I think it would be smart for them to do that.
[21:06.000 --> 21:09.920]  And they just have to wait for the customer to come back and log back in and unlock that information.
[21:12.760 --> 21:15.820]  Okay, now, here's what I think is one of the nicer features of this.
[21:15.900 --> 21:18.720]  And if you remember the table in the last slide, is that I...
[21:19.840 --> 21:25.540]  I only hashed up the name and the personal information, but I didn't hash up the data of what people bought.
[21:25.540 --> 21:29.340]  And so this means that the marketing department is going to still be able to do its job.
[21:29.540 --> 21:36.720]  They're still going to be able to look at this and they're going to see that people bought, you know, 10% small shirts in this one town and 50% large.
[21:37.120 --> 21:41.140]  Because there are these big demographic differences between the different towns.
[21:41.860 --> 21:42.920]  You know, like they're...
[21:43.640 --> 21:46.420]  And, you know, they're going to be able to figure out all this information.
[21:46.420 --> 21:51.140]  They're going to find out that people bought blue shirts with red pants or whatever combination that people do.
[21:52.100 --> 21:54.800]  But they're not going to see the personal information behind it.
[21:54.800 --> 21:56.080]  And so, they're gonna be able to aggregate it.
[21:56.160 --> 22:03.600]  They're gonna come up with all this data that they're gonna be able to use to plan for the future, but they're not going to have the personal data attached to it that can be abused.
[22:04.180 --> 22:06.620]  And so I think that's, that's kind of a useful feature.
[22:07.000 --> 22:12.480]  Because it's always the Marketing department which is the kind of... the Big Brother with a smiling face.
[22:12.600 --> 22:13.360]  Cause they're saying, oh, come on.
[22:13.500 --> 22:15.080]  We're just doing this for marketing purposes.
[22:15.260 --> 22:16.240]  We're not gonna sell it, etcetera.
[22:16.740 --> 22:20.740]  And they're one of the big forces behind collecting all of this information.
[22:20.740 --> 22:33.860]  So, I think one of the ideal things is if you can develop these systems in a way that doesn't cut them off at the knees, they're going to be happy because they can do their job without taking as much criticism for spying on people.
[22:36.060 --> 22:36.480]  Yep.
[22:45.520 --> 22:46.360]  You mean...
[22:50.310 --> 22:57.170]  Well, I don't know if I have a slide for this, but when I talked before about the five different principles and the second one was blurring it just enough.
[22:57.170 --> 23:03.990]  I mean, one thing you can do is you can keep just the zip code instead of the address, which often helps... which is often what you need.
[23:04.550 --> 23:08.370]  Or you could hash... I mean, you can... there are lots of different games you can play.
[23:25.630 --> 23:25.990]  Right.
[23:25.990 --> 23:27.910]  I think that's a very good attack.
[23:27.910 --> 23:32.570]  And what he's pointing out is one of the weaknesses with what I've just shown you.
[23:32.650 --> 23:36.050]  And I'm going to about to... if we flip to the next slide, solve that problem.
[23:36.110 --> 23:37.070]  In honesty, it's not a plan.
[23:38.310 --> 23:39.590]  So, what would a pharmacy do?
[23:39.750 --> 23:44.970]  Let's imagine that we've got... we're going to kind of increase the level of security here.
[23:45.090 --> 23:48.990]  And I remember at the beginning, I talked about this being kind of a trade-off between usability and security.
[23:49.270 --> 23:56.550]  So, if people just type in the name, what he made the very good point is that, you know, maybe someone's going to do a dictionary attack, or they're going to do a phone book attack.
[23:56.650 --> 24:00.990]  They're going to take all the names from your small town, and they're going to pour it through the hash function.
[24:01.130 --> 24:04.190]  And eventually, they're going to figure out who that was that bought something.
[24:05.030 --> 24:11.050]  And so, you know, in order to just motivate this, I imagine the question of what would a pharmacy do?
[24:11.690 --> 24:18.230]  And, you know, again, I think a pharmacy has problems... has a lot of problems with drugs, because people want to steal a lot of these drugs that are out there.
[24:18.330 --> 24:25.230]  And many of the legitimate drugs also kind of have this new illegitimate usage, because they have these timed narcotics like OxyContin.
[24:25.410 --> 24:28.530]  And what people want to do is they want to crush them up and take them all at one time.
[24:31.370 --> 24:38.190]  So, the information in the pharmacy database is very valuable to... and also very subject to abuse.
[24:40.310 --> 24:44.410]  So, what I'm suggesting in that case is you hash up both the name and a password.
[24:44.690 --> 24:47.390]  So, you might give someone a PIN or a password.
[24:47.570 --> 24:52.630]  And so, then what happens is your database looks something like this, and it looks very similar to the last database.
[24:53.230 --> 24:57.410]  And it looks just like the same kind of gobbledygook that we saw before is in this column.
[24:57.530 --> 24:58.390]  This is the key column.
[24:58.690 --> 25:03.390]  But if you notice on the top, I've got the... that this is the hash of the name concatenated with a password.
[25:04.050 --> 25:08.410]  So, if you were a pharmacy customer, what you do is you type in your name, and then you'd have to type in a password.
[25:08.670 --> 25:13.610]  So, this makes it a little bit less useful, because remembering all the passwords is kind of a pain in the neck for people.
[25:14.110 --> 25:20.210]  But it makes it impossible for someone to just kind of take the phone book and start hashing up names that they come across.
[25:20.870 --> 25:23.210]  So, this is a way to deal with that kind of problem.
[25:23.770 --> 25:26.970]  And I think it's a... I think it's an okay solution.
[25:26.990 --> 25:30.750]  And I think you might even be able to prove a theorem about why you have to have this secret password.
[25:31.710 --> 25:35.930]  Now, you'll notice that there's still some things that a pharmacy can do with this database.
[25:36.230 --> 25:37.650]  You can look for drug interactions.
[25:37.650 --> 25:42.650]  So, if a guy comes in and he's going to be buying OxyContin and Prozac, and let's say that that person is...
[25:43.450 --> 25:47.990]  I know nothing about pharmacology, but let's say that that's a dangerous combination.
[25:48.270 --> 25:53.590]  The pharmacy can still look and say, hey, wait a second, this guy is taking this and he's taking this other drug.
[25:53.950 --> 25:57.870]  And maybe this guy shouldn't be taking both at the same time.
[25:57.950 --> 26:03.550]  And they can kind of police how people are using their drugs and making sure that there aren't any dangerous combinations.
[26:03.550 --> 26:06.570]  But they don't have the kind of information...
[26:07.290 --> 26:11.110]  They don't have the kind of personal information stored attached to it.
[26:11.650 --> 26:12.670]  Now, one of the things...
[26:12.670 --> 26:19.170]  One of the objections that people often have to the solution I have for pharmacies is they say, well, look, you know, they have federal regulatory obligations.
[26:19.170 --> 26:20.990]  They have to keep track of the names.
[26:21.190 --> 26:25.190]  They have to know that this prescription for OxyContin went to Bob Jones on this day.
[26:25.410 --> 26:30.030]  And I think that's a very good objection and that's a very practical problem for pharmacies.
[26:30.430 --> 26:35.310]  But one of the ways that you still might use this technology is as a satellite database.
[26:35.590 --> 26:38.130]  So in many cases, there are, you know, many...
[26:38.130 --> 26:40.550]  A pharmacy has many chain or branches.
[26:40.830 --> 26:46.170]  So that branch that's fulfilling the prescription may keep a kind of a translucent version of the database.
[26:46.390 --> 26:52.570]  And they don't have to spend a lot of extra money on security for that small database at that location.
[26:52.610 --> 27:02.850]  But they may have a hardened location at their, say, corporate headquarters where they actually keep the information that they would give to the DEA if the DEA was doing an investigation on somebody.
[27:07.280 --> 27:07.640]  So...
[27:13.540 --> 27:14.680]  Well, I mean, you...
[27:15.760 --> 27:17.660]  I mean, there are some dangers in this.
[27:17.780 --> 27:25.280]  I mean, my feeling is that, like I said, that then all of a sudden we have the problem of dealing with passwords.
[27:25.940 --> 27:26.300]  His...
[27:26.840 --> 27:28.380]  Actually, let me repeat his question.
[27:28.580 --> 27:31.260]  He was saying, what about the administrative overhead of dealing with the passwords?
[27:31.320 --> 27:34.680]  And I think that's absolutely a problem.
[27:34.680 --> 27:35.400]  And there's nothing...
[27:35.400 --> 27:37.100]  Unfortunately, I don't have a great solution for it.
[27:37.100 --> 27:38.280]  And I don't know if anyone else does.
[27:39.160 --> 27:43.980]  You need to have this secret if you want people to have some kind of leverage over their control.
[27:45.240 --> 27:53.260]  And I don't know of a practical way of storing these things so that you can deal with forgotten passwords.
[27:53.720 --> 28:10.440]  So I think it's a question that you may want to deal with in kind of a hybrid system where you have a locked-down system where you keep someone's password in the clear and you have a kind of a low-grade system where you do most of the work and you use the hashed version there.
[28:12.380 --> 28:20.520]  Now, if you go back to, say, 1998, 1999, I was talking to my wife and she said, her friend said, you know, this internet thing's great.
[28:20.600 --> 28:28.400]  What you really need is some system where you log into someone's database or you go to some website and they'll tell you which of your babysitters is going to be free on Friday night.
[28:28.840 --> 28:33.980]  Because, in her mind, this was her biggest hassle was figuring out, you know, who is actually going to be available on Friday night.
[28:34.340 --> 28:36.880]  And I started thinking, this is a $100 million idea.
[28:37.500 --> 28:38.740]  Maybe a billion dollar idea.
[28:38.900 --> 28:41.620]  We can IPO this in four months and we'll be really rich.
[28:43.600 --> 28:45.280]  But it turns out that there are...
[28:45.280 --> 28:51.820]  It's actually completely the opposite of that because babysitting is not a very well-rewarded profession.
[28:52.520 --> 28:58.380]  And so the babysitters don't actually have a lot of money to support this kind of neat website if it were out there.
[28:59.920 --> 29:04.560]  And there's also a problem with this kind of website in that it's got a lot of really dangerous information there.
[29:04.640 --> 29:07.000]  There are the schedules of 15-year-olds in there.
[29:07.180 --> 29:09.580]  There's the schedules of parents who are going to be out of town.
[29:09.800 --> 29:23.100]  You know, it's very, very sensitive information on one hand, but it doesn't have much economic value on the other hand because the business and the industry that's driving this, you know, can't really support a high-grade security solution.
[29:23.700 --> 29:30.420]  So the more I started thinking about this, I realized, wow, you know, I don't know if I want to have a database with all the, you know, the locations of these 15-year-olds.
[29:30.520 --> 29:31.440]  I mean, what if I got hacked?
[29:32.220 --> 29:34.560]  And, you know, what if it was abused by some insider?
[29:34.720 --> 29:36.980]  It would be, you know, this would be an enormous responsibility.
[29:37.780 --> 29:41.520]  And so I started realizing, you know, maybe there's a way that you could do this translucently.
[29:41.740 --> 29:42.720]  And I think there is.
[29:42.740 --> 29:45.060]  I think what you can do is you can build these kind of systems.
[29:45.060 --> 29:49.460]  And I'm going to try to show you with two different tables here how you might build a simple version of this.
[29:50.880 --> 29:53.900]  And the database itself will have no personal information.
[29:54.300 --> 29:58.500]  But the parents will still be able to find out which of the babysitters are free.
[29:58.680 --> 30:02.700]  And the babysitters will be able to control which parents see their schedule and which parents don't.
[30:02.860 --> 30:06.240]  So if the babysitters want to turn somebody off or turn someone on, they can do that.
[30:06.400 --> 30:10.100]  And in fact, they'll even be able to show two different schedules to two different parents.
[30:10.100 --> 30:16.120]  So if they like someone better or someone pays more, they can be free a lot more often for them.
[30:17.140 --> 30:19.780]  So let's imagine a typical way this would work.
[30:20.180 --> 30:27.200]  The top table here kind of shows when someone might be free and when they're busy.
[30:27.400 --> 30:34.060]  And so a babysitter would be putting all these entries into the table and they would hash up their name and their personal password.
[30:34.060 --> 30:44.320]  So one of the... and this would be just kind of a generic table and it would be indexed by the hash to their name and their password.
[30:44.500 --> 30:46.360]  And it would tell when they're free and when they're busy.
[30:46.400 --> 30:49.080]  And the question is, how is a parent going to be able to use this?
[30:49.680 --> 30:59.800]  So what the sitter might do is the sitter keeps this second table and the sitter puts entries that lets parents figure out which is their...
[31:00.260 --> 31:05.140]  you know, what's the right name or the key that you need to go into the database so you can do this database join.
[31:05.420 --> 31:11.420]  So what a parent might do is the parent's going to type in their name and their password and hash it up and send it off to the database.
[31:11.420 --> 31:16.200]  And the database will say, you know, oh, you're 752ABB whatever.
[31:17.160 --> 31:24.280]  You are authorized to see the schedules of this 9829FFB and also the A492B.
[31:24.280 --> 31:31.580]  So this parent, whoever the 7525 guy or girl is, can then see these two sitters and their schedules.
[31:31.900 --> 31:39.400]  And then the database would just do a match and find out that 9828FFBA is busy on April 2nd.
[31:39.800 --> 31:45.020]  But, you know, A492 is free on the first and the third.
[31:45.400 --> 31:49.060]  So that would be how a parent could use a system like this.
[31:49.240 --> 31:53.540]  And the more I played with this, the more I realized that these hash functions really are like duct tape.
[31:53.540 --> 31:58.980]  You can start hashing this and hashing that and you can build up these arbitrarily arcane kind of systems.
[31:59.180 --> 32:05.220]  And they have, you know, you have to be a little careful how you do it because you can, you know, you can end up being too clever.
[32:05.460 --> 32:14.320]  But I still think that this is a nice elegant way of solving a solution where you need real high grade nuclear weapons like security for a database.
[32:14.740 --> 32:16.780]  But you don't have that much money to support it.
[32:17.120 --> 32:23.200]  So you can build these systems and I claim that you could leave these tables in the clear and you don't have to worry about them too much.
[32:24.620 --> 32:24.940]  Yeah.
[32:41.200 --> 32:42.940]  Yeah, I think that's a challenge.
[32:43.120 --> 32:46.240]  I don't, I, if I give a longer version of this talk, I have a slide that's devoted to it.
[32:46.300 --> 32:49.240]  And in fact, I think I have a slide, like three slides from now.
[32:49.360 --> 32:51.280]  And I, I'm trying to remember if I left it in or not.
[32:52.360 --> 33:00.240]  But there, you kind of clean it up the same way the database you would if you were doing a regular data, if you're running the database for a regular reason.
[33:00.240 --> 33:04.480]  Because you still have to worry about matching and the kind of keyword matching.
[33:05.080 --> 33:13.740]  So, you know, what the database users, the developers have is they have these canonical forms where they might say last name, comma, first name, middle initial.
[33:14.040 --> 33:21.100]  And they may delete all the Mr. and Mrs. And they may, for instance, even put everything in upper case to deal with case issues.
[33:29.620 --> 33:36.280]  I think if you, if you deal with collisions, then you have the same kind of problem you would with the database in any case.
[33:37.280 --> 33:45.260]  So, if, if you end up running this babysitter service and you've got two Chris Browns, then, you know, Chris Brown has to...
[33:46.240 --> 33:54.320]  Actually, no, if, if, if the two Chris Browns don't use the same password, then they're not going to hash to the same value.
[33:54.320 --> 33:55.760]  And so you really don't have it.
[33:56.000 --> 34:08.320]  One of the neat, one of the neat things is when you start hashing the name and the password together into one pile of gobbledygook, then you, you lose the problem, you, you don't, you avoid a lot of the problems with name collisions, which are kind of common in the namespace.
[34:09.960 --> 34:14.210]  So, I mean, one of the other kind of classic problems that we have out here, let me move on to the next scenario, what?
[34:14.460 --> 34:17.260]  But if you do that, how do you change your password?
[34:23.960 --> 34:41.400]  You can, I, I think, I mean, one, I don't really necessarily mind doing that because, I mean, okay, maybe you're going to have 10,000 records in your database, but I think changing a key or, you know, doing an, doing an insert or an update on a database table is not that big of a problem.
[34:41.550 --> 34:42.540]  I think, I think you're right.
[34:42.570 --> 34:46.360]  It is a price you have to pay in efficiency and it makes, it's a little bit harder to do that.
[34:46.360 --> 34:48.570]  It's not going to be just one place where you can do it.
[34:48.920 --> 34:58.460]  You're going to actually have to update a lot of, if you, if you look at the, the babysitter example, and the babysitter happens to have 10,000 items from her, you know, Palm Pilot uploaded into your database.
[34:58.650 --> 35:02.190]  You are going to have to do an update on all those 10,000 records.
[35:02.590 --> 35:03.670]  But, you know...
[35:10.060 --> 35:13.200]  No, I don't, I mean, I don't think, one, I don't think people change their password that often.
[35:13.200 --> 35:16.940]  And I don't think, you're not going to have to update the entire table.
[35:17.080 --> 35:18.500]  You're just going to have to update their entries.
[35:19.540 --> 35:27.960]  And, you know, I don't... perhaps I'm being a little bit cavalier about it, but, you know, for what you can get with a $700 server these days, I really don't worry about it too much.
[35:29.280 --> 35:50.000]  I mean, really, you can... like, you can keep the entire flight schedule and you could run a reservation service for, say, Southwest Airlines and keep maybe, like, 10 bytes for every seat on every flight for a year and put it all in RAM and a couple gigabytes of RAM or four gigabytes of RAM I actually kind of did the calculation.
[35:50.200 --> 35:51.620]  I mean, you have to be careful about how you pack it.
[35:51.820 --> 35:57.400]  But, you know, it's conceivable that you could run everything, you know, you can run an entire airline in RAM now.
[35:58.000 --> 36:06.240]  So that's why I'm... I'm not too concerned about your problem, although I will concede that it, you know, it's a problem of efficiency when you start doing this.
[36:07.200 --> 36:09.660]  Okay, so let me show you this other hack that you can do.
[36:10.000 --> 36:18.440]  So the question is, you know, there's been a lot of debate about whether people can go to libraries and find out who's taking what book from the library.
[36:18.900 --> 36:25.540]  And, obviously, this is a big problem because Al Qaeda might come in here and try to blackmail servicemen or something by reading, you know, finding out what they've been reading.
[36:25.880 --> 36:30.680]  And so a lot of librarians have been trying to fight terrorism by destroying library records or things like that.
[36:30.980 --> 36:41.420]  But one of the problems they have is they say, you know, we can destroy them after people return the book, but we need to kind of keep the record just to make sure they bring it back just because, unfortunately, people will abuse the libraries.
[36:41.420 --> 36:42.800]  And that's a good point.
[36:43.280 --> 36:49.980]  So I started thinking, is there a way that you might be able to make this a little bit better with using some hash functions?
[36:50.260 --> 36:53.340]  And so I kind of imagine these other database tables you might have.
[36:53.560 --> 37:00.480]  So you can imagine, like, there's the James Morrison guy who works for American Express, and he takes out some books.
[37:00.680 --> 37:09.840]  What the library might store is instead of storing the book's title, it would store the book's title and password and the replacement cost.
[37:09.840 --> 37:15.260]  So this fellow, James Morrison, is on the hook for $26 until he brings back this book.
[37:15.360 --> 37:21.520]  And then they would take the book, and they would look at it, and they would hash the title, and maybe they would include a password, maybe they wouldn't.
[37:21.740 --> 37:26.180]  And then if that's the case, then James Morrison's obligation would be discharged, and they would delete it.
[37:26.560 --> 37:38.080]  And if he didn't bring it back by the date—and there's no date in this table, but you could put one in— They would just send them a bill or they would bill his credit card or they would deal with, you know, unreturned books as they do now.
[37:38.420 --> 37:48.020]  So I think this is kind of a neat feature because the library can kind of protect these personal records without keeping detailed records of what people are reading.
[37:49.900 --> 37:50.540]  Yeah, yeah.
[37:52.720 --> 37:54.120]  Well, it would be Mr. Morrison.
[37:58.010 --> 38:01.270]  Well, he would just type it in when he was returning the book and then it would be hashed and then...
[38:08.590 --> 38:12.990]  No, they still have Mr. Morrison's name and they know he's on the hook for $26.
[38:13.190 --> 38:15.030]  They just don't know what book he is reading.
[38:15.410 --> 38:19.230]  So he couldn't be blackmailed and he could... which is what they're trying to protect.
[38:19.510 --> 38:21.290]  So they can still done him for the $26.
[38:21.710 --> 38:25.570]  And the way he discharges his obligation is to bring the book back and types in his password.
[38:25.770 --> 38:26.410]  They hash it.
[38:26.470 --> 38:28.910]  They say, oh, you brought back 7872B.
[38:29.110 --> 38:30.570]  I remember chapter seven.
[38:30.650 --> 38:31.130]  Wasn't that great?
[38:33.950 --> 38:35.590]  Okay, now you have one back there.
[38:45.680 --> 38:46.920]  That's a perfectly fair one.
[38:47.020 --> 38:49.000]  That's why I suggested putting in the password.
[38:49.240 --> 38:54.740]  So if you want to make the library a little more friendly but less secure, you only just hash the book titles.
[38:55.880 --> 39:02.100]  And if you want to make it more secure, then you hash Mr. Morrison's password in with it.
[39:02.100 --> 39:04.980]  So again, it's that kind of trade-off I was talking about.
[39:09.450 --> 39:10.610]  Yeah, I suppose so.
[39:11.210 --> 39:14.890]  But, you know, perhaps you can have a newfangled one if you want to go...
[39:14.890 --> 39:17.250]  where they type in a pin code when they drop it in.
[39:17.550 --> 39:21.010]  I think it really depends how much you care about people's browsing records.
[39:21.390 --> 39:23.970]  But I think that this is still a very practical system.
[39:24.910 --> 39:30.810]  But if you want it to be really secure, you have to go to, like he points out, a little bit more arcane length.
[39:32.930 --> 39:42.110]  And if you want to, if you really want to even protect people's names and you don't even want people to know that they're in there, you can extend this even further and you can start hashing up their names and passwords too.
[39:42.930 --> 39:44.870]  And you just keep the replacement cost.
[39:45.030 --> 39:50.270]  And so when they show up, they actually have to type in their name and password and present the book to discharge their obligations.
[39:50.730 --> 39:56.890]  And I think the downside with using a table like I've got here on the bottom is that what the people have to do is they have to put up a bond.
[39:57.230 --> 40:03.010]  Where, you know, if you want to take out this book, you have to put up some bond of $14 and then you get the $14 back when you bring back the book.
[40:13.430 --> 40:15.410]  Yeah, that's a good point.
[40:15.550 --> 40:23.350]  I mean, if you, well, it just depends, you know, whether the guy wants to get it off his, get that $26 charge off his back because of return.
[40:28.140 --> 40:37.900]  Well, it's, you know, that is a good point is, you know, you may not be typing your PIN number that time, but you may come back later and you type in your PIN number later to discharge the obligation.
[40:38.460 --> 40:41.140]  Yeah, we've got about 15 minutes here and I've got a few more slides.
[40:41.360 --> 40:44.060]  How about if I try to speed through them and then we'll have...
[40:44.540 --> 40:45.720]  Oh, we have five minutes.
[40:45.820 --> 40:46.100]  I'm sorry.
[40:48.720 --> 40:59.360]  So, this was the slide that I talked about where he asked the question about what do you do about people having the same name or typing in their name differently each time and I was, the solution is a canonical form.
[40:59.940 --> 41:18.000]  I talked before, I'll mention this only briefly, is quantization, which kind of is a fancy technical term for an abstract way of always handling just keeping the zip code or kind of coming up with one point inside a set that refers to all the sets or the entire set.
[41:18.620 --> 41:26.700]  One of my favorite ways of doing this is to use some steganography and what you can do with the database is you can kind of, in essence, have two databases that are mixed in one.
[41:26.900 --> 41:34.280]  So, the example I always use for this is that you might have a ship's location with...
[41:34.800 --> 41:49.620]  You may want to provide an incorrect or an inaccurate ship's location to people like family members or, you know, the general public, but you want the supply ships and the people who really need to deal with the ship to know the exact location.
[41:49.620 --> 41:53.580]  So, there's some ways you can use some steganography to hide both in the same database.
[41:53.580 --> 41:56.360]  And I can tell you that later if you still have questions.
[41:58.240 --> 42:03.900]  I like the idea of mixing in fake data, where there's a digital signature that tells you which ones are real and fake.
[42:06.620 --> 42:14.840]  So, this is the final slide, which is that I think one-way functions can destroy data without destroying all the usefulness.
[42:14.840 --> 42:16.140]  You can still test equality.
[42:17.040 --> 42:20.520]  And, you know, finding the right amount of noise and the way you deal with this is kind of an art.
[42:20.660 --> 42:26.120]  And as the people who've asked questions have pointed out, you know, there are these kind of trade-offs along the way.
[42:27.640 --> 42:34.820]  So, I still want to kind of make the point that I think that information is abused frequently by insiders and people who break in and attackers.
[42:35.620 --> 42:44.880]  And so, I think that there's a reason why legitimate businesses, intelligence agencies, and people who collect this data should really think about just what they have there and whether there's a way they could do it translucently.
[42:46.220 --> 42:48.620]  Okay, so, does anybody have some more questions at the end?
[42:48.680 --> 42:50.140]  I guess we have like one or two more minutes.
[42:50.140 --> 42:51.620]  Maybe one question.
[42:51.820 --> 42:53.200]  The guy in green hasn't asked one yet.
[43:10.330 --> 43:14.410]  Yeah, you could maintain that, I guess, in a different table that doesn't have the name attached to it.
[43:16.130 --> 43:20.510]  So, you know, you would just have one bit that marks whether a book is in or out.
[43:20.590 --> 43:22.910]  And then you'd have the other one.
[43:23.010 --> 43:24.810]  Now, the guy behind you in black is...
[43:29.060 --> 43:38.340]  I don't understand... I don't understand how you're going to end up having the babysitter decide which parents can see them or the parents knowing which babysitter they're going to get.
[43:38.580 --> 43:43.000]  Well, the babysitter... I can explain this more to you later, but the babysitter...
[43:43.000 --> 43:46.120]  The babysitter would be in charge of the second table, the ones on the bottom.
[43:46.120 --> 43:52.200]  So, if the babysitter... If you came to me and said, I want you to sit for my kids, and I said, yeah, that'd be cool.
[43:52.700 --> 43:54.520]  You'd say, well, here's my name and my password.
[43:54.820 --> 43:55.720]  And I would say, great.
[43:55.880 --> 44:00.980]  And I would then go to my computer and I would give you access by putting that entry in that bottom...
[44:00.980 --> 44:02.360]  You know, that entry in the bottom table.
[44:03.620 --> 44:04.800]  Let's see, over here.
[44:14.650 --> 44:20.530]  I don't remember collecting any book and doesn't recall or won't fess up to losing said book.
[44:21.470 --> 44:25.170]  What do you suggest as the fallback method?
[44:25.410 --> 44:36.770]  We were thinking that a good possibility would be to have a long list of all the books that are out and have, like after a certain amount of time, have them go on to a different list that has a trail back.
[44:36.930 --> 44:43.010]  Or to have an independent computer that has a record of the people and the books that's not on the network at all.
[44:43.010 --> 44:45.750]  So that it, you know, very locked down type of thing.
[44:45.870 --> 44:47.050]  But what do you... have you thought about this?
[44:47.050 --> 44:49.150]  Yeah, I mean, I think all of those solutions are good.
[44:49.330 --> 44:50.830]  And we're gonna have to end everything here.
[44:50.990 --> 44:54.930]  But I think you could do all those things.
[44:55.090 --> 44:58.850]  And the first problem that you suggested, I think, is just a generic problem to having a library.
[44:59.130 --> 45:01.690]  People can always disavow taking a book out.
[45:01.830 --> 45:09.110]  So yes, just because you've got a record in your library that says Peter Wayner took out this book two weeks ago, I can always just say, well, yeah, I didn't.
[45:09.690 --> 45:12.050]  And then the library would say, yeah, who are you fooling?
[45:12.150 --> 45:13.850]  We've got, you know, we don't make mistakes.
[45:14.230 --> 45:16.730]  And then it becomes a he said, she said thing.
[45:16.910 --> 45:21.450]  And I think you're right, it's a practical problem in a few cases.
[45:21.710 --> 45:26.430]  But, you know, I think you could just say, look, if you're taking...
[45:26.430 --> 45:29.010]  You know, our records are solid.
[45:29.130 --> 45:31.170]  Are record keeping solid and we don't make mistakes.
[45:33.230 --> 45:36.550]  You know, or you could just be kind and, you know, forgive it because you want to be cool.
[45:36.550 --> 45:39.090]  It kind of depends, I guess, but I think you're right.
[45:39.490 --> 45:42.610]  Okay, so if anyone else has more questions, you know, please come up to me afterwards.
[45:43.170 --> 45:52.490]  If you're really interested in it, I boiled a lot of this stuff down to a book, which you can get from Amazon and, you know, I suppose it's kind of ironic.
[45:54.470 --> 45:58.670]  But I do push them to try to do something about this.
[45:58.750 --> 46:00.510]  So maybe they've read it there.
[46:00.570 --> 46:00.890]  I don't know.
[46:01.130 --> 46:04.510]  I talked to some woman who claims that they use these ideas, so we'll see.
[46:04.910 --> 46:06.850]  But you should check it out.
[46:07.030 --> 46:11.770]  There's a website, if you read my webpages, that there are a lot of practical examples which you can get for free.
[46:12.050 --> 46:13.610]  And this has got a lot of Java code in it.
[46:13.730 --> 46:18.010]  So thank you very much for being a wonderful audience and having such great, deep, insightful questions.