 Okay. So my name is Brent Waters. I'm going to be talking about detecting dangerous queries, a new approach to chosen CypherTech security. This is joint work with Susan Holmberger and Allison Lucco. So one of the great events of cryptography, I think, is public key encryption where Bob can send a message to Alice by just knowing her, encrypted message to Alice, just knowing her public key, send it on over, and then Alice can decrypt knowing her secret key. Now, where it gets somewhat interesting is how we think, what do we mean by security? How do we capture security for these schemes? One way, maybe the first most natural one, is to think of some type of passive security, like a chosen plaintext attack, where we have our attacker at the bottom, who's eavesdropping on the channel, gets the CypherTechs and tries to distinguish or figure out what's inside it. However, perhaps a more robust and useful model for security, something known as chosen CypherTech security, where attacker can actually inject messages herself, and in particular, might create a CypherTechs, send it to Alice, have Alice decrypt it, and let's say somehow use this answer to help her in discerning what's inside that other message. Now, for a long while, we've actually been able to formalize these notions of security in terms of games. For example, in the indistinguishability and the chosen plaintext attack game, the attacker, the challenger first sends the attacker to a public key. The attacker will then take two messages, M0 and M1 of equal length. Then the challenger flips a coin B, and it's going to encrypt the message M sub B under the public key. I'm going to call that CT star over there, the challenge CypherTechs, and finally it submits a guess B prime. And we see the advantage of the attacker is the probability that B is equal to B prime minus one-half. And in general, a scheme will be considered to be secure if this value is negligible. Now, for chosen CypherTechs security, the pattern is going to be very similar in terms of this indistinguishability game like we had before, but we're going to also endow this attack with more power in that he will get to send CypherTechs to the challenger, and the challenger will decrypt them for him. So this will actually happen both before and after seeing the challenge CypherTechs, CT star, with this one very important restriction that the challenge, after seeing CT star, he cannot actually ask for a decryption of the challenge CypherTechs itself, or else the game would be trivial to break. So that's chosen CypherTechs security. Now, before we get into, okay, and then CCA one is where we move the second oracle. Now, before we get into the results of this talk, I at least want to put in perspective what I consider to be the very big grand huge challenge of everything, which is can you take any chosen playing text secure scheme and build a transformation to a chosen CypherTechs secure scheme. Now, we know very little about this problem. It's still very wide open, but I don't know, I like to sort of whenever I think of anything in this realm, I like to, I think it's important to kind of keep this bigger goal in mind. So why we haven't shown the bigger goal, there's been some notable results along the lines of figuring out chosen CypherTechs security, only some of which I'm going to be able to call out here. For example, using non-interactive zill launch proof techniques, we can build CCA security from trapdoor pairings, like in the RSA assumption and also trapdoor permutations, RSA assumption and pairings, but we don't know how to do it from DDH or lattices. Kind of something I grouped as Kramer chute plus starting, let's say about 14 years ago in 98, we started knowing how to do a DDH palli encryption. More recently, I think coffines and kilts had an efficient factoring solution and so on and so forth, and that we didn't know how to do lattices, and then about four years ago or so myself and Chris Piker introduced law CTDS, which could in some sense finish off the number theory, or at least the main, we're able to prove it now under the main number theory of our constructions. Okay, one other piece of work I also want to call to note was this interesting problem proposed by Myers and Shalad a couple years ago, and they want to ask the question is, suppose I give you some scheme, which I'll tell you it's one bit CCA secure, that is it can encrypt one bit and it's CCA secure, and the question is, can we encrypt many bits or end bits and still get CCA security? And the first thing to notice is the thing I would think of when I first do this, okay, well, maybe we just append these together, and straightforward appending actually doesn't work. So suppose I want to encrypt three bit messages, and I just do it by, I used to call encryption scheme first to encrypt one, then encrypt one again, and then zero, and I shove these all together, and I call these things the ciphertext. Well, it's a very easy attack. Let's say I just do I flip the order for example of two of these. And now I have a new ciphertext. And if I query this new ciphertext and get the answer for it, it'll tell me how to break the original ciphertext. So this type of straightforward appending is very easy to break. I'll say in the myish lot they actually did solve this problem, and they had what I thought were a lot of neat ideas. On the other hand, I thought they had some heavyweight machinery and was perhaps a bit more complex than it eventually needed to be. So one thing we'll do in this work is try to capture this result in the process and also have a simpler explanation for it amongst other things. Okay, so coming to our result, I'm going to introduce a new notion of chosen ciphertext security, which I call detectable chosen ciphertext security. This isn't a goal in and of itself, but I think it's a good target in that a lot of different natural type of schemes, I think, can map into it hopefully more over time. And I'll also show how to build this ladder over here in that we can take any detectable scheme and build it to a fully chosen ciphertext secure scheme, which is what we actually want. Okay, so before I formally define it, let me give you a little intuition about what DCCA detectable CCA security is about. The main idea here is that it's CCA secure as long as what we avoid what are called dangerous queries. And these queries are bad or dangerous relative to the challenge ciphertext. We're going to have two properties about this. First of all, it should be hard to produce these dangerous queries before seeing the challenge ciphertext. Before seeing the ciphertext I want to attack, I can't really create any bad queries for it. The second property is that if someone comes up with a dangerous query, you can actually detect it. You can tell, oh, asking what this ciphertext is is going to be bad, is going to help someone attack this other ciphertext. So I can give a very concrete example here. Consider this one-bit CCA scheme that I talked about earlier, or let's say three-bit CCA scheme, which came from concatenating one-bit ciphertext together. This is actually a detectable scheme in that a dangerous query is any type of reordering or copying of any of the original blocks. And you can see it's both like hard to produce before you see the ciphertext that I can't move around too much here. Before you see the ciphertext that I put up here, you won't be able to copy any of those blocks. You won't be able to predict or guess what they are. However, it's also very easy. If CT stars my ciphertext, I come up with another ciphertext which copies one of these blocks. Just by comparison, it's very easy to tell if it's a dangerous query. So this is a very natural example, or an example from before, at least, that detectable captures. Okay, so getting a little more formal, detectable encryption system will have the usual algorithms set up, encrypt, and decrypt that we're all used to. However, I'll also add something else to any detectable scheme, which would be a detection function F, which takes as input a public key, CT star, think of this as the challenge ciphertext and CT, and I'll put zero one, one indicating if the query is dangerous, and zero if it's not. All right, so the scheme is going to have two security properties. The first one is going to be this hard to predict property. I'm going to give you this two versions of it. I'm going to give you a strong one. It says suppose we give the attacker actually both the public key and the secret key, and then the attacker gives us a ciphertext and a message, and then we encrypt this message to come up with CT star. It should be hard for the attacker to come up with a dangerous query for anything where F of public key, CT, and CT star is equal to one. This value should be negligible if it's secure. The main point here is that the attacker has to give the ciphertext that he's trying to make dangerous before seeing CT star. So it should be hard to come up with a dangerous query before seeing it. The second property is going to be a game a lot like CCA security, which I have up here, except we're going to make one important change before we had this restriction that CT is not equal to CT star. Here we're going to replace it with the restriction that you can't make any dangerous queries in the second phase. Okay, so the two properties are that it's hard to create something a priori that's dangerous, let's say, and then an indistinguishability game where we just disallow dangerous queries. Now, I'll just remark that detectable CCA security lies somewhere in between full CCA security and CCA1 security. Okay, now what hopefully motivates it is that it seems like at least a natural target for multiple different things. First, probably the leading example, let's say, is this one bit to many bit that I talked about before, but it also captures some other things like tag-based encryption and what I loosely call slop, your heuristic CCA, kind of to catch the idea, maybe if you try to make a chosen ciphertext scheme, and here's the bar for getting a chosen ciphertext secure, and you fall a little bit under it, it might still be detectable, so if you apply a process to it, you might be able to jump back up to what you want. I should remark that the middle one, there are other ways to boost this up to full CCA secure, but it's kind of, I think, neat that this thing captures all these notions. Okay, so now that I hopefully motivated why it's an interesting thing to study, let's see now how we actually can take a detectable scheme and bring it all the way to fully CCA secure. There's going to be three basic ingredients in building it. First, this detectable notion I talked to you about. Second is going to be chosen plain tech security, the plain thing. And the last one is what I call one, what's been called one bounded CCA security, which is CCA security, if you just get one query. It doesn't matter whether it's before or after the chosen ciphertext. It turns out that these are all implied, we can get all these from detectable CCA. This direction is pretty trivial, and this other direction going to, I guess, your left has been done in previous work. Okay, and then another little thing I'm going to use for this talk is that I'm going to consider messages to be in zero one star and randomness to just be of length of the security parameter. So the random coins are just always n bits. This can be justified by PRGs. Okay, so let's see how the construction works. First, there's the setup scheme, which is fairly simple. We're just going to run the setup schemes for the one bounded CPA scheme and detectable scheme and come up with three public key, secret key pairs, which I call A and B keys, and also the inner key. And so the public key would be that triple of public keys and the secret key is a triple of secret keys. Okay, so you just want run the setup algorithm for each of them. Now for encrypt, let's say we want to encrypt a message under the public key. We first start out by choosing three random, three random values, which would be the random coins for the encryption schemes, which I'll call RA, RB, and R inner. Next, we're going to, we're going to do some type of nested encryption eventually. I'm going to encrypt, so create what I call CN, which I'll encrypt under the detectable scheme under that public key. And the message will be the main message itself, but I'm also going to encrypt these random values as part of the message. And the coins will be R in. So these used here are actually not as coins, but more treated as a message. Then what I'm going to do is I have this inner layer. Now I'm going to create the two outer layers. So I'm going to take cipher text A will be encrypted on as under the one bounded key. I'll encrypt as the message CN under randomness RA. And I'll create CB in a similar manner. So I'll encrypt CB in a very similar manner. And the cipher text at the end will just be CA comma CB. So this is what it looks like on the inner cipher text is this yellow thing you see on the inside over here. And the CA is the green part and CB is the blue part. So both of the CA and CB are encrypting this yellow inner part. Okay. So now let's see how we actually can do decryption. So to decrypt the cipher text, what we first do is unwrap the left half, the A half of the cipher text, and we get CN prime. Then we get message, then we unwrap CN prime itself using another decryption and we get M prime RA prime RB prime which are the claimed message and encryption randomness for that. After that we're actually going to do sort of something like an integrity check. We're going to want to make sure whoever created the cipher text, you know, did it in a legitimate way or at least came close to it. So what we'll actually do is re-encrypt the two outer cipher text and make sure that it's what we started with. So we'll get, okay, this guy is saying here, okay, I'm encrypting this, this CN prime under randomness RA. We can actually check whether he did this or not. Since we have everything, we have all the randomness ourselves, we can actually do this. And similarly for RB, this is going to allow us to do, it's going to create a scheme where eventually the proof if we encrypt it from the left half or the right half, or decrypt it from the left half or the right half, no one could actually tell which one we did. Okay. So decryption, it looks like we unwrapped the left half, then we unwrapped that, just get this little part over here, and then we re-encrypt and test. Okay. So since I won't have a chance to actually prove, you know, show the proof of the scheme or anything, I just want to give you a little bit of an intuition about the ideas of what's going on here. So the features of the scheme, they have some ideas from my shot, but it looks a little bit like a no or Jung two key system, like I'm going to encrypt this message which happens to be the yellow ciphertext, I'm going to encrypt it under two keys using the NY two key paradigm. In the no or Jung paradigm though, they made sure this was done correctly, it was very important that this wasn't faked, and they made sure of this by doing a non-interactive zoological proof, where you prove that you did it correctly, and before decrypting, some would check this proof. Here we don't have Nizix, you know, we don't have that, but instead we check that the structure is there with this re-encryption mechanism that effectively checks the same thing. So here we're using embedded randomness instead of Nizix. Okay, so I guess what I tried to have here was a double edged sword to mean that this idea of embedded randomness has good and bad. The good is we can get something like this NY, this two key type of paradigm going on where we don't know which side we're decrypting, someone can't tell which side we're decrypting from. The bad is encrypting, in an encryption scheme, encrypting your own randomness is usually a sometimes a bad idea or a tricky idea or can make things go wrong or broken, or at least make proofs very hard. So here it makes, the question is somehow if we're going to use the outer ciphertext security intuitively at some point, it's weird to have its randomness embedded and that's going to be kind of a pain for getting a proof to go through. Okay, so let me, I won't have a night time to give the actual proof itself, but I can try to give maybe just a little insight into it. First of all, the focus of the proof is what is the problem? The main problem we're going to try to say that doesn't, that doesn't have, that we need to argue that doesn't happen is getting problem queries. So imagine that the C A star and C B star are a challenge ciphertext and C A star is the inner part of the challenge ciphertext. A problem queries when I get a, I get a challenge ciphertext C and I decrypt the left half and I guess C A prime, where C A prime is relative, is dangerous relative to C A star. If this never happened, if I could like argue that this didn't happen, this bad event, should I define over here, didn't happen, then I would be like home free, like then I could use the detectable property. If the dangerous queries didn't happen, the detectable property would be just enough for me to finish things off. So the proof, the hard work of the proof is making sure that this thing doesn't actually happen. Okay, so let me try to give you a high-level overview. I'll skip through this. So the main idea here is we're going to kind of consider two different distributions, one which encrypts the normal randomness and another one where even the coins are not embedded. Okay. So just keep in mind we can consider these two different distributions. Okay. So here's the main idea or the proof overview. We're going to try to eliminate this bad event. The first thing we're going to do is we're actually going to eliminate the bad event when the random in this kind of pretend case that doesn't really even come up in real life when the randomness is not embedded. And there we'll be able to use the inCPA and the one-bounded scheme to be able to argue security, use the nor young trick. And there we kind of get things are sort of easier because the adversaries queries have to embed the randomness, but we don't have to. So it's sort of this pretend game where things are able to go through. Okay, so that's great, but that doesn't really help us for the case we really care about when we're at, or it doesn't directly help us with the case where we really care about. However, then we're going to move on to the step of trying to argue that this bad event of a dangerous interquery doesn't happen when the randomness is embedded. And we could try to go through the same proof steps as before, but we'll get stuck somewhere. So instead, what we're going to do is be able to do an indirect inference from the previous case. The main idea here, and if you do get a chance to look at the paper, I think this is kind of unfortunately the interesting thing that I'll have to go over quickly. Usually, when you're doing a security proof, you try to, in the adversaries making these queries, you try to answer all these queries, get to the end, and the adversary is going to tell you what it thinks. And you know, you use what it thinks in order to break your, in order to break the assumption. Here, and you don't want to get stuck. You don't want to get stuck where you can't simulate any further because then you won't hear what the adversary says. In this game, and kind of this point, number two, you can go further, and the adversary might give you a query where you get stuck. And normally, this would be, and you can't simulate any more. Normally, this would be really bad, but in this case, the fact that he made this query itself tells you something, and let you break the detectable game. So obviously, this, I apologize for the high hand review, overview, but this is kind of what I think was the neat thing. And also, there were hints of this, there were parts of this idea in the Myershalat thing. And then once you eliminate the bad event, finishing off isn't too, too hard. Okay, so in summary, we create a new extraction called detectable CCA security. We can build full chosen CypherTech security from it. It covers multiple things, like the one bit to many bit, tag-based and more. One of the main things is it's embedded randomness, and it's both a blessing and it has its problems. And the way to get around it is this kind of indirect argument, which I thought may be one of the most interesting things of the work. And I'll just conclude by throwing up, again, what I think the picture is here. Probably not to scale, to be honest, but we built this ladder in between detectable CCA, full CCA, and obviously these other gaps remain unsolved. I don't know, maybe this is an interesting one to think of in the near future, or re-examine. Okay, thank you very much. Are there any questions? Yes, Sarah? Do you have a construction of a DCCA scheme? Sure. Well, for example, I threw a tag-based encryption inside of many examples. I guess IK has one. I mean, there's many tag-based encryption schemes that I could plug in there. One interesting thing is even the PW, the Pikerwiders, when we first gave our law CTDF paper, we first described a CCA1 scheme, it happened to also be detectable. So a lot of the schemes that you might think of is just, and also Kennedy, Hilary Katz, they had a light version of their scheme. A lot of these things that you might think of only CCA1 happened to be detectable. Any more questions? Okay, then let's thank Brent again.