 Hello everybody, my name is Aksana, and today I will present our work with Ron Kanetian-Sanu Park about fully-deniable interactive encryption. When we talk about public key encryption, we usually have an eavesdropping attack in mind. However, in this paper, we are looking at a stronger adversary called a cursor, who has an additional power. After the communication happens, this adversary can come to both parties and demand to see all their randomness used to transmit a plain text. Most encryptions are not protecting against this kind of attacks because they are committing. For example, in El Gamal encryption scheme, the first component of the ciphertext uniquely determines the randomness of the sender, and therefore the sender has no other option other than to truly disclose its plain text and random coins. To mitigate this kind of attacks, the notion of deniable encryption wasn't reduced. And this is the main purpose of this work, we are asking whether it's possible to communicate deniably, potentially with many rounds. Note that coercion attacks capture not just coercion per se, they are actually applicable in any scenario, where parties have some incentive to disclose their true coins and randomness and the plain text, for example, in a bribery case. It is instructive to look at the case where parties have a pre-shared secret key. When this is available, deniable encryption can be very easy, just send a one-time pad of the message, and it's easy to set up the fake key key prime to match any desired target fake plain text m prime. However, the question is how to come up with such a key to begin with in a deniable manner. For example, if Diffie-Hellman key exchange is used, then the key is committed to by the transcript, and thus we are back to the same problem. Therefore, in this work we are focusing on the notion of a public key deniable encryption, which was introduced in 1996, and the idea is exactly to mitigate this kind of attacks where the adversary can demand from the parties to see all their random coins. More concretely, deniable encryption comes with two additional algorithms called sender fake and receiver fake, where sender fake algorithm takes as input everything the sender knows, this includes its true random coins s, the communication transcript, the true plain text and the desired fake plain text m prime, and this algorithm will output fake sender coins s prime, which is consistent with a given transcript, no matter what it really encrypted. In a similar fashion, receiver fake will produce fake coins of the receiver consistent with a given target fake plain text m prime. Security requirement roughly says that the adversary cannot tell whether it sees true keys or fake keys. More concretely, it shouldn't be able to distinguish between the following two distributions. In one case, it sees an encryption of some innocent message like a cat, and the parties disclose their true random coins. In the other case, the adversary sees an encryption of a sensitive message, but the parties give it fake random coins consistent with the innocent message. In particular, if the adversary tries to decrypt the given cipher text with a given key, in both cases, it will get an innocent message. And moreover, these two distributions are required to be indistinguishable. The original paper considers three different cases of deniability, depending on which party gets coerced. In this work, we are considering the strongest case when both parties can get coerced. Note that in this case, it is very important that both parties claim the same fake plain text, otherwise the adversary can easily tell that they align. Nevertheless, we also consider an additional definition of deniability, which we call off-the-record deniability, which exactly aims to capture some security even in inconsistent case. We are inspired by the fact that ideal secure channel will provide some protection to the parties even in this case. For example, the parties maybe didn't have a chance to coordinate on their fake stories, or maybe the receiver turned against the sender and decided to prove to everybody else that the sender has sent a particular sensitive message to him. It can do so by revealing its true secret coins of the receiver, even though the sender can make a counterclaim by giving fake coins consistent with different plain text, it could be that the combination of receiver true coins and the sender fake coins still reveals what the true plain text is. Deniable encryption doesn't give any protection in this kind of scenario, however, in the ideal channel case, the parties would still be protected. Off-the-record deniability exactly aims to capture this kind of protection. Note that the standard deniability and off-the-record deniability are incomparable, however, together they give the protection akin to secure channel. Let me briefly mention the definition here, so the adversary should not be able to tell which world it sees. In all three worlds it will see that the sender sent a kitten and the receiver received a dog, however, in one world the true message was the kitten, in the other world it was the dog, and in the third world it was yet another sensitive message. It's important to realize that deniable encryption won't solve all your problems. If your fake plain text is not very believable to begin with, then creating keys will not make it any better. Deniable encryption doesn't tell you how to pick your fake plain text. Indeed, this is a problem even in the ideal world. Rather, as long as you have some fake plain text, be it believable or not, deniable encryption tells you that the keys will not degrade the level of how believable it is. Let me briefly mention some related notions. Non-committing encryption has a similar flavor as deniable encryption, meaning it allows to open some cypher texts in arbitrary manner to different plain texts. However, this fake opening can be only done with respect to simulated cypher texts. Said otherwise, non-committing encryption only allows to fake as part of a mental experiment. True cypher text cannot be faked. A more relevant notion for us is a notion which came up under different names in different papers and with slight variations of the definition, which I will call a flexible deniability. This deniability gives a weaker form of deniability, which can be called a plausible deniability, and the idea there is that parties can use a special fake entrapter in order to come up with fake coins. However, the adversary does not learn this fake entrapter because parties claim that they have never generated it. Security of the schemes is crucially based on the fact that the adversary believes the fact that this fake entrapter was never generated. In contrast, in this work we are considering full deniability, where the adversary is fully aware of the fact that parties are running deniable encryption scheme. In particular, if this encryption instructs parties to pick any trapdoors, the adversary expects to see these trapdoors as well. Let me talk about some prior work. So the original paper which introduced the notion of deniable encryption also gave the first construction of sender deniable encryption, however the detection probability there was not negligible. It was inverse polynomial in the size of the cypher text, which means that to get negligible advantage you have to send super polynomial large cypher text. The study of deniable encryption came with first an impossibility result by abandoning it all, which said that receiver deniable encryption is impossible in two rounds. This automatically means that the by deniable encryption in two rounds is impossible as well. A couple of years later in a beautiful paper The High End Waters showed how to build sender deniable encryption from obfuscation. This settles the landscape of two-round protocols and shows that deniable encryption is basically impossible in two rounds. However, does this mean that we have to give up? No, maybe we can build something in more rounds, maybe we can build deniable encryption in three rounds akin to key exchange protocols. And indeed, if we move to the three-round setting it's very easy to combine prime work to get a three-round receiver deniable encryption. In fact, it's very easy to transform it into a sender or receiver deniable encryption where the adversary can adaptively choose which party will get corrupted. However, all these approaches crucially rely on the fact that some part of the secret state of parties remains secret to the adversary. It's not even clear a priori whether it's possible to get a fully deniable encryption in doesn't matter how many rounds, because the adversary can see all the transcript of the communication and all the state of the parties. Nevertheless, in this work we show a positive result. We show that it's possible to get deniable encryption which satisfies both the standard deniability and our new notion of all the record deniability and does essentially emulate secure channels in the presence of coercive adversary. This protocol requires only three rounds which is optimal given the impossibility result. And the protocol requires pretty strong assumptions of sub-exponentially secure obfuscation. Our scheme also requires a setup in the form of a CRS which consists of a bunch of obfuscated programs. These programs can be reused many times. Before going into the construction, let's look at why deniable encryption cannot exist in two rounds. Intuitively, the problem is that once you start lying, you have to keep lying and remember all the lies and this is a problem. More concretely, assume the adversary sees the challenge transcript and the challenge secret key. Let's say that this secret key was already fake with respect to this transcript and I will denote this by the edge on the picture. Roughly the attack goes as follows. First, the adversary has to generate multiple related transcripts. I am not defining what exactly related transcript means but it's very easy to generate them in a two-round case by simply producing fresh ciphertext under the same public key. Then the adversary should take the challenge secret key and fake it again with respect to the second transcript it generated. Now the resultant secret key should remember the lies about two transcripts. Now the adversary can keep doing this and eventually it will get a secret key which is fake with respect to multiple transcripts. Now the secret key is a fixed size string and it can only remember that much information theoretically. Therefore, as long as we keep doing this for a long time, eventually the resultant secret key will have to forget some lies. The paper of Bentley net all shows that eventually it will have to forget the lie about the very first challenge transcript and therefore this eventual secret key can be used to decrypt the challenge transcript honestly. To build a scheme in three rounds we need to avoid Web of Lie attack in three rounds. As I said in two rounds it's inherent that you can reuse the public key and therefore generate multiple transcripts. However in three rounds we can try to avoid this by essentially letting the sender commit to its random coins in the first round and the hope is that then there is only one valid third round message from the sender and indeed our first attempt follows this paradigm. So the first two messages exchanged by the parties will be basically the hashes of everything the parties know so far. Concretely the sender will send the hash of its sender randomness s and the plain text m and the receiver will send the hash of the first message message 1 and its random coins r and it will be the third round when the actual plain text will be transmitted to the receiver. Concretely the sender will encrypt under the key which I'm not talking about yet the plain text and the history of communication so far. Then the receiver can decrypt it again I'm not talking about how and learn the plain text and the question is why is this deniable or how to make it deniable. Indeed the first message for example depends on the plain text and therefore to make it deniable the sender should have some way of inverting this hash with respect to a different plain text. Here is where obfuscation comes in. We will let the CRS contain all the programs of deniable encryption in an obfuscated form and in particular now the parties do not have to perform any computation on their own. They should only run obfuscated programs and send over their output. To make the programs deniable we will use the beautiful technique from Sahay and Waters which basically enables the deniability of arbitrary algorithm. This is not very important for the stock but roughly their idea is that obfuscation can hide where the program is doing the actual computation like a hash or whether it's running some special trapdoor execution which will simply output any output you wanted to. Moreover they show how to come up with special algorithms sender fake and receiver fake which can let parties find the proper randomness which will trigger this trapdoor execution. Now the question is okay at this moment we have a scheme which doesn't allow for web of lie attack and where every message is explainable. Aren't we done? Don't we have already deniable encryption scheme? And the answer turns out to be not yet. What we've gone so far is a local consistency meaning if the adversary looks at every single algorithm on its own it will be deniable. However this doesn't mean that the adversary who sees all the values in the system cannot tell the true plain text and in fact it turns out that our scheme so far is not secure. So we wanted our web of lie attacks to not go through by saying that we cannot generate related transcripts anymore and indeed this is why we came up with all those hashes. However reality turns out to be very different from our expectations. And indeed one of the contributions of this work is to show that in any three round scheme there is always a way to come up with related transcripts. This is what we call a chain in attacks. Since related transcripts are unavoidable we need to make sure we protect against web of lie attack. And it turns out that in three round case you can protect against this attack as long as the scheme follows a special decryption behavior. We call this a comparison based decryption logic. Here is what it says. Assume the adversary generates a bunch of related transcripts and then takes say the transcript number four and uses it to generate fake randomness r of the receiver or think about it as a secret key of the receiver. Then it takes this result in fake secret key and tries to decrypt other transcripts. What should decryption algorithm do? We say that it should do the following. If the target decrypted transcript is ahead of the chain, say it's transcript number five, six and so on, then decryption should decrypt honestly. However if it is before transcript number four on the chain, in particular if it is the challenge transcript, then decryption should refuse to decrypt. It turns out that once this behavior is in place, the resulting scheme will indeed be secure. However the question is how to enable this behavior? Indeed, decryption algorithm has no idea about the chain. It only takes as input receiver randomness r and the transcript. It has no idea where they are positioned in the chain. Thus we need to enhance the scheme to make sure the decryption has all the information it needs to make a proper decision about the decryption process. In particular we do the following. First we change the scheme so that every transcript in the chain actually knows its own index in the chain. What does this mean to know the index? It means that the transcript will have an encrypted index inside it for the message. I am not telling you how to produce how to set up this change. However once this change is in place, it is very easy to set up the scheme so that every fake r also knows the index of its parent transcript in the chain. Indeed the receiver of faking algorithm can simply look up the index of a transcript and then copy it inside the resulting fake r. Once these indices are sitting inside the proper values we can have a decryption algorithm which looks at these indices, compares which one is bigger and based on that makes its decryption decision. To set up this kind of information we need to modify all the major programs of our deniable encryption scheme to make sure the proper information gets passed around in different values such as fake s, fake r and the transcript. Let me conclude my talk with the final overview of the scheme. So as I said the CRS will contain all the obfuscated programs of deniable encryption and then parties will simply run the proper program and send over the result of this program. As I said before the first two messages are essentially hashes of everything parties know so far and in fact we implement them using very special prfs which have to be IO friendly. The third message of deniable encryption will actually carry the plain text and in addition it will also encrypt zero. What is this zero? This has nothing to do with the plain text this is the index of this transcript in a potential chain which the adversary can try to generate. So this is always set to zero in an honestly generated transcript. As I said all the programs should be set up in a special way to make sure that the proper flow of information is ensured within the scheme. In particular the third program of the sender should make sure that the proper index gets inside the cipher text and the decryption program of the receiver should make sure it follows the decryption logic and decides whether to output the message or return an error. This concludes the high level overview of our scheme. I encourage everybody to take a look at the paper we have updated an imprint and the section two should give a very good overview of the scheme in fact it's almost complete overview. If you have any questions me and my co-authors will be happy to take them over email and thank you very much for your attention.